Surviving a transition to Agile methodology - Part One, Defining the Problem

Greetings all,

There are tons of books, courses, blog posts, and probably YouTube videos about how to convert your organization to Agile, but I don't recall seeing many (any?) that talk about how to deal with the pitfalls of such a transition and how to survive them.

The most common issue is that many conversions to Agile are driven from below, as the developers decide that they need to stop doing things the Bad Old Way and get on this Agile train, and this means that they have to convince Upper Management to convert.

This typically fails.

If your Upper Management does not buy into Agile, they will drag their wingtip-shod feet at every point, question every Agile tenet, and resist.

However, this is not my topic - I'm assuming that your Upper Management has either agreed to convert the organisation, or perhaps is insisting that the organization convert - one of the C-levels probably read about Agile in the trade press and wants to get ahead of this new thing.

While this might seem good, it is still dangerous.  The parts of the organization that deal with customers will have to sell the concept to the customers, and that leads into a swamp of problems - the customer doesn't want to allocate resources to work daily/weekly on the scrums; the customer does not want to agree to anything less than a full solution in X months, bound up in a bulletproof contract with penalties for late delivery; and so on.

Then you find that most of the non-development part of the organization doesn't want to spend all of its time thinking about the stuff currently being made, and would rather move on to the next thing, so you can't get the answers you need, or they want to keep using the old waterfall process documentation ("Just write the whole thing out, and you can modify it if you run into anything that changes")

Next in line is typically the old chesnut that Agile will let the organization develop code faster.  Management sees the promise of a faster acceptable product as meaning faster coding, ignoring the parts that mention writing test code, spike solutions, refactoring, and all the rest of the things that mean you will not be writing anything faster from a code perspective.

Moving along, we come to the Misuse of Metrics, in which Upper Management starts to use the team metrics (velocity, number of user stories completed, etc) as part of the performance review process for the developers.  This is usually fatally toxic to Agile adoption, in that the developers naturally become more concerned with saving their jobs by tweaking their teams' numbers to look good.

And tagging along at the caboose of this trainwreck is the expectation that it will go smoothly from the start.  Upper Management, after a sprint or two will realize that often the forward progress is slower than before, so they will begin to "help" by changing things up - reorganizing teams, taking personal interest in the prioritizing of User Stories and tasks, etc.

Now, it's fairly common knowledge in the Agile world that organizations can have pockets of resistance to the conversion, but much of the remedies are on the order of "Give your CTO a stern look and tell him that's not how Agile works", which is hardly helpful at either changing the organization or staying gainfully employed.

In part two, I'll explain some of the things a good Software Ninja can do to survive the whole mess.