Failures in Agile Development
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?"
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.
Journal of Agile Failures
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.
Jounal of Scrum and Agile Failure just founded
Most of all of all the journal needs your stories.
Re: Agile failure
Re: Journal of Agile Failures
Re: Jounal of Scrum and Agile Failure just founded
Re: Agile failure
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