Autopsy of a Failed Agile Project (or Death of a thousand cuts)

by Evan Leybourn on      4 minutes read

Projects are a tricky thing. No matter how much you plan, or how adaptable and agile you are, something will always go wrong. Any project manager who states that they have never had a failed project is young, confused or going for a job interview.

Depending on which study you look at (and here's a few for reference: http://calleam.com/WTPF/?page_id=1445) it is commonly accepted that between 40 and 70% of all ICT project fail by one or more criteria including; schedule, budget, maintenance & return on investment. Even agile projects are not immune, with a 30-50% failure rate.

Unfortunately, many of us tend to be terrified of failure, which makes it difficult to admit or learn from our mistakes. However to be a good Agile manager we need to understand that failure is a necessary step in the process of learning. In the Agile community, we have an expression: Fail often; fail early. We want to discover the flaws in the project as early as possible to limit the impact of the failure. This doesn’t mean we think that failure is good. We still want to produce high quality outcomes for our customers. However, we need to see failure as an opportunity.

I would like to begin to examine some of the reasons for Agile project failure that I have personally witnessed.

  • Lack of customer engagement: How many times have your projects stalled while you wait for clarification or decisions from your customer? Trying to get access to busy customers or SMEs, who are usually already overworked, can be nearly impossible. I’m sure that I’m not the only one who find it difficult to deliver on schedule without a fully engaged customer.
  • Understaffed: Hands-up anyone whose project is fully staffed? Every time I ask this question in a conference, not a single hand goes up. Understaffed teams (or worse, incorrect team members) cause significant delays in development and often deliver low quality outcomes.
  • Competing priorities: How often have you run projects where your assigned team members also have conflicting BAU responsibilities? Even worse is when their BAU responsibilities can vary from week to week making it nearly impossible to manage.
  • Low team morale: Have you ever gone into a project, only to find out you’re the fourth project manager, the team hasn’t delivered anything and they are under major stress from senior executives? For me, twice (and that is two times too many). One of the first things I do on a new project is to address team morale. Low morale (for example, due to lack of delivery or a low understanding of project value) can affect team productivity and, in turn, can lead to even worse morale.
  • Insufficient allocated time for delivery: How often have you been given a deadline and asked to deliver more work than possible in that time? I like to visualise my project teams as a pipeline. The width of the pipe is my Team size and the length is the time available to deliver. If an estimate is incorrect or a new requirement comes into the pipe, the lowest priority requirement will fall out the end. In Agile terms, the Velocity of each Team doesn’t change just because you give them more work.
  • Unfocused development: How many times have you had developers go off on tangents building “frameworks” that added no direct value for the Customer? I believe that business value is, usually, the most important thing when prioritising work, but sometimes it can be difficult to get developers on the same path.
  • Underlying architecture design: The flipside to unfocused development. If the underlying architecture is poorly documented and underdeveloped, this can cause massive delays and issues early in the project.
  • No defined success measures: Do your Customers always know when a project is “Done”? I find that without clearly defined success measures it can be impossible to measure benefits realisation on project completion.
  • Poor quality (or inconsistent) test data: Mostly relevant for Business Intelligence projects, but I have seen poor test data cause inaccurate tests results (both false positives and negatives) resulting in rework.
  • Lack of systems and infrastructure support: How many times have you had a project stall because you are waiting for technical support or non-project staff to respond to an urgent issue? I have seen this cause numerous problems, especially in business intelligence projects.
  • Poor project scope at inception: Now I’m an Agile guy, so I love minimal up-front requirements and working with the customer to iteratively develop a system to meet their changing requirements. However, even I agree that a lack of clarity on the end goal (and the relative priorities of the requirements) reduces developer productivity and can end in the wrong product being delivered.

I don’t admit to knowing the answers to all these issues. I’ve certainly solved many of them and turned my share of failing projects into successes (for various definitions of success). Nevertheless, I’ve also had my share of projects that were doomed to failure no matter what I do and, unfortunately, a few that I realise I could have made successful with the benefit of hindsight.

Finally, I believe we all need to learn from each other and discuss our failed projects, so we can identify these issues early and mitigate them before they become serious.

Attribution

Image is GFDL - Unisouth