Failures in Agile Development

Posted by Mark Levison on Jul 10, 2008

Sections

Process & Practices,

Architecture & Design

Topics

Customers & Requirements ,

Agile in the Enterprise ,

Agile

Tags

Business/IT Alignment

As Agilists we love to talk about our successes but its much harder to talk about failure. Robin Dymond has stepped up to the plate and written "A Scrum Project that Failed".

Robin documents a project to replace an existing internal process that had every expectation succeeding:

• Implemented based on Commercial Off The Shelf Software (COTS)
• Product Owner with deep experience in the existing process
• Team members with business and previous (successful) Agile experience
• Senior Agile Coach who had worked extensively with the organization before
• Big 3 consulting firm provided team members with knowledge of the product

By the end of the second iteration things had started to wrong. The Product Owner began to doubt the COTS tool was up to the task. After piloting the software with business users (3rd iteration) the feedback is universally negative. The Product Owner is removed since he lacks vision. As Elizabeth Hendrickson points out "By iteration 3, when all the user feedback was negative, the project should have been cancelled or seriously re-thought".

In Robin's opinion the root of this failure was planted even before the project started:

Project Inception: The project business case was driven by an IT Director and an OPs Director working together. The business that owned the current process ... was not driving the project and asking for these improvements.

Platform Decision: The choice of platform was driven by a belief that the infrastructure needed to move to a COTS application vs. a custom application. ... the application was chosen prior to the start of the project and before anyone had tried to use the tool to build the desired capabilities. Furthermore, when the application was used by the team it was found to be very limited, and the business users found it painful to use. This data was rejected by the Directors.

Allan Shalloway writes about a project that had "no real customer just a business owner saying do something". Months after Allan and his team recommended the project was cancelled. In Allan's opinion failure often comes from:

My own experience with projects doing Scrum is that most aren't actually doing Scrum. That is, when we come in to help/train teams, they say - we've been doing Scrum for X number of months. But when we ask what they are actually doing, it wouldn't qualify as Scrum.

Later on Allan notes that recently he has seen a number of teams that don't have a clear understanding of the Scrum principles:

• Focusing on one product at a time
• Keeping the team focused on business value
• Having a strong business sponsor
• Having the team swarm on stories
• Having a clear definition of what done means to the team
• ...

Finally from his experience climbing Robin talks about a publication of the Alpine Club of Canada - "The Journal of Alpine Accidents". The journal documented climbing accidents so that other climbers read about what went wrong, how they got out of the situation and how events unfolded. He suggests that we need our own journal: "With billions of dollars on the line every day, and a spectacularly high rate of project failure compared to other engineering disciplines, shouldn't we be formally logging and analyzing failures?"

1. Back to top

   Agile failure

   by Joakim Holmbäck

   Recognizing failure in a project and learning from that failure is key to how to improve the process. I agree that we need to talk (more) about failed agile projects, but the above is not really a good example.
   
   
   
   When reading the article it is apparant that the agile process has worked. Already in the first iterations it is apparant that the COTS software does not measure up and is confirmed when the product owner is replaced. The only reason the project really failed was because of management not listening to the people in the project.
   
   
   
   Regardless of which project management technique you use, it will always fail when that happens.

   Reply

2. Back to top

   Journal of Agile Failures

   by Julian Browne

   In the scuba diving community it's a common practice to publicise the events surrounding what are known as "incidents", so that they can be prevented from happening again. The British Sub Aqua Club formally publishes an annual report which makes for sobering reading.
   
   
   
   Regardless of the agile element to this story - it certainly sounds to me as if the basic good practice of solving the problem, not implementing the solution, was missed here - the notion of a common place to share information about project failure is a great one.
   
   
   
   Sadly, many (most?) failures occur within the confines of commercial organisations and thus there's not much of a desire to let this info out. Leaving us with the post-implementation review, which is another useful idea that's equally badly managed.

   Reply

3. Back to top

   Jounal of Scrum and Agile Failure just founded

   by Mark Levison

   I just posted a short posting on my blog kicking off the Journal of Agile/Scrum failures:
   www.notesfromatooluser.com/2008/07/journal-of-a...
   
   Most of all of all the journal needs your stories.
   
   Thanks
   Mark

   Reply

4. Back to top

   Re: Agile failure

   by Mark Levison

   Joakim what other kinds of failure are there? To quote Jerry Weinberg "Its always a people problem". I think all project failures boil down to people and communications. I would love to see a counter example that proves me dead wrong.

   Reply

5. Back to top

   Re: Journal of Agile Failures

   by Mark Levison

   We agree that it is good practice to document failures. While a lot of information is tied up inside commercial organisations, even these stories can be written up without giving out any information. In addition there are enough coaches and trainers in the market now that there must be many stories of failure to be found.

   Reply

6. Back to top

   Re: Jounal of Scrum and Agile Failure just founded

   by Deborah Hartmann

   Cool. We will want to mine that for an upcoming "sensemaking" exercise. Fill up the "Journal" and we'll hit you guys up to tag your anecdotes for our study!! www.m3p.co.uk/blog/2008/04/14/what-is-going-on-...

   Reply

7. Back to top

   Re: Agile failure

   by Joakim Holmbäck

   Reply to Mark: While it always boils down to a people problem, there are numerous ways for a scrum team to fail with its task. The aforementioned failure was a result of management actually removing a product owner and not listening to the team's results. (although it is interesting to see that even a project that has all the ingredients of making a successful agile project can fail)
   
   
   
   Some examples of other ways a scrum team can fail:
   
   - Dependent on other scrum teams (i.e. scrum of scrums doesn't work properly, different agendas in each team)
   
   - Definition of Done is not used properly
   
   - Stories are way too big and too long
   
   - The team does not have all the competences necessary to finish the task at hand
   
   - The team's stories are organized in such a way that each team member works on their own story and the stories are dependent on one another
   
   - The team doesn't bother doing a proper retrospective so improvements can be made
   

   Reply

• Older >