Lean and Agile

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.”

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. The project team must regularly engage in retrospectives that help the team continuously improve their development practices.

7. 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.

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.

July 20, 2009

Next: Process, Projects and Customers -- The Unholy Trinity