Presentation: When Working Software Is Not Enough: A Story of Project Failure

In this presentation filmed during Agile 2008, Mitch Lacey talks about a real life project that was on the verge of being successful, but was deemed as unsuccessful by the customer. Considering that "the true measure of project progress is working software", Mitch and his team delivered the software, but the client was not satisfied.

Watch: When Working Software Is Not Enough: A Story of Project Failure (1h 27min.)

Mitch tells the story of a project which started very well, used Scrum and XP, user stories and delivered working software every 2 weeks. The customer saw the software and asked for changes, which were implemented accordingly. After 8 months in development, the customer said that the team failed the project. The reasons were:

1. Unclear stories on the product backlog
2. Not providing project deliverable status
3. Not providing reasons for stories and functionality being prioritized lower

The team made a retrospective, trying to understand what went wrong. They came up with these conclusions:

1. Sharing risk in the project. The customer was used to fixed bid contracts, where the vendor takes on all the risk. The team, on the other hand, thought the customer was sharing the risk in the project, and that was wrong.
2. Providing timely and valuable feedback. Multiple customer user representatives sat in each demo meeting, telling the team that what was being built was correct. It was not until there were six weeks remaining in the project when the customer “woke up” and started actually using the application that had been delivered, resulting in changes to components that had been complete for months.
3. How decisions for requested functionality impacted other functionality. The customer, used to a fixed bid scope, did not understand that when functionality was de-prioritized that it meant it was at risk of not being complete. The backlog waterline was not understood.
4. Accountability. The team identified that some customer representatives were not comfortable with accountability. This became obvious when, at the end of the project, several people began blaming the team project manager for work not being accomplished, regardless of what documentation and decisions were available. The project manager for the team was to blame.

The final conclusion was: the team and the customer had different approaches to project development, and different expectations, leading to different evaluations of project progress and success.