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?"

Related Editorial

Related Vendor Content

Infographic: Just How Big is the Nerd Economy

How do you Develop a Shared Understanding on an Agile project?

Continuous Delivery: A Maturity Assessment Model

How do you estimate on an Agile project?

Agile Executive Primer: Partnering Across the Organization

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.