Google Tech Talk Video: Mary Poppendieck

Touches a lot of her (and Tom Poppendieck's) topics on Lean. One hour of solid gold.

http://video.google.com/videoplay?docid=-5105910452864283694

Debt and the effects on releases

Our Last Release

Our two main goals of adopting agile is to (a) reduce waste and (b) find the fun first. By focusing on adding scope to the game in prioritized and "completed" increments, we hope to achieve these goals and avoid scrambling at the end to find it.

We develop our games in series of 2-3 week "Sprints". Each Sprint adds "vertical slices" of features that add to the value of the game. The game should be better every 2-3 weeks. We also have "Releases" which occur every 2-3 months (there are about 4 Sprints per Release). Releases are "potentially releasable versions of the game". We think of them as magazine or E3 demos.

As we wrap up another release, I had some observations about how we can do it better. E.g. how we can reduce the waste and improve finding the fun.

With the last 2-month release, we didn't really see much of the value until the final Sprint during which the team elected to work some overtime (the last weekend and some of the nights during the week). Although this was not a death-march in any sense, it's something to keep an eye on towards improving.

So I've been thinking about that.

One of the values of Scrum is its tools for creating transparency in what is going on. One of these tools is the "Release Burndown". This shows how many "Story Points" the team is finishing each Sprint. Story Points are measures of feature difficulty that are relative to one another (and most importantly, not tied to hours). It's been a very good measure of feature velocity when planning future releases.

During the last release, we saw a drop off of Story Point velocity towards the end of the release:
This diagram is used to illustrate what happened (it's not the actual Release Burndown, but simplified to make the point). The blue line shows the story point Burndown. The purple shows the value of the game (fun) from the customers perspective.

Ideally, I'd like to see the value grow at a steady pace. If it's not, then it implies that debt is growing. Some of the work going on is not reflected in the game.

Debt

Debt is unfinished work. We'll refer to it as "parts on the garage floor". Debt can be:

• Polish or tuning work
  
• assets that are left out or built too soon.
  
• over-design

If we use polish or tuning as an example, we might see them being ignored in the Sprint builds. The team will take credit for the related story (and it's points) because the functionality is there, but those issues will still need to be addressed. Since it takes time to polish and tune, then the team has a debt associated with that story they thought was complete. This debt has to be paid. Typically this happens at project Alpha, but in our case much of this has to be repaid before the end of the Release.

The reason is that lack of tuning prevents value. How many times have you played a game where an annoying behavior prevented you from enjoying it as much as your could have had it been fixed? You can see the effect of this in the diagram above; As the team shifts from working on stories to working on polish, the story point velocity decreases, but the game value increased at a much increased rate. We customers started enjoying it more and more as those annoying and distracted problems were fixed.

(One comment that comes up is that "all debt is not bad". That's the topic for a future post.)

Why overtime?

So why did we have overtime at the end of the Release? Two reasons:

1. The team elects to do overtime when the product value growth is near vertical and they are running short of time.
   
2. You do it because you can't ship with critical bugs still in the product.

It's not a great place to be because you are letting the schedule determine the value and QoL. The schedule should determine the scope.

What should happen is:

1. The team completes vertical slices of scope every Sprint.
2. The scope is prioritized.
3. When you near the end of the Release, your Scope velocity determines the Scope cutoff point. The lower value features are left off.
   

Debt takes the control out of your hands.

Causes? Fixes?

This is the hard part. There are two avenues of how to address this that need to happen:

We customers have to set the expectation for completeness every Sprint. We need to recognize debt and react to it. Recognizing debt in game development is hard.

The team needs to focus on value and not on stories and points. They get fixated on the Sprint Burndown and need to pay more attention to the game.

Fantasic Article on adopting Scrum

One of our programmers found this article. Although this is not a VG developer, the similarities in experience are very close.

GDC AGD Tutorial Announced

The Agile Game Development Tutorial has been announced on the GDC website.

We're still in the process of planning, but the thought is 50% presentations, 50% open discussions (most likely an Open Space).

Article posted

I uploaded copy of an article called "Get in the Game: What others can learn from game developers" on the AGD site. I wrote it a few months back at Mike Cohn's request for "Better Software Magazine". Mike is their technical editor.