The most important part of the Agile Manifesto is the
uncovering better ways of developing software part, not the 4 comparisons.
I regularly read tweets and blogposts that claim that if you’re not doing this practise, or that one, you’re not doing Agile. That you’re half-arsed and half-way to Gartner and Dilbert. That a well-refactored method is like a zen garden. That iterations are better than flow (and vice versa) and in all cases, anyone in possession of a Gantt Chart is to be cast out like Lizzie Proctor for having supped with the devil. That the Scrum Ceremonies ritually purify the soul in preparation for casting code upon the waters.
I can’t count the number of Agile Introductory Workshops that I’ve seen founding its approach on the Agile Manifesto, taking time to dwell on the four comparisons, inviting participants to meditate on how doing the items on the left that might impact how work has progressed until now. Or on Agile’s people-based culture and how that’s a revolution to many commercial organisations.
Even the better workshops that point out the very balanced nature of the whole comparison (which is that there is value in the items on the right too, even while accepting that it’s less) seem to me to be missing the point. It seems to me a really strong echo of what I remember reading once about Toyota’s Management System: what we know and love as Lean – single piece flow, kanban, JIT, Jidoka, Poka-Yoke and all the rest – are simply a set of countermeasures within an ongoing cycle of continuous improvement. They may be the best way so far found, but that if Toyota found a better way, all of it would be swept away in a heartbeat.
So the four comparisons, and the Twelve Principles of Agile Software, similarly feel to me like
the best way we currently know, and the language of the preamble comes close to saying so explicitly:
we have come to value…
So what is the heart of Agile? The thing that drives the engine and leads us to valuing some approaches over others? To my thinking, it’s this:
We are uncovering better ways of developing
software by doing it and helping others do it.
Within that, there are 5 key things:
- An implicit dissatisfaction with the status quo
- A dedication to not only find better ways but to continue to do so
- A bias towards action and empiricism: how do we know it’s A Better Way? We use it
- A willingness to put ourselves on the line — to uncover better ways in our own real work, not just through publishing theory
- A directive to sharing and re-investment back into the profession to maximise the impact of better
Powerful stuff in only 16 words. Nothing about being responsive. Nothing about iterations. Nothing even about what ‘better’ means.
I believe that staying true to these driving forces is the perennial hallmark of the Agile mindset and community. The rest will come and go, evolving and contextualising, and should change as and when we uncover what better ways are in every situation we find.