Agile value: 2 – Working software

The Agile Manifesto describes four key Agile values which are expressed in pairs and each covered in separate articles:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The second is perhaps the most misunderstood of the four Agile value statements in the Agile Manifesto.  It is often read as relating to user documentation.  It is true there is a lively debate on how much user documentation is needed, and how much software should be intuitive.  However, that is not what this value is discussing.

Working software over comprehensive documentation

Manifesto for Agile Software Development

This pairing relates specifically to the development process.  In classical development, a significant effort is placed at the beginning documenting what we intend to do.  This could include plans, specifications and designs.  Classical methods might suggest that most of the work occurs at the beginning in specifying the work. 

Articles from the Project Management Institute suggest effort on a software project might break down into three sequential phases. It has been suggested that this would be 60% planning, then 10% coding and then 30% testing.  Of course, the PMI has an interest in emphasising planning. There are several implications of this breakdown

• The “coding” is a small activity which can be separated from other work.
• The work can be sequenced. Coding does not affect planning, and testing does not affect coding.
• When the requirements and design are complete, you are 60% of the way through the project.

Let us go back to the principles that we have learned for understanding Agile value.  The item on the right has value – here that is documentation.  We would be unlkiely to start work on a significant development with no idea of where we are heading.  We might typically want to know

• How this fits into our roadmap
• What value we aim to get from the work
• What we need to include to deliver that value (a high level backlog)
• How we will demonstrate success (some acceptance tests)
• What significant architectural decisions will avoid degrading the product.

However, past that basic point (which we might consider a “Definition of Ready”), introducing more documentation will not add more value.  The issue is that we are in a complex environment.  We do not know all of the answers at the beginning.  Therefore making all our decisions at the beginning is unwise.  We need to include mechanisms to accommodate change and learning as we progress.

Over-planning is potentially “waste” (and challenged by ideas like “noestimates”). To reach a high level of competence, we need to focus on change and learning.  Knowledge and creation are not independent functions, but are fundamentally linked.  Documenting what we want to do has some value.  Knowing how we are progressing however requires us to look at what we have completed, not what we have planned.

If we learn as we progress, then we must make progress in order to learn.