Summary of Sabotaging an Agile Transformation
by Fred George:
Agile companies are 4x better. One metric of agility is how fast a change can be made to the codebase, from checking out, designing, implementing, testing and committing. This should be 15 min-2 hours, no longer. Another metric is how many releases are made, which increased from 14/year to 3000/4 months as a result of transforming the company to be agile.
In many cases, the people in the company sabotage the agile transformation the company is ostensibly working towards. Even after the transformation succeeds, when the consultant leaves, companies often revert to their earlier way of working. How do you prevent sabotage?
Continuous CxO involvement: Sell the benefits of the transformation to CxOs. Keep talking to them regularly and telling them what’s going to happen next. This matters because people in the organization will keep approaching the CxOs with their complaints. If the CxO is aware of what’s happening and has bought in to transformation, he’ll defend it, and the complainers will have nowhere to go.
You can’t convince everyone: Stalin had an interesting way of dealing with people who disagreed: he wouldn’t try to argue with them, because he knew they wouldn’t be convinced. Instead, he’d reach agreement with the others, isolate the dissident, and then have him executed. Similarly, you can’t convince everyone. If someone is coming after you or irritating you, don’t confront them. Sideline them. The great insult you can give to an enemy is ignoring them. If they’re pissed, it’s a good thing, because they’ll then do stupid things and consequently lose credibility. Work with the believers rather than trying to convince dissidents.
Use the sandwich strategy: Middle managers (which includes architects, architecture review boards and people who ensure compliance with some standard like web services) can’t be convinced, despite both Fred and Kent Beck trying various approaches over the years. They’re excessively risk-averse. They view any change as a risk. Since you can’t convince them, you should sideline them. Or get them fired, as Fred did in one gig. Get buy-in from CxOs (see earlier point). Then sell the transformation to the individual engineers. Then, ignore the middle managers — when they run to the execs, the execs will defend you.
Anyone who loses power will resist change: It could be people who approve releases, architecture, standards or other things. Anyone who is no longer playing a central role after the agile transformation sabotages the agile transformation, such as by minimizing your accomplishments, or saying it won’t work here.
To be a change agent, you have to be a tyrant, and tyrants are always shot: As you work, a counter-culture develops against you. In 6 months, it will become strong enough that you’ll be fired.
Success conservatism: Once you create a high-performance team, the manager who owns the team might tell you that things are good enough and you need to stop making further changes. When Covid struck and demand increased many-fold, Fred spun off a small team to build a new service in four days. After that, they never spun off another team to deal with new challenges. Once you succeed, managers don’t want further change. If you build a powerful engine, they won’t let it do what it can; they’ll lock it down.
Seating together: Seat people working on the same project together, not all the engineers across teams in one place, all the designers across teams in another place, all the PMs across in a third place, etc. The chance of two people talking varies as the square of the distance between them.
“Experiments”: If someone objects to your change, call it an experiment. Nobody wants to be unreasonable and reject an experiment. In fact, someone may say we don’t want to do it as an experiment, and you’ve gotten the buy-in for the permanent change.
Keep the businesspeople away from the engineers, or they’ll waste the engineers’ time and keep distracting them every few days with something or the other.
Reference other people: If you want to convince a developer about your change, ask him to talk to another developer who works in an agile way. Developers listen to other developers, and CIOs to other CIOs, not to whitepapers or presentations.