Last week I came across a post by my friend Kelly Waters, in which he bemoaned the many competing Agile methodologies, and said that he thought “the best advice is to go back to basics and apply those basic principles without layering over them a whole tonne of processes“. I agreed, but didn’t add my comment to the thread because it already consisted entirely of “me too”s, and I thought one more wouldn’t really add much value.
However, the fact that there was (at that point) 100% percent unquestioning agreement got me thinking. Don’t grassroots Agilists—i.e. those who advocate developing an Agile approach organically—think there is any merit in off-the-shelf Agile methodologies and frameworks? I can think of two good things they bring.
First, they ask and answer a lot of questions. When starting out in Agile there are a lot of questions that one might consider, and many people will forget to consider them. For example, one could ask: What roles should we have? How should they interlink? How should we prioritise? How should I co-ordinate dependencies, needs and questions across multiple teams? And so on. An experienced individual might consider most of these, but many might not.
Lots of Agile methodologies and framework ask and answer these questions, so they’re potentially useful to compare against any working practices that we may devise ourselves. For example, we might look at SAFe, notice that it advocates all our teams working in sync, and ask ourselves if we should consider doing that.
Of course, there is a flipside to this. The various Agile methodologies and frameworks also provide standard answers to these questions. And that’s where trouble can occur, which Kelly highlights: “I have always believed that one size fits all doesn’t work“. It’s easy to take an off-the-shelf methodology and apply it without thought. Varying a standard methodology or framework is sensible (if not essential), but that step is often forgotten or resisted.
A second benefit of off-the-shelf Agile methodologies and frameworks is that each one provides a common language. This is particularly useful in large organisations. I’ve seen organisations were different areas have different roles with the same label, or the same role with different labels. It causes a lot of confusion, delay and—sometimes—conflict. This has come about because the different areas were given the freedom to explore and implement Agile in ways that suited them.
Again, this second benefit is not problem-free. After all, we can debate who should define a common language, and we can debate whether such top-down or committee-led implementations of Agile (which this implies) are appropriate for one or any organisation.
But those problems are not the point.
As I said at the start, I do favour the view of Kelly and many others that the ideal way to introduce Agile is through learning the core principles and developing what is appropriate for that situation. But at the same time let’s not pretend that off-the-shelf approaches are entirely without merit. And sometimes (whisper it) there might even be circumstances where implementing such an approach might actually be the best way forward.
niksilver.com 