Transformation Journeys
I was talking with a customer today about a transformation. Like most folks, they wanted to know what the start of their transformation journey would look like. That’s usually a pretty easy question to answer. I might suggest that we start with basic agile training for the leadership team, then engage with them to co-train the teams in work groups. Maybe we work with product and other teams to help get them engaged. I might even suggest chartering and kickoff events of one kind or another. It’s all pretty standard stuff, but it usually ends with “…and then you advance from there.”
There’s nothing wrong with that. We don’t really know where a given customer will take their transformation once we, as consultants, have left the building. However, it doesn’t give people much of an idea of what comes next. In fact, it does nothing at all. It strikes me that we as an agile community have collectively acquired enough experience with agile transformations that we can start to articulate at least rough trajectories of agile transformations.
Here are a few transformation journeys that immediately occur to me:
The Pendulum – You adopt an agile framework, run into impediments, pain, etc. and drop the framework. Then you realize that you need agile, so you start all over again and adopt another agile framework. Rinse and repeat.
The Requirements Black Hole – you like the new agile process, but you missed a few things in your last plan. So you add more process to catch those things in planning next time. But you miss a few details next time, so you add some more process. Repeat until the requirements process becomes so inconceivably heavyweight that not even light can escape the organizational event horizon.
Spotification Syndrome – You want to skip the learning bit and just use a successful system that someone else has already taken the time to invent. You change all the names of your process artifacts to match (Let’s call them tribes!). Of course, nothing meaningful beyond the names have changed, so there is no real change.
De-scaling – Maybe you adopt a framework and that was an improvement over the chaos you had before. Now, based on thoughtful experiments, we continue to remove processes rather than add it. Ultimately we have a unique, very lightweight framework that works the most efficiently for our culture.
The Inverted Bureaucratic Pyramid – We slap additional roles and processes on the organization. This has the consequence of creating an army of new managers and middle managers. The organizational hierarchy balloons, with there being more roles than people actually doing the work.
Bright Shiny Frameworks – We start with one manager attending a certification class for a framework. He comes back and pitches the new dream framework to the organization which decides to adopt it. They get into it for a year or two and realize that they still have problems, so they send a manager to another framework certification. They come back and pitch the new dream framework…ad nauseaum.
Fossilized – We adopt a framework and never change again. Ever.
None of these is guaranteed, but I’m sure folks have seen varieties like these. Looking at the list now, I’m a little disappointed that I didn’t have more success scenarios. I must be feeling a little cynical today. I’m sure there are many more (and I’d love to hear what you think they are).
I think we need to pay more attention to describing what the journey might look like for our customers long after we have left (both good and bad). It could give us a sort of pattern language to describe the challenges that they will face down the road on their own agile journey and help them to make better decisions, or at least better informed decisions, when the time comes.