An Agile Acid Test
One of the problems with Agile Software Development is the lack of any rigorous tool or method for determining any given project’s agility. To some extent, this can be considered a “feature” of Agile (and not a bug) since one of the core Agile values is a preference for “individuals and interactions over processes and tools.” At the same time, when managing a large-scale agile deployment at an organizational level, or providing consulting help to a number of different teams, there arises a legitimate need to distinguish between projects that can be fairly classified as Agile vs. others that may only be aspiring to this state.
The way in which Agile Development is defined makes this somewhat difficult. At a lower level of detail, we have sources that define specific practices. However, we have multiple such sources — most notably, for Scrum and Extreme Programming — and these various sources are far from congruent. The Agile Manifesto successfully generalizes these lower-level practices into a higher-level definition, but this definition is so general as to leave it open to broad interpretation, and so offers no easy way to assure consistent application.
While I can’t claim any definitive authority for such a list, it does seem to me that there is a fairly small set of essential elements that can be used to determine whether a project is “really” Agile. So here, then, are the constituents of what I would call an “Agile Acid Test.”
The project must deliver working software to its customers on a fairly regular basis — at least once every two months.
Note that the customers may elect to defer use of a particular software release, but the delivered software must be usable.
Also note that the first release may in some cases take longer — say, up to six months — to lay the foundation for further development with a minimum useful set of features.
The project must demonstrate new or revised software to its customers on a regular basis — at least once every four weeks.
Note that, if projects are delivering working software at least every four weeks, then element 1 would also satisfy this requirement. If they are delivering less frequently, however, then they must be demonstrating software more often.
The project must work to an actively managed feature backlog.
There are several implications here:
- Project requirements are primarily defined in terms of desired software features, rather than in more abstract concepts or models.
- The backlog of feature requests must be managed as a list of items that can be individually identified and prioritized in relationship to one another.
- The list must not be frozen. Items should be added to and removed from the list as customers and developers gain more knowledge about what needs to be accomplished.
- The relative priorities of items on the list, and the sequence in which they are to be implemented, should be reviewed at least once at the beginning of each new incremental delivery cycle.
- Each feature request should be small enough to be completed within a single incremental delivery cycle.
The project must focus on fulfilling an overarching product vision.
The product vision need not be fancy, but it should be documented. Without some sort of overall vision for the product and its evolution, the project can too easily devolve into a simple aggregation of unrelated change requests, and the product can quickly become a victim of feature bloat. A product vision provides the cohesion necessary to make both the project team and the features being implemented more than just the sums of their respective parts.
The project should produce just enough documentation that is done as needed, on a just-in-time basis.
Documentation can be useful to help clarify issues before committing them to code, but it should be the software code, not a separate set of documents, that serves as the primary repository for the knowledge gained by the team over the course of the project.
The project team must regularly engage in retrospectives that help the team continuously improve their development practices.
Most team communication must happen on a direct, real-time basis, and the team must be small enough — fifteen members at the most — to allow this to be practical.
These then are what I would suggest as the essential practices of Agile software development. There are other important practices as well, of course, but I would consider those supporting practices, rather than essential ones.
As confessed above, I can offer no definitive authority for this list. But if we take a look at the elements of the Agile Manifesto, I think I can explain how these are all directly related. I’ve listed my suggestions for essential agile practices down the left side of the following table, and used succeeding columns to explain how each practice supports the Manifesto element called out in the column heading.
| Essential Practice | Uncovering better ways of developing software by doing it | Individuals and interactions over processes and tools | Working software over comprehensive documentation | Customer collaboration over contract negotiation | Responding to change over following a plan |
|---|---|---|---|---|---|
| 1. Delivery of working software at least every two months | The more frequently each delivery cycle is completed, the more rapidly the team can observe the results of their efforts and try improvements | Rapid delivery of working software reduces the need for more extensive documentation | Rapid completion of each delivery cycle allows changes to the overall delivery plan to be incorporated relatively quickly | ||
| 2. Demonstration of new or revised software at least every four weeks | The demonstration of working software is the compelling event that generates the most meaningful interaction between all the individuals involved with the project, and reduces the need for more complex processes and tools | Rapid creation and demonstration of working software reduces the need for more extensive documentation | Frequent demonstration of working software provides the most meaningful opportunities for customer collaboration, and reduces the need for contracts to specify complex statements of work | Demonstration of working software is the most reliable means of eliciting further ideas for change, and frequent demonstration opportunities provide the best means of demonstrating responsiveness to these changes | |
| 3. An actively managed feature backlog | Desired software features are topics that can generate interaction between developers and customers | Desired software features can be translated relatively easily and rapidly into working software | Customers and developers can easily collaborate on software feature requests | A list of requested features, with relatively little investment in the initial definition of each feature, is a document that lends itself to easy and rapid change | |
| 4. An overarching product vision | Without an explicit vision for the product to be developed, it is difficult to tell to what degree the team is succeeding | A compelling vision can engage both developers and customers in meaningful interaction, without the need for complex processes or tools | A compelling vision does not require comprehensive documentation, and can help shape the evolution of working software | Customers and developers are encouraged to collaborate on the means of fulfilling their common vision for the product | An overarching vision to be fulfilled is different from a detailed plan to be followed, and tactical changes can be easily accommodated without disturbing the overall vision |
| 5. Documentation that is just enough and just-in-time | Allows more time and energy to be focused on actual software development | Since documentation is a less interactive form of dialogue, minimal documentation places greater focus on real-time interaction between customers and developers | Less focus on comprehensive documentation | A contract is a complex, binding document, so minimal documentation implies less reliance on a contract, and greater reliance on direct collaboration | A smaller investment in documentation makes it easier for the development team to respond to changes |
| 6. Continuous improvement through retrospectives | Provides a forum for uncovering better ways of developing software | Provides a forum for team interactions about improvements and reduces dependence on rigid, unchanging processes | Allows the team to rapidly respond to ideas for process changes | ||
| 7. Direct, real-time team communication among no more than 15 people | Allows team members to quickly share experiences and learn from each other | Larger teams require more complex processes and tools for communication and control | Larger teams require more documentation to ensure adequate communication | Larger teams require more definitive, documented statements of work in order to keep the team on track | With larger teams, responding to change is more like turning the battleship rather than turning on a dime |
| Essential Practice | Uncovering better ways of developing software by doing it | Individuals and interactions over processes and tools | Working software over comprehensive documentation | Customer collaboration over contract negotiation | Responding to change over following a plan |
If Agile offers — as I believe it does — an approach to software development that is essentially different from others, then we owe it to ourselves to draw the line between Agile and non-Agile in such a way that the two cannot easily be confused. From my perspective, the practices I’ve listed above are all essential: if any one of them is missing, then I would suggest that a project’s approach would be better described using some other terminology.