Tracking change and innovation in the enterprise software development community
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Defy all
Challenges.
Microsoft®
Visual Studio
2008
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
TargetProcess:
Plan, Track
Succeed with
Agile PM tool.
Free Download!
Posted by Mark Levison on Jul 10, 2008 01:00 AM
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:
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:
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?"
The Agile Business Analyst: Skills and Techniques needed for Agile
Evolutionary Design through Agile Development Podcast
The Future of Software Delivery According to visionaries Grady Booch & Erich Gamma
Lean Software Development Governance, a whitepaper by Per Kroll and Scott Ambler
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.
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.
I just posted a short posting on my blog kicking off the Journal of Agile/Scrum failures: http://www.notesfromatooluser.com/2008/07/journal-of-agilescrum-failure.html Most of all of all the journal needs your stories. Thanks Mark
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.
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.
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!! http://www.m3p.co.uk/blog/2008/04/14/what-is-going-on-out-there-a-narrative-inquiry-project/
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
Michael Mah analyzes the development process in 5 companies: 2 Agile (one of them BMC) and 3 classic. He presents the factors which contributed to the success of BMC's Agile adoption.
In this interview filmed at RubyFringe 2008, Tom Preston-Werner talks about how both Powerset and GitHub use Ruby and Erlang, as well as tools like Fuzed, god, and more.
David Laribee discusses the purpose of ALT.NET, its mission and future.
Ruby on Rails has become a popular Ruby framework for creating web applications in recent years. An aspect of creating a web application is the need to repeatedly create the same base functionality.
Steven Haines talks about tackling web application performance tuning by proposing a method called wait-based tuning.
Shaw and Fowler talk about the need for a new relationship between the business department and the IT department. Studies have shown that projects mostly fail due to miscommunication between the two.
In this article, Jim Webber, Savas Parastatidis and Ian Robinson show how to drive an application's flow through the use of hypermedia in a RESTful application.
Eccentric artist turned overnight anti-celebrity, Giles Bowkett captures the heart and soul of RubyFringe as he demonstrates his revolutionary Archaeopteryx MIDI drum pattern generator.
7 comments
Reply