Failures in Agile process?

One of the questions that was posed at ACCU conference was “What are the downsides of Agile development?” – and “What does Agile failure look like?”

I have tried to answer the first question before but failed myself.  One downside is that the Product Owner role – typically filled by a Business Analyst, Product Manager, Customer or other proxy-customer – is given an immense work load.  This is a subject James Noble has done some work on.

What happens is that Product Owners have to keep doing their original job and service the needs of an Agile team.  As the Agile team becomes more productive they ask more and more of the owner.  Consequently the owner gets maxed out and themselves becomes unproductive.

However when I thought about this I don’t think the failure is a failure of Agile, I think it is a failure of the business.  Put it this way: for years “the business” has been complaining that software teams do not deliver what they want.  Now along comes Agile and says “we will deliver exactly what you want” but “you need to tell us exactly what you want.” 

It is no longer enough to set half a dozen developers working on a problem and expect them to come up with the right thing.  If customers want what they ask for then they need to tell the developers exactly what they want in detail.

The second question, “What does Agile failure look like?” is hard to answer because we don’t have many case studies of failed projects.  This isn’t just true of Agile projects, it is true of many IT projects.  Companies don’t like to talk about failure. 

Still I can see several failure modes for Agile:

• Teams fall back to the old way of doing things: I’ve only heard about this not seen it myself.  Typically it occurs when you bring in a lot of consultants to make your team and process Agile.  Things work when the consultants are there but when they leave teams fall back to the old way of doing things.  Unit test break and aren’t fixed, planning meeting are missed, quality slips and deadlines are missed.  The presence of consultants gives the team a backbone but knowledge is not really transfered to the existing team.


• Failure to get management buy in: Agile is often introduced at the bottom of the hierarchy, by developers at the code face.  Eventually there comes a point when managers need to support it or stop it.  This doesn’t happen and the development process is left in a random state.


• Failure to get developer buy in: this occurs when management buy into Agile but developers don’t.  They don’t want to write tests, do code reviews or pair, believe in technology over visual planning, etc.  Again the process is left in a random state.  I expect to hear more about these types of failure in future.

The common theme here is not that Agile fails, after all IT projects and processes fail all the time so there is nothing new or special here.  Failure of an Agile project looks a lot like the failure of a Waterfall or RUP project.

Rather Agile fails when you fail to see the benefits of the new approach.  So when you do a little bit but not enough to improve quality, improve delivery dates, and make things predictable.

Both questions are good questions and deserve more attention.