Merging Waterfall and SCRUM

Introduction

This article explains how I've managed to marry both forms of scheduling, why I do it, and what pitfalls I've identified.

What is SCRUM?

For those of you who don't know, please read up on it: http://en.wikipedia.org/wiki/Scrum_(development)

This is a more iterative, self-managed workflow designed for fast-paced software development where the tasks and work assignments are not defined until the time-period where features are to be implemented.  It tends to respond better to change and the iterate-until-it's-right mentality of game developers.
 
What is Waterfall?
  
This is the traditional scheduling method where everything is planned up front to the nth detail and all tasks and assignments are pre-determined.  This provides a more predictable end point and resource needs, is easier to see impact on changes, but does not respond well to the often shifting goals and moving targets of game design.

Feature Driven Master Schedule

Any good milestone schedule is feature driven.  A feature is a combination of art, code, sound, design and testing.  It's a tangible, often playable thing.  Using MS Project, work back from the game's alpha (feature complete) date to layout target dates for features. Historical data or the TDD should provide gross man-month estimates for how long these should take.  Err on the side of needing more time.  The SCRUM process should help you refine those dates as you get to them, and if you have a publisher commitment on a feature, you can't always extend the date.  You can use resource leveling, but don't assign names, just resource headcount (programmers, artists, etc.)  This should block out the resources you might need for budget purposes and helps ensure you're not overallocating.  You should end up with a fairly clean MS Project schedule with apparently very little justification for how those dates are calculated.  That's okay.  These are goals or target dates.

Planning Phase SCRUM Sprint

For those new to SCRUM, a SCRUM schedule turns feature descriptions into "stories".  A story is a description of behavior, look and feel from a user perspective.  A big story item (like a game level, multiplayer match type, game shell, etc.) that take many sprints (weeks and months) is called an "epic".  SCRUM is supposed to get a complete backlog of the epics and stories that make up a feature.  At each segment of time, called a "sprint" the team takes a chunk of those stories off the backlog, widdling it down in a process called "burndown".

For the marriage to work between Master Schedule and SCRUM process, you need to form a SCRUM team around a feature and update those target dates in their first sprint, called the Planning Sprint.  This sprint should culminates with a complete plan for implementing the feature - concepts, storyboards, design documentation, and finally a full feature breakdown into stories with gross estimates for each.

Each estimate should be by discipline.  If multiple disciplines are involved in a story, then break it down further.  This usually translates to a few weeks, or one to a fews days of work for one type of individual.  SCRUM method of peer voting on estimating should help keep the estimates from bloating.

Then it should be a simple matter of doing a projected burndown by discipline or using a scope checker of estimates vs. discipline allocation to calculate the new end date.  I do the latter using Excel.  I tend to add some risk padding to their end date to minimize the damage of a slip.

Pitfalls

Iterations & Risks: You should plan on certain stories being repeated, particularly very subjective ones involving look, feel & fun.  Start those stories as EARLY as possible in development and do as much detail as possible on them in the Planning Sprint to reduce the risk of repeating the work.  Planning on iteration helps you identify when product owners (management) or the team is iterating too much and puts onus on the management to accept an iteration or miss the end date.

Rushing past planning: You must NOT fail to do a complete feature breakdown and gross estimates for the feature by discipline otherwise you cannot predict the end-date.  Teams HATE doing this, but it makes it much easier to plan each sprint and calculate the end date.  If the estimates are not done by discipline, it could mean that insufficient members of a particular discipline can unexpextedly push out the end date.

Benefits:  

Scope Control: The team tries to fit the newly vetted dates within the target dates of the master schedule.  If it does NOT fit, then the negotiation begins on scope or manpower.  Management WILL attack your estimates if it pushes out a date, but because you've done your homework, you can win or come to a reasonable reduction of scope where nobody is killing themselves.  Once the negotiation is over, you'll now have a shield against feature creep or resource stealing.

Accountability: Using SCRUM, the team has determined the work and the end date.  It is now up to them meet that date.  This is where as a manager I don't feel bad asking for a little overtime to keep on target.  If they estimated or executed wrong, it's up to the team to address it.  You signed off on the scope, they signed off on the work and estimates.  If you're not messing with the scope, then they have no excuse.

More Certainty: Lastly, the benefit of this method gives you the best of both scheduling styles - the predictability and defensability of a well-planned waterfall schedule along with the more iterative, plan-as-you-go, rapid-response, fast-prototyping, and self-directed nature of SCRUM.