Agile Methodology wars

Methodology (n) 1. The system of methods and principles used in a particular discipline. 2. The branch of philosophy concerned with the science of method and procedure. 3. An organised, documented set of procedures and guidelines for one or more phases of the software development lifecycle. 4. A pretentious way of saying Method.

Since 2001, when the Agile Manifesto was published, “Agile” adoption has grown steadily worldwide, to the point where, in 2009, Gartner declared “agile is now mainstream”.

But what, indeed, IS Agile? There are different views on this, but Agile does not necessarily mean Extreme Programming (XP). It doesn’t necessarily mean Scrum either. Lean/Kanban? Nope. DSDM? No, not that either. Fundamentally, Agile IS the manifesto and the underlying principles. It is, as Alistair Cockburn says, about Self-Discipline, Self-Organisation and Self-Awareness. It’s not about what you do, but about how you do it. In other words, it’s not about the Method.
Alistair spoke at the Agile2009 conference about the need to view Agile in the context of the larger landscape in which it now sits. Agile needs to be scalable, and for some companies that is proving difficult. And the larger you grow and the bigger your agile projects, the more you need formality, structure and governance. In other words, Method. That does not, however, mean abandoning anything in the Manifesto.

Agile originated in the context of small, co-located, cross-functional teams. That Agile principles and practices are now being used in thousands of organisations worldwide at a scale possibly never imagined by the original authors is a Good Thing, and a testament to the inherent ‘rightness’ of the thinking that went into the Manifesto. But Scrum (on its own) doesn’t scale. A large organisation embarking on a 5-year, $155m program with a couple of hundred people involved across ten countries cannot rely on Scrum alone. But that does not mean they cannot be Agile. Far from it.

Scrum lacks the Project view (search the Scrum Guide for the word “Project” and, as a noun, it is used only once : “Each Sprint may be considered a project with no more than a one-month horizon”). Scrum is not designed to work in a project (“a temporary endeavour undertaken to create a unique product, service or result”) environment, as it does not consider team-building, requirements generation, architectural design, high-level planning, etc, etc. It lacks Programme, Portfolio and Enterprise Architecture views. Oh, and before the Scrum people jump down my throat, I must clarify that XP, Kanban and DSDM don’t consider all these views either. DSDM goes one step further than Scrum with its focus on Projects and just enough high-level up-front planning, but still, there is stuff missing.

Clearly, Agile has for a long time now, required a wider view of the world, to put the iterative development cycles into an Enterprise context. Scott Ambler developed the Disciplined Agile Delivery (DAD) framework and the SDCF and Dean Leffingwell is constantly evolving the Scaled Agile Framework (SAFe), both of which attempt to illustrate this big picture in an agile context, creating the environment in which development teams can thrive down at the Sprint/Iteration/Timebox level.

While I will leave you to read about both of these at your leisure (if you haven’t already), I was rather surprised to read that Ken Schwaber, no less, has had a little rant at SAFe, although not so much about the approach, but “turning that and RUP into a product and [licencing] people to implement it”; people “touting their processes and tools” at Agile2013. Ken’s objection is that “they are now pushing SAFe as a simple, one-size fits all approach to the agile organisation.”

This criticism of the commoditisation of Agile has already been levelled at Scrum. After all, how much knowledge and experience does it take to become a Certified Scrum Master? Two days and under £1000. For a lot more money (and not much else), you could be a Certified Scrum Trainer. Mind you, it takes only a week (and a heap more money) to be certified in PRINCE2, so this is nothing new. An entire industry has been created to provide training, coaching and transformation consultancy to companies small and large. Agile IS a commodity, and a lucrative one for some.

Quite frankly, this is all starting to sound a little like Methodology Wars. And it needs to stop. The Manifesto and the vast quantity of excellent publications by notable authors like Mike Cohn, David J Anderson, Tom and Mary Poppendieck, Gojko Adzic and many others are muddying the waters for those still trying to find out what the actual heck Agile really is. Yes, we do value individuals and interactions over processes and tools, but frankly, a little process now and again is also a good thing. And we need a little framework in our lives when we want something to act as the basis for setting up our whole organisation to be properly agile.

I think what a lot of companies need is a ‘steer’ – some principles, a rough guide or a framework, that will help them deal with all those things that are necessary for a Scrum (or XP or DSDM) team to thrive in a large and complex organisation. Things like Governance, like Portfolio, Programme and Project management, like HR, resourcing, organisational structure, empowerment, enterprise architecture, etc etc.

Perhaps the time has come for another gathering of the good and the great agilists to agree a new Manifesto – the Enterprise Agile Manifesto, or the Agile at Scale Manifesto. It might not even take three days.