How Agile Goes Bad, Blame, and Options [Agile Safari]

Tweet this Agile Safari Cartoon!

Does this sound familiar? We have someone asking the obvious question. “Why would we say we will do something we know we can’t accomplish?” When we hear these questions, too often, we have no mechanism to deal with them. We have not created a protocol to deal with these common situations that always occur. This type of problem needs to be dealt with as soon as it comes up. In the cartoon, I’m talking about creating an agile organization, but it is hard to imagine in any organization that you would want people to just make things up.

How Agile Goes Bad

There are a number of ways agile can go bad. A very common way is people’s lack of a clear protocol for dealing with challenging issues.The causes people to avoid having conversations about them.

People leave training excited (if the training was good) and ready to start! Perhaps there are people who are not even totally on board yet, but willing to at least try. You might have a few that are thinking it will not work. That’s all good. People are different and not everyone will just change because someone says to do it (in fact, if suddenly everyone agrees to a major change and there is not concern — I’d be worried there was a lot not being said.

Then, the turn happens — when an organization, team, or individual goes from believing agile can work to believing it’s a farce. It happens quickly. And, it also happens quietly.

There is one conversation like this cartoon, perhaps even said sarcastically. Then there is another. One team member becomes infected with the belief that management just doesn’t care. Then a second team member, then a team. One team falls. Then another. It’s a sad state really.  Suddenly, the punch line is true. Game over. Many people will leave. Some will now think agile actually is a farce, many will be less engaged. Blah!!

There is not just one cause. Saying people believe that management does not care is one thing (notice I said ‘the belief’ above, not ‘the fact’), but do they really not care? Does a VP really believe anyone would or should just commit to something that they have no knowledge about? Would the VP commit? Would anyone want to rationally argue that point? Sure, maybe they are irrational, but what I see frequently, is that the VP (or project manager, product owner, team member, CEO, manager, director, or human) is not in touch enough with the other people involved to understand their point and simply don’t have the rapport to engage in a discussion to understand and learn.

Any organization wide initiative requires transparency for it to succeed. It also requires considering how you want to behave and act when things don’t align with your goal. A scrum team is supposed to commit to work based on what they believe they can complete in an iteration. If they are committing to work that they know they can’t achieve, that is a problem. It is a common problem and one reason why some people say “agile and scrum are bad.” Some say they are just different ways to get people to work nights and weekends, since “they” committed to getting the work down. Of course, agile also talks about a sustainable pace — nights and weekends are not sustainable (in fact they typically result in less productivity (check out Pig & Chicken Part 3 for more on these ideas).

Who Do we Blame?

There are so many options!

  • Blame the Team: Blaming the team is a solid approach. I mean, they are the ones committing right — and if they are too weak to speak up, they get what they deserve!
  • Blame the Executives or Managers: Blaming them is another terrific option. Why not blame the bozos ‘in charge!’ They are obviously pressuring the team and are a bunch of clowns with big egos that do not understand real work!
  • Blame the Scrum Master: This has to be a top contender! If only the Scrum Master would have told us, then we would be able to address the issue. They must have saw the issue and did not do anything about it! Idiots!
  • Blame the external Agile Coach: Winner Winner Chicken Dinner! This is the best yet. I mean, they are external. They are a great target. In fact, you might consider hiring one simply to blame! These fancy-pants agile coaches flying around the country doing agile transformations… they should CERTAINLY know better!
  • Blame the Culture: One of my favorites!  It must be the culture! It’s just the kind of place we work! It’s just like that here! This is such a great choice cause we do not have to point out a person or even group of people, we can just more or less say the whole place stinks!

Blame whoever you want… it will not change the reality that blame just puts you in a place where you have no power. If it is someone else’s fault, then you should just sit down and wait for someone else to fix it. Wait for someone that might have the answer. For most people I know, that is not sufficient.

What Can You Do?

What are the organizations goals. Do they want to actually use agile to deliver more value? To compete more effectively? To foster innovation and creativity? To create an organization where people enjoy working?

If you are aiming for these ideas, then accepting the premise in the cartoon is just not something you should be okay with. That said, what can you do? You can start by having a conversation about this article. Seriously — HAVE THE CONVERSATION.

You might just print this article or the cartoon and leave it on someones desk without a note if you are concerned with the response, although I guess if you did that and someone did not like it, they might just call me. But ya-know, I’m okay with that — it would actually be an interesting call!

What you want to aim for in the conversation, is to find out what everyone wants to do when something like this occurs. Then write the ideas down and create a protocol to address these issues.

  • Ask: If the team feels like they are forced to commit to something that is impossible, how will they want to act? What will they want to do?
  • Ask: If management believes the team is not being honest about what they can get done, how will they want to act? What will they want to do?
  • Ask: If the Scrum Master sees an issue developing that no one is sharing, how will they be? How will they act? What will they do?

Of course anyone might say, “we want to act really mad and frustrated and we will throw chairs around the office.” That might be what they initially want to do. What will they do when they think about it for a moment? What would be productive to move forward? If their aspiration is to throw chairs, well, it’s not a total loss, at least you know where you are and what you need to work on.

Have these conversations and agree on your protocol. You can obviously ask even more questions, but the core of the questions is to identify the behavior you want to model and to consider how you want to be when an issues comes up. If you have never discussed how you will address these when they come up (or some variation does) your chances of successfully dealing with them decreases and your risks increase.

If you attempt to have these conversations or even talk about having them and people start freaking out, you are probably on to something!

If you are still looking for more, take a look at Agile Leadership – an in depth coach training course for leaders, managers, and agile coaches! Learn how to help teams advance on their journey to high performance and tackle major agile myths.

Share

3 thoughts on “How Agile Goes Bad, Blame, and Options [Agile Safari]”

  1. Howdy Jake, unfortunately I attended a very well organized and well conducted User Story Agile approach for a development project that went South for 1 person (me) for the very reason you have posted on this article (very well done article I’d like to add). Yes, I made the mistake of mentioning the Elephant in the room and it cost me my job. I have been on several User Story oriented gigs and the process is used for project manipulation instead of project management. I like the User Story process because it makes the developers perspective of what to do very atomic and legacy or disparate systems become black boxes making life much easier. However, when the real goal is to introduce a large chunk of ‘How’ displacing the ‘What’ and someone brings this move into question destroys all the work the agile team put into the User Story writing process and the ‘Bad Guy’ gets fired.

    Reply
    • David, sounds like a tough one. Often I find that when that happens, it turns out to a blessing in disguise, even though it rarely seems like it at the time! Sometimes we have to be the one to bring up the issues, even when unpopular and then deal with the fallout. So, maybe it was a mistake to bring it up, I certainly don’t know the details, but the first thought I had when reading your comment was “that is awesome that he spoke up!” Keep bring up the tough issues!

      Reply
  2. Great text, Jake! 🙂 I’d say that blaming the culture happens quite often especially when the team members change. These who don’t understand it or don’t feel comfortable enough yet start to say sth like ‘this culture’s so baaad, agile’s bad’. Of course, there may be met some ‘bad’ Agility actions (like these mentioned http://kanbantool.com/blog/good-and-bad-agile-development-practices here) but blaming the whole culture’s the easiest generalization that can be made – and, I think, it’s often used.
    Anyway, ‘have a conversation’ is the base of Agility. The base definitely more difficult than blaming others and, as it happens with these wiser solutions, often forgotten.

    Reply

Leave a Comment