The Fallacy of Agile Transformation

Last summer, I attended Agile 2013 in Nashville. Many of the talks were focused around the idea of “agile transformation,” where an organization following a traditional waterfall software development process switches to an agile methodology, almost always Scrum.

But how does this occur? Does it start small, from the bottom up, and evolve gradually over time? Not usually, or at least organizations following this approach aren’t talking loudly about it.

Instead what seems to happen frequently is that a leader in the organization, presumably fed up with late deliveries, cost overruns, or other issues where the blame could be pinned on the software development methodology, decides that it’s time to get with the times and “Go Agile!” They then seek out a new tool and its associated training to roll it out to their teams as if it were a new time card entry system.

At its worst, it all goes nowhere, vast amounts of time and money are wasted, and the “forward-thinking” leader is eventually thrown out along with their tools. People doing actual work learn the lesson that change is bad.

When it’s called a success, what happens is that teams adopt some of the popular practices, like standups, and they use new terminology. However, since they were told of the new way to work, rather than working it out on their own, they seldom internalize the underlying values. When they run into trouble, they assume they must be doing the sanctioned process wrong and seek out process-oriented solutions from external sources of information.

So if the results of these transformations are not usually ideal, why do organizations follow this approach? It seems to me that the people who conceive of and orchestrate the transformation treat the entire undertaking like a waterfall project, because that’s the world they know. They create a plan, mandate a particular process and/or tool, and set a date for completion. The alternative, empowering their teams to change the way the work and improve over time would take an uncertain amount of time with uncertain results.

As an example, there was an idea board posted that asked attendees to complete the sentence: “Agile will fail at my organization because…”

An organization who has realized that predictive approaches have limitations and decided to experiment in more adaptive ways of building software would not frame the question this way. A team that is learning how to be better every day as it incrementally delivers value is already succeeding, whether they are on day one or five years into their journey.