Agile Adoption, Part 4 – When do things go wrong?

If you’ve been reading my previous blogs on Agile Adoption, you know that I have already talked quite a bit on how to start going agile, and why the way you introduce it matters. If you haven’t been reading the blog series, I encourage you to look at Part 2 and Part 3 for more details on the challenges of introducing agile to an organization. You can always start at the beginning as well. In this blog post, I will talk about when new agile projects run into challenges – at the beginning, in the middle, and at the end.

In the beginning
Suffice it to say, there are a number of things that can go wrong at the beginning of an agile adoption, including (but not limited to):

Silver Bullet – Agile will solve all our problems!
This often happens in organizations where they are doing a Top Down implementation of agile. Someone in upper management read an article or attended a workshop and decided that going agile would make everything better. While agile can solve some problems, what it is more likely to do is expose your real problems sooner. This can leave teams discouraged and overwhelmed, instead of empowered and energized.

Flavor of the Month – Agile is just another new fad, it won’t really help us.
This issue comes up with teams that have been through too many management fads and changes. They have seen new initiatives come and go, and in their experience everyone gets excited for a few months, then things go back to normal. This type of team will need to see real change and progress happen quickly, as well as over the long term, before they come around to the idea of adopting agile for good.

Read the book and be Agile! – Not getting enough support
When teams are thrust into the world of agile without enough training and support, things can go downhill fast. Change is difficult, and people can easily become overwhelmed with trying to do too much too quickly. A good coach will help teams who are new to agile adopt practices in a way that makes sense for them, adding value rather than adding new rules to follow.

As I mentioned before, how you go about implementing agile matters, both from the perspective of how it is positioned to the teams, and in terms of the level of support you provide for your teams. Since I’ve already covered much of that in earlier posts, let’s assume that you have gotten off to a good start with implementing agile and want to know when to expect challenges moving forward.

In the middle
Often once the initial hurdles of adopting agile are overcome, things start going well and the team becomes more comfortable with this new way of working. And then, something happens. It could be a technology problem, or a requirements issue, or something with team dynamics. While I don’t know what bump in the road your team will encounter, I do know that these bumps in the road are normal. Unfortunately, this is the point where people start to worry, panic, and blame agile.

Teams tend to start worrying when stories aren’t getting done, or when a big technology challenge arises. Teams start to worry more if management challenges the agile approach, or wants to know why we can’t tell them when the project will be done, or what the final product will look like. Usually the panic happens when agile exposes the real project problems.

To be clear, it isn’t that agile created these project problems. They were here all along, but were often buried under the usual project planning and execution. But with agile, all of the project problems and issues are exposed as part of the transparent nature of agile projects. Even thought that level of transparency can be pretty painful at first, it is also part of what allows us to fail fast with agile, and iterate and improve. Once you can see the problems, fixing them becomes a much higher priority than when they were buried under the usual project overhead.

The biggest challenge with these middle of the project issues is that they frequently coincide with people falling back on old habits. Change is difficult and people often revert back to what they know and are familiar with. That is why it is so important to having ongoing support for your agile adoption, either in the form of internal champions or external coaches, because they have seen the pattern before and can provide different strategies for how to overcome your team’s particular challenges.

At the end
Finally, at the end of an agile project a new kind problem comes up, the need to ‘just get it done’. There is usually a lot of pressure to get a project finished and out the door, especially if there is a big deadline. What sometimes happens is that there is a push to treat the project more like waterfall, just to get it out the door. I have clients say to me, “We know that this is not the right way to do things, but we just need to get this project done. We can do it the agile way later.” The problem is that this just emphasizes all of the challenges and disfunctions that made you want to do agile in the first place. Only now, you are undercutting the effectiveness and value of what you have done so far by saying you are willing to throw agile out the window to get the project done.

I think one of the most important things to realize about agile adoption is that there will be challenges – change is rarely easy, and usually doesn’t go smoothly. However, having the right coach to help you weather the challenges of adopting agile can make all the difference. Stay tuned for my final blog post in the series about how a great agile coach can help you through these challenges.