July 10, 2008 in Software Development by Mark Levison

On a topic related to my recent efforts on Scrum Smells, I’ve started a page on the Scrum Alliance wiki to document Agile/Scrum Failures. The failures are not of the process itself but of the humans associated with the project. This all happened in response to a thread on Scrum Development that Robin Dymond started  (Blog entry: The Scrum Project that Failed). In this thread Robin suggested, that we need a Journal of Agile/Scrum Failure much like his experience in the climbing world:

When I was a member of the Alpine Club of Canada there was an annual journal called “The Journal of Alpine Accidents.” Initially I thought this was odd. Once I started reading it the value instantly became clear. Climbing accidents make for gripping reading because lives are at stake. The real value is to other climbers who can read about what went wrong, what they did to correct, and how the events unfolded. This concept is not new, civil and mechanical engineering failures are studied, and we are all familiar with the painstaking work of the FAA when a plane crash happens.

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?

After reading this I decided to start the journal, but there is a small catch I don’t know alot of good stories on Agile/Scrum failures so this is where my readers come in. If you know of a good failure story: i.e. an Agile/Scrum team that failed to deliver something of value to the customer then I would like to know about it. These can be stories that are already documented and you send me the link or stories that need documenting – in which case I can help.

BTW In most cases I expect that these failures will be related to the people and more importantly communications. As Jerry Weinberg says “Its always a people problem”.

Update: There has been some confusion: Its not that I think that an Agile or Scrum project can fail – but the
people can fail to execute the methodologies well. Perhaps they don’t
listen when the team raises issues, perhaps team members don’t want
cooperate – “Its always a people problem”. Yet
when we are caught up in the thick of things we often don’t see the
early warning signs or recognize the fact that all these small problems
point to something much bigger. In my mind the stories are a useful way
to remind us of how things can go wrong and what it looks like when
they do. As format there is none. Write your story any way that you and post wherever you want – your blog, the scrum community wiki etc.