Sunday, April 22, 2007

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.


  1. Considering the reasons for failure you named someone may conclude there is no difference between Agile project failure and RUP project failure. In other words the software development approach obviously does not make difference. The main bottleneck I came across is the failure to define good system requirements. In other words: garbage in - garbage out, principle applies here.

    Agile wins more attention of management becacuse they discovered the way to shift the responsibility and blame for project failure to programmers...

    Downsides of agile:

    - agile may only be used on small projects
    - maximum 5 developers on project
    - all developers must be higly skilled (no learning moments are allowed)
    - developers must be in the same physical room with the project owner.
    - project owner must be available 24/7 since good programmers also work extra hours
    - agile does not support use of virutual teams or outsourcing constructions
    - agile provides poor quality of software since documentation usually does not exist. If it does - it is written in "reverse engineering" style.
    - selling "agile project" as "fixed price & fixed scope" is mission imposible since scope of the project is not defined.

  2. I thought it would be nice to share this article with Japanese readers, so I posted translated version on following URL:

    上記記事の日本語訳を にて公開しました。

  3. Another take on 'Downsides of agile':

    - All developers should be higly skilled. Skilled developers know how to pose the right questions based on deeper understanding of end user expectations. Under a Waterfall project this is spelt out with a requirements document. Under Agile it is not and the inexperienced developer will spend more time to get it right.

    - Highly dependant on the owner being able predict what will work for all users - damn rediculous to expect this of a single person. Many companies have go to guys that are 'very helpful' but just become a bottleneck and this is often the type of person that gets lumped as the owner.

    - Lack of documentation is nice if you have a stable / non contract based App Dev team, but who seriously sees a team of 5 developers stay in the same team for 2-3 years these days?

    You criticised a previous comment for lack of examples, so let me proide you with one of mine.

    I just spent month fixing a setup developed in the Agile way. Even been told by my company 'hey, we're Agile, ok?'

    * It took 2 weeks for the original developer to put it together
    * It took me month to understand all the poorly documented infrastructure and functionality and finally fix the thing end to end in which time the large corporation could not service it's customers properly or with confidence. It took me 6 weeks to construct a better solution WITH documentation based on more formalised requirements, using something closer to (but not strictly) Waterfall. The customer is now assured that any issue can be fixed in 30 mins, not weeks and they're very happy. So tell me, do you think Agile here was worth it? It obviously will work for some customer and some situations, but clearly not for other.

    While I agree Waterfall has flaws (and something in between makes more sense), I think you'll find many stories like mine where someone has been placed in a very difficult position facing off with a business in accute pain and it would have been better if the Agile approach had not been taken in the first place.

    The customer has learnt it's lesson with under estimating projects and is much happier with the newer non Agile approach now in place.



Note: only a member of this blog may post a comment.