Search

Tuesday, November 04, 2008

Scrum and project miracles

There is a lot hype about the benefits of Scrum. Much of this hype is born out of the desperation developers have had from the failures using traditional methodologies. One example of this was on a project I joined in its early planning phase. We were challenged to develop a sequel to a game that another developer created. The original developer had spent four years developing the original game. We were given eighteen months to finish the sequel which had be of higher quality. The impression was that if we had the source code of the original game, we could be three times more efficient.

Detailed plans and schedules were created that defined how we would successfully ship a superior sequel on time. Unfortunately we failed to achieve the goal even after months of mind-numbing overtime and the project was canceled.

Could we have succeeded with Scrum? I'm sure we wouldn’t have shipped the game on time, budget and at the quality target. However I believe the project would not have failed as badly. Rather than trying to follow a preset plan and hoping to catch up as we slipped, we could have known earlier that the goals were impossible. Had we known early that the goals were unlikely, we could make better decisions on how to proceed.

The best way to spend less money on a game is to spend less time. We are always in a rush to be first to market. Even if costs are the same, we often choose the project with higher staff levels that can be shipped six months earlier.

This is why we are never given enough time to do our job well. This is why we are forced to enter production before we have found what is fun enough to produce. This is why we ship prototypes.

Scrum isn’t an answer to this. It’s a different way to deal with uncertainty by addressing it head on. Take for example, a game in development using Scrum that is projected to enter production by October 2009. After a few iterations, (see figure) we see that the actual progress of the team (the thick red line) is 70% of what was projected in the blue line as measured by user story points. By projecting this actual velocity (the green line) we see that with the current scope planned, we will enter production five months late.

The Product Owner (PO) will be aware of this actual velocity and has a number of choices to make. If the game really must enter production by October 2009, then they will likely cut scope. The PO could try to increase the velocity of the team by adding people, but this rarely works.

Conversely, if the PO wants all of the scope defined in the game, then they must communicate to the stakeholders that the production date needs to slip.

One caveat to mention here is that things aren’t often so cut and dry on our projections. We don’t often estimate user story points beyond six months in advance in detail and velocity isn’t constant. Beyond six months the crystal ball is a bit foggy. Some projects will estimate larger epics. Others will build larger backlogs. Neither of these solutions will give us more certainty. If the ship date is fixed more than six months off then we need to make sure the backlog is always prioritized so that if the PO needs to cut scope, they are cutting the lowest value scope.

The principles still apply. We need to measure the actual velocity and not depend solely on our predictions.

2 comments:

Paul said...

The obvious follow up question: how do you estimate a project longer than 6 months?

Clinton Keith said...

Paul,

Good question. I added some text at the end to address what I left out.

Most projects simply can't have much accuracy in estimates 6+ months out. Even 3+ months starts to get a bit foggy.

This is why the backlog is not arranged based on the order of when the features will be done but ordered based on their value to the customer. The idea is to deliver value by removing work from the top of the backlog until the PO decides it is time to ship. If the ship date is the deciding factor then the PO will cut off work. The key thing is that value is still deciding what we ship, not schedule.

The important thing to note is that the backlog is not seen as a promise of what will be shipped, but a full set of all potential scope that is potentially reprioritized every sprint.