Making Agile “work”

Tom Breur

16 February 2014

The “promise” of Agile was, and –I believe– still is, that by embracing a ‘better’ approach to software development, we would increase knowledge worker productivity. I will leave in the middle here, whether “Agile” is, in fact, a “methodology”, or not. If you are interested in that discussion, Alistair Cockburn wrote an insightful piece discussing that topic.

Improvement implies change. You can hardly expect superior results, and expect to get there without changing a single thing. Popular belief has it, that “something has to give” – there is no such thing as a free lunch. Jay Forrester once pointed out to me, that if you want to change a system, it is easy to point to what needs to improve. What is more important, though, is to point to things that should worsen as a result of the change.

What I have noticed as an Agile coach, is that implementing Scrum invariably triggers considerable resistance. I have always attributed this to the need to change some of the existing roles, like “line manager, or “project manager”, both are likely to be affected by a transition to Scrum.

In contrast with that, implementing Kanban seems much “smoother” – you start by ‘innocently’ recording current practices, and then make piecemeal changes accordingly. What may not be “innocent”, though, is reporting on the findings of effectiveness of current practices. The end-to-end value creation often is shockingly missing.

When you begin to spread insight on effectiveness, this may cause serious disruption. The CDE model can be a powerful tool to surface the “hidden” impact of information exchange. “Merely” adding an information loop, can have a dramatic impact on a complex system.

David Anderson seems to have noticed something similar, judging from his remarks on page xviii in “Lessons in Agile Management”, where he writes: “The Kanban framework -despite the explicit acknowledgement of uncertainty- fits in with "traditional" management a lot easier than Scrum/Agile, which makes adoption a lot less traumatic.” Comparing the two is a bit likes apples and oranges, because Scrum is a process framework while the Kanban Method is a process improvement framework.

So if you are still “on the fence” as to where to begin your Agile journey, why not start by ‘innocently’ recording current practices in Kanban style?