I’m offering up this diagram as “the world of Agile Software Development according to Craig.” Let me know what you think.

One of the principles of Agile development is known as “Simple, Emergent Design.” And one of the ways to know if you have achieved a simple design is if the entire system can be diagrammed on a single sheet of paper — no matter how involved and feature-filled the system becomes — by applying the proper level of abstraction. (Note: It’s not unreasonable for parts of the diagram to be black boxes representing sub-systems, each of which have their own single-sheet diagram.)

A while ago, I took it as a challenge to try to describe the world of Agile development, itself, using such a single-sheet diagram. It’s been attempted before. Try googling “scrum diagram” or “agile diagram” and you’ll find more than a few. Most of them do a pretty good job of illustrating the mechanics of Agile development, or of Scrum, in particular. But I found that they failed to address some of the fundamental questions that I often get asked…

1. Where should we start to become agile?
2. How are we doing so far in becoming agile?
3. Why are  we being asked to do certain practices?
4. How do the technical-level practices and principles tie in with the business-level practices and principles?
5. Why aren’t we seeing dramatic results yet? Where are those big gains in productivity you promised us?

Well, without further ado, here is the chart that I came up with. (Click on the image above to download a PDF. It’s meant to be printed on legal-size paper, but can easily be reduced to letter size.)

As you can see by the legend at the bottom, an arrowhead means “depends on.” For example, I’ve declared that the practice of “Frequent Refactoring” has three dependencies: refactoring tools, first principles, and automated unit tests. It’s my contention that unless and until a development team gets good as using/doing all three of those dependencies, there should be no expectation that frequent refactoring will occur. Furthermore, there should be no expectation of anything else that depends on the frequent refactoring, nor anything that depends on that, ad infinitum.

And, here’s how I use this diagram to answer those fundamental questions…

1. Where should we start to become agile? Start at the “leaf nodes” of the diagram. For the developers, this means automated tests, GRASP, etc. For project management, this means having well-defined done states (acceptance criteria), cross-functional teams with embedded product ownership representation, etc.. And, for both, it means writing stories that follow the INVEST mnemonic.
2. How are we doing so far in becoming agile? Put a checkmark next to every practice and principle on the chart that you are performing well.
3. Why are  we being asked to do certain practices? Since the arrowheads point to dependencies, the arrow tails point to the reasons. For example, the reason we want our stories to follow the INVEST mnemonic, is that it enables discussions of clear business value and honest developer estimates, which, in turn, enables a sustainable pace.
4. How do the technical-level practices and principles tie in with the business-level practices and principles?For the most part, the business-level practices and principles depend on the technical-level practices and principles. Which is not to say that the responsibility and burdon for becoming agile rests entirely with the developers. On the contrary, both sides have to pull their weight before Agility can be realized.
5. Why aren’t we seeing dramatic results yet? Where are those big gains in productivity you promised us? Patience, please. Certain practices offer innate gains, but this is definitely a case of the whole being (much) bigger than the sum of its parts. The magic doesn’t happen until you can honestly place checkmarks next to all three of the yellow ovals (Technical Maturity, Project Management Maturity, and ROI focus).