≡ Menu

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?

Comments on this entry are closed.

  • Ethan Vizitei February 16, 2010, 9:52 am

    I experienced #9 first hand when we were working with a team in Omsk to get a portion of our startup codebase launched. Between the time difference and the burden of heaps of written communication, it was a pretty tough deal. Compared to situations where I’ve been in a close local team, it was a little painful, and our “Agile” process that we were struggling to follow was really just a thin veneer over a very disjointed and stepping-stone methodology. In that case, we were better off just shipping them a spec, paying for the delivered code, and iterating over it ourselves (in house) for improvements and fixes.


  • Adam Knight February 20, 2010, 7:58 pm

    Glad to see 5. identified as an issue. People find comfort in the familiar structures and documents that are embedded into more traditional development processes. This is despite the fact that often the poor execution and lack of maintenance of these was the cause of many of the false assumptions and misunderstandings that were apparent in poorly implemented waterfall developments. Persuading people to give up the false confidence that is provided by these artifacts can be a genuine risk to the success of Agile implementations.


    “The true test of character is not how much we know how to do, but how we behave when we don’t know what to do.” John W. Holt, Jr.

  • Adelaida Crummie May 21, 2010, 12:37 am

    Such webmasters try to use articles from free substance directories to make visitors to their website and make some money. This is mostly powerful for those who have just begun working as an affiliate for individual companions and do not even have any funding, yet need to develop little niche sites to visitors to their site so that they can begin making gross.

  • David May 24, 2012, 6:09 pm

    I came across all of these at my last role – which was mostly about undoing the chaos of nine months of half-arsed agile adoption before I got there. Not a single member of the development team had even heard of the agile manifesto, let alone read it. All of them were simply doing what they were told. What a mess…