While technological improvements have grown exponentially over the past decades, our software development practices have not kept pace. Common complaints of project-based, waterfall-oriented efforts include ...
Lack of visibility into progress, trade-offs, and quality.
Under-estimated dependencies and constant over-commitment.
Massive growth in complexity, discovered too late.
Phase gates that don't reduce risk.
Late delivery.
Poor morale.
What do these say about our business and software development models?
Empowered, self-organizing, and cross-functional Agile Teams using continuous integration and automated deployment practices deliver high-quality value to systems frequently and predictably. Agile practices provide transparency, immediate feedback, and objective metrics which support governance and relentless improvement.
A self-organizing, self-managing team of Agile Teams (also known as a Release Train) delivers large, coordinated system capabilities that are traceable to executive vision and strategy, and operate in accordance with the enterprise architecture, at a reasonable and reliable pace (e.g., every 10 weeks). Like individual Agile Teams, Release Trains also provide transparency into progress, immediate feedback, and objective metrics which support governance and relentless improvement.
Organizations that have a scaled Agile implementation have reported 30-75% improvements in release times, 50% reductions in defects, 20-50% increases in productivity, and happier, more motivated employees.
Agile yields these results by thinking about the problem of software development differently. By focusing ...
On work flow rather than on feature completion, overall value gets added to a software system more quickly.
On stabilizing velocity (a team's capacity for work) rather than on predictive ("level of effort") estimates, a shift in priorities and/or changes in requirements can be easily accommodated.
On fast feedback rather than on defect reduction, defects are prevented and the cost of learning and risk-taking is reduced by catching issues early.
Although software development is very different from manufacturing work, the principles of process and quality improvement are universal in nature. Agile grew out of Lean. In Lean-speak, the waterfall methodology forces huge batch sizes and long work queues which, in turn, centralize requirements and force design commitments during the times of greatest unknowns.
Agile recognizes that all units of value (e.g., business features or architecture enablers) pass through a process' interconnections (i.e., hand-offs); and that when a transaction between two points in a process is burdensome or costly (i.e., has a high transaction cost), it encourages the actors in the system (us) to accomplish more work and accumulate more value (i.e., increase batch size) before pushing it through the pipeline.
By comparison, shorter hand-offs allow for smaller units of value to be pushed through the pipeline more quickly and frequently, thereby increasing predictability, quality, efficiency, visibility, and flexibility. So, to improve on a process, it is more economic to focus on reducing the delays between integration points (e.g., analysis, design, development, test, deployment, use). And the best way to reduce delays is to restrict the size of the units of work that a resource (such as an Agile Team) should tackle at any one time. Consistently accomplishing small tasks results in big goals getting accomplished faster and with less cost and frustration.
In short, Agile seeks to optimize and predict how much work can done at a time rather than which work will be complete by a particular date.
For details about what success with agile requires of an organization, go here.