Published August 1, 2022
by Doug Klugh
Put working software in your users' hands as early and as often as possible while evolving your software through continuous delivery. Feature teams and component teams should often showcase software that is complete and potentially shippable. This will facilitate early and frequent feedback, provide true indication of progress, enable early release (when needed), and discourage teams from doing things that result in a lot of activity with little forward progress. Do not rely on completed tasks or milestones to demonstrate progress toward product delivery.
Working software is so fundamental to being Agile that it has been established as one of the four core values documented in The Agile Manifesto.
« We have come to value working software over comprehensive documentation. »
- Beck et al. 2001
It is also called out in three of the twelve Agile Principles:
#1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
#3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
#7 Working software is the primary measure of progress.
- Beck et al. 2001
When it comes to delivering software products, it does not matter how great your documentation is if you don't have working software. You can have the most elaborate UML models, the most well-written requirements, and the fanciest designs documents, but if your software doesn't work, none of those matters.
That’s not to say that documentation isn’t important or is never needed. In many cases, proper documentation is needed for regulatory compliance. In the case of DoD contracts, formal requirements are always required. But documentation alone won’t deliver a working product. Frequent attention should be directed toward the actual product being built — not just on supporting artifacts. Always keep your software in a working state to facilitate continuous feedback and be able to deliver functionality on demand.