People often ask me, “When is agile right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.
That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.
I had a coaching conversation recently. My client has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.
His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.
The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:
- Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
- Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
- Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)
If you work in an agile organization, you know the problems with these assumptions.
Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.
Remember, Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.
Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.
I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.
I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:
- Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
- Do a simulation with management to have them feel what agile is like.
- Explain the system of agile and how the ideas that management have is not helpful.
- Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.
Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.
Remember, agile is a cultural change, not merely a project management framework. Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.
Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.
| Reference: | When is Agile Wrong for You? from our JCG partner Johanna Rothman at the Managing Product Development blog. |
