Sunday, January 10, 2010

Spouses, death-marches and Scrum

Another spouse led revolt about extended overtime (death-marches) has come out.  Invariably, some comments suggest that Scrum is a solution and the argument is led astray.  It's time to set some things straight.

Scrum is not a solution.  Teams and studios are the only solution to crunch.  Scrum is a not a methodology of "best practices" to solve problems, but a framework to create more transparency so  you apply common sense and find a ways to solve those problems yourself.

That said, Scrum and agile have tools and principles to help teams fins ways to eliminate death-marches:

Minimizing debt - Scrum practices focus teams on delivering features that demonstrate a level of quality and even optimization needed to determine their value and avoid excessive work or waste later on.  This doesn't mean that every feature developed every iteration is fully shippable.  It also means we avoid postponing as much debugging, polishing and optimization as makes sense.

Prioritizing scope - Features and requirements are developed primarily in the order of value they add and the risk they resolve (see below), not according to project management's resource allocation plan and schedule.  This way, if scope needs to be cut to meet a fixed schedule, it's not the highest valued scope.

Prioritizing risk - Uncertainty is not "planned away" in a document or schedule, but tackled head-on.  We don't build 20 levels without knowing they are fun and meet the budget (technical and production) constraints.  We shouldn't wait to see if online multiplayer works for our FPS until the end.

Manage by velocity, not what the plan says - Reality does not budge one inch for a plan.  Planning has to be ongoing and reflect the empirical measurements of team progress.  We can't "wish away" bad news or schedule crunch time to make up for a bad plan.  Contrary to some comments, knowing the original plan is not going to work sooner gives you more options than knowing it later.

These principles make looming death-marches visible far enough away to do something about it.  If this visibility is ignored, it can't be avoided.  Velocity demonstrates that extended overtime doesn't work anyways.

This is why it's said that Scrum merely creates transparency, but doesn't solve problems.  Creating transparency is half the battle.  Using it is the other half.


Scrum can help you keep your spouse happy, but don't take it too far.  I hear stories of developers teaching their spouses about Scrum and later finding a task-board and burn-down chart on the refrigerator with all their "honey-do" tasks identified and prioritized!


Joe Tortuga said...

I don't think it's unique to game development for management to think that a methodology is going to be some silver bullet that will solve their problem. All any methodology will do is give you the tools, measurements, and framework to know what is going on and make decisions about how to proceed. Hopefully it'll do so in time to change course.

I've not used scrumm specifically, but I've done agile development before, and to the extent we were supported it worked well.

Clinton Keith said...


You're right, it's not a superstition unique to game development. I haven't heard of wives banding together to fight overtime outside the industry though. That might be unique!

Thanks for the comment!