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.

About aterny

Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
This entry was posted in Agile and tagged , , , , , , , , , . Bookmark the permalink.

4 Responses to Agile Methodology wars

  1. scottwambler says:

    Thanks for the kind words about DAD. One of the many interesting features about DAD is that it is what we call a decision process framework – it provides the guidance that teams need to choose the approach that makes the most sense for them. For example, DAD doesn’t prescribe that you manage requirements as a prioritized stack (e.g. Scrum’s product backlog) or as a pool of work items that you pull into your team as you have capacity (along the lines of Kanban). Instead DAD recommends that a team address changing stakeholder needs somehow and then describes several ways to do so (formal change management, product backlog, work item list, work item pool, or not at all) and describes the advantages and disadvantages of each approach.

  2. Pingback: I’m coming out as not-Agile and not post-Agile | Mike MacDonagh's Blog

  3. avillena says:

    IMHO the root cause is not in the Agile Manifesto. Its first line says “We ARE UNCOVERING…”, not “We just found the ultimate way…”.

    IMHO the root problem is that 1st (scrum) and 2nd wave (Kanban, Lean Startup) methods aren’t using the agile mindset in their business models.

    If agile is AFAIK about collaborative change for the better, the old-schools business model of scrum & kanban are based on defining the One-True-Way to be/do agile, as their way to bring more followers under their own umbrella.
    Any valid deviation from their One-True-Way is diminished ( “scrum-but” & “shallow kanban” are examples), confusing this adaptations with those who really “doesn’t get it”.

    This attitude is at odds with the “embrace change” and “local adaptation” from the original XP.

    My proposal? Use agile-like tools like Design Thinking and Business Model Generation to explore new ways to allow agile methodologists to thrive while being compatible with evolution and collaboration between agile branches.

  4. Hi there aterny,

    I reached this article by way of a Scott Ambler tweet. While I agree with the articles final premise that “what a lot of companies need is a ‘steer’ – some principles, a rough guide or a framework”. Yet I am somewhat shocked by and don’t know how to respond to a few of your other assertions.

    One is that, “For a lot more money (and not much else), you could be a Certified Scrum Trainer.” As a Scrum Trainer, I know from direct experience I went through a lot more than that. Some of it questioned my sanity and if I wanted to continue with the organization, and yet I persist. After being a CSM for a couple of years (1 year minimum required) I had to be a CSP and show evidence of 2,000 hours of practice, among other things. After keeping my CSP for a couple of years, I went for the CST. For that, I needed references from 5 customers, and 5 existing CSTs. I also had to demonstrate contribution in the community, show materials, and proof of 3 co-trainings with other CSTs. Both of those processes continue to be tuned. Here are the current incarnations:
    and CST

    Do you think this qualifies as “not much else” than a bunch of money?

    Another one you mentioned is that, “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”. The thing is, in February Gojko invited some people together to talk exactly about what we hold in common as our values.
    Here’s a short summary from Henrik

    and some more from Gojko

    Can you help me see how this is muddying the waters?

    Thank you,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s