Difficult Decisions When You’re Between a Rock and a Hard Place

Over the last six months, I have been working with a client that is moving from “RUP” to Scrum. It’s unfair to describe their projects as using RUP because in truth they’re more waterfall than RUP. The project teams used RUP nomenclature and artifacts, but still worked within the waterfall lifecycle.

One particular project that I help convert had an interesting set of circumstances that put the Product Owner/Customer in a very difficult situation.

A difficult beginning
The motivation of converting the project from RUP/Waterfall to Scrum was very understandable. It wasn’t going well. The team had had difficulty delivering software and had already missed several deadlines. Management decided to try Scrum after experiencing several successes with Scrum on other projects within the company. The motivation was to try and achieve some level of comfort for the amount of work remaining and to determine a realistic timeframe for completion.

The transition to Scrum was rather painless. The team finished their RUP/Waterfall phase and simply started Scrum the next day. They initially had difficult and the very first Sprint was canceled when it was obvious that they had made no measurable progress a week into the sprint. After further discussions and a greatly reduced commitment, the team started to make progress and have been making good steady progress every since.

When the team converted to Scrum, there was a great deal of uncertainty regarding what work remained to be completed. I believe that this was partly due to poor team communication and insufficient testing during the construction of the software. As the team started to communicate and understand what needed to be done it became clear that there was a great deal of work outstanding. The conversion to Scrum had highlighted the state of the software which required substantial work before it could be considered “Done”. This had always been the case, but Scrum makes this information more visible.

The Product Owner (Tom) prepared a backlog for all the items that he wanted for the first release, and the team estimated each backlog item. The targeted deadline for the project was 2 months. Following the exercise in estimating, it became clear that the amount of work remaining was in excess of 14 weeks (approximately 3 1/2 months).

A difficult position
Tom was in a difficult position. When the project had started (under the waterfall model) a commitment was made to delivering a set of agreed upon features, within a certain period of time. Now (under Scrum) that the team had identified a long list of work that needed to be completed before the product could be considered “done”. He was unable to remove backlog items to reduce scope and hence reduce the time to completion.

Tom had to report this to his senior executives. He was in a position where he had to deliver the message that an at-risk project had been delayed (again) and that the delay would be significant. This is a difficult message to present. One the positive side, the conversion to Scrum had help identify issues with the software early, and the team was far more confident with the amount of work remaining.

How to break bad news
Tom did a remarkable job of breaking the news to senior executives. His approach was to present the facts of the project; a summary of what the project set out to do, any alternative solutions, and a list of the outstanding work. He then used the teams velocity to show how many iterations remained.

He did not give a completion date, but simply left it up to the executives to do the calculation. I think this is important. By leaving out an estimated end date, he avoided an immediate reaction (on the part of the executives) and was able to continue the conversation without being put on the defensive. Using a more subtle approach he was able to present all the necessary information.

By all accounts it was still a difficult discussion.

Summary

I’m glad to say that that team is doing very well. They have resolved many of the initial quality issues, and are now producing software of a higher quality. More importantly, there is a better understanding of what needs to be delivered (i.e., the goals of the project) and what work remains.

And thanks to Tom’s efforts, they know that they have the support of senior management.

Note: As always my old articles can be found on my personal blog at http://KaneMar.Wordpress.com.

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*