When is Agile Wrong for You?

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 ( 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.

Tags: , , , , , , ,
Previous/Next Posts
« »

5 Comments

  1. Gil Broza

    Hi Johanna,

    Great post! We need more posts like this one (not that it’s your first on the topic ;-))

    You said: “Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.” The sticking point is what those “ideas of agile” are. Too many people equate ideas with practices, tools, artifacts, and meetings — the visible mechanics that yield results. What I think you meant (and I do too) is the higher-concept ideas are higher concepts: principles and values. When people flock to one of the popular Agile frameworks, they often miss those concepts, or never get to learn about them.

    Gil

    Reply
  2. Berthold

    The last and second-to-last paragraph have a duplicate sentence. Other than that, excellent insight. Thank you. I like to work in guerilla environments, working from the inside out, but not everybody is build for that kind of friction, even if it’s made clear from the outset we won’t have smooth sailing.

    Reply
    • johanna

      Berthold, thank you. I fixed the post.

      I am of two minds about guerilla approaches. I use the inside-out approach. And, there are times when the teams are ready to do more and the management culture will not let them. That leads to a ton of internal friction. Often, good people leave.

      As a consultant, I want to make sure I am helping my client. My client might be a specific manager/group/product line, and they want this turmoil. And, if my client is one manager who does not have the influence, and I can’t help that person become more influential, I ask if they want this. Especially when they can use evolution, not revolution.

      I don’t think there is a clear answer. To me, it’s about seeing the context and asking what makes sense now, for these people.

      Reply
      • Berthold

        To be sure, I’m a fan of evolution over revolution. Revolutions tend to bring out more friction than the organisation can bear, grinding to a near standstill. Few companies have the resources to weather this kind of impact, and it’s no fun for anybody. But measured, small seeds sown and nurtured can satisfy both the need to get better as well as the need to not lose control completely. Especially if you track first and improve later, so the changes become apparent.

        Reply

Trackbacks/Pingbacks

  1. The Case For and Against Estimates: Part 4 – Technology Up2date - […] In projects, we need to decide where to spend our time. In agile and lean projects, we limit the…

Submit a Comment

Your email address will not be published. Required fields are marked *