How Sprinting Slows You Down: A Better Way to Build Software
Summary
Aggressive two-week deadlines are common, with a small army of developers dividing up work production-line style and racing toward an immutable launch date. Consider a frontend engineer whose job would be made much easier if the backend team would change the API to expose a critical piece of information to the front end. These implementations are virtually impossible to achieve in big-team systems, since no one — save for an omniscient architect who can foresee every issue — has the authority to make all the necessary changes without superhuman levels of communication. This fundamental truth is easily overlooked when engineering is treated like any other department that does not have the context, correctness requirements, or compounding downstream impacts of writing code. They do not have to compromise technically sound implementations to hit arbitrary deadlines; they are always learning new skills and domains rather than being siloed in a narrow part of the codebase; they are not constantly putting out fires in production code; and they ship meaningful, cohesive solutions with high frequency.