How Agile Goes Bad: Blame and Options
How Agile Goes Bad: Blame and Options
When Agile projects stray, the temptation is to blame the method rather than working with it. Here's how to get back on track.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
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 a person's lack of a clear protocol for dealing with challenging issues. This 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 — 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 organization's 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!
Published at DZone with permission of Bob Hartman . See the original article here.
Opinions expressed by DZone contributors are their own.