10 Mistakes Adopting Agile

Want to really mess up your adoption of agile methods in your organization? Here are 10 mistakes I’ve come across with teams that will ensure an utter failure, Dilbert style.

1. Not Reading the Principles of the Agile Manifesto – Everyone likes to quote (and misquote) the Agile Manifesto. But the manifesto is more than just the four value statements – there are also a set of principles behind it. And since you are reading manifestos, read the Software Craftsmanship Manifesto as well.
2. Not knowing what you want to change – This is the number one question I ask teams. What are you trying to change, and why? Imagine you picked up a book on carpentry, and several expensive tools and said, “This is to make my house better”. I’m pretty sure my wife would be not-so-happy if I did all that and then found out we had to dig up the entire septic system because the problem was a clogged drain.
3. Not having a solid product vision – Agile methods are designed to increase your quality and decrease your time-to-market. But if you don’t have the foggiest clue what you want to deliver or why, then all the sprints and iterations in the world is just going to cause rework and waste as you discover what you really do want. As an example, I coached a team recently who needed a way to keep features out of the mainline for 6-8 months (until the next release) because there were times when features were completely dumped at the last minute. That’s not waste, nor is it an agile problem. It’s insanity that needs to be fixed.
4. Not accounting for the learning curve – There are lots of grand claims made about agile, Scrum and Lean software adoptions and I’m here to tell you that they can be true! Those kinds of increases aren’t going to be seen out of the gate, however. Changing into a collaborative process from a heroic, blame-oriented culture takes a lot of adjustment – and requires time to allow trust to be built up.
5. Not having a plan for resistance – Your laggard adopters are going to want solid data, and are going to resist you every step of the way without it. Be prepared to have heart-to-heart conversations, and to find ways to provide ways to include resistors – or ways to move them out.
6. Surprises for management – “Surprise! The release you promised for July of 2010 will now be in November of 2013!” Keep management informed of what is going on, and find ways to help them with the conversations they need to have. After all, we may all find Gantt charts unrealistic and a waste of time, but if you help your manager generate them from burndown charts for her executive meetings, she may help support your team even more.
7. Not recognizing the value system of the organization – As I wrote in Reward Systems and Organizational Change there are deep, embedded assumptions in how people get recognized / rewarded / paid. The unfortunate norm is tying individual performance appraisals to raises. If you want a highly collaborative atmosphere, you can’t rely on rewarding individual employees the same way. Further, the changes you are trying to bring may not even match the organizational values. Trying to bring openness and honesty into a place which values closed-door, buddy system style meetings and exchanges will only lead to frustration.
8. Local Optimization at the expense of the organization – Anyone who has tried to bring change to a team can likely point out several areas that could not be improved due to organizational constraints (read: politics). To work effectively, agile adoptions need to be able to look at the entire value stream, including marketing, system administrators, database administrators, sales teams, etc. It’s not enough to just shove some development teams into training and hope for the best.
9. Using techniques for collocated teams with distributed teams – You may have a wonderful business case for how you distribute your development team all over the globe. But as you adopt agile methods, you’ll start discovering just how much time you have to spend communicating with the teams just to get the basics across. Stand-Ups, Planning Poker, Retrospectives, and Big Visible Walls are all vital techniques that require much more overhead to accomplish – with quite a loss in the richness of the information.
10. Forgetting that formulaic approaches need to be adapted – Sure you can adopt the 3/3/3’s of Scrum. Or the practices of Extreme Programming. But as you begin to gain context and insights, you and your team should be adopting and adapting the practices to fill the gaps. If you just shove forward without reflecting on what you’ve done, and what you want to do, you’ll end back up in a status quo and a bunch of team members who can quit and go out to tell the world how bad agile is.

What mistakes have you come across?