program selection system

The Story

The team had six months to build an order tracking system from the ground up to replace a legacy system. The team reviewed the backlog of legacy use cases, performed analysis on the existing system and met with the client to understand what business problems they needed the system to address. The customer, whose specialty was building vehicles, like the traditional approaches common with manufacturing. The team highlighted the ambiguous requirements to the customer and proposed a collaborative solution that would allow the customer to provide feedback to the team based on an emerging, working system – the team introduced Scrum, with XP thrown in for good measure, and the customer agreed to take this approach.

The team had a surprise waiting for it, lurking in the dark. After eight months of development, after demonstrating a working application to the client every two weeks based on emerging requirements, the customer said the team had failed to deliver what they requested.

The team was shocked to hear this. After all, the customer met with the formally every two weeks in the demo, and informally two to three times per week to flesh out requirements and provide feedback as functionality was being built. There were no warning signs until now.

The customer told the team they had missed several elements that were critical to success for the project manager from the customer side. They 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, understanding the customer pays the bills, did what it could to salvage the relationship and deliver the application. After all, this was a key account for the company.

In its end-of-project retrospective, the team identified several elements that it failed to help the customer understand in its usage of agile for this project:

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.

Presentation Outline

I plan to use this time based on the following rough agenda:

90 minutes - 60-70m for the talk part, 20-30m for q/a.

1. Project overview.
2. How I failed.
3. Retrospective results.
4. Q & A. (20-30m)

Session Learning Objectives

My intent in this talk is to provide the audience insight into a real life, fresh-off-the-presses project that met all technical deliverables but still failed in the eyes of the customer, in hopes of giving people insight into how not to make the assumptions (and mistakes) the team made.