Long term planning & Agile?

One of the initial questions raised about Agile development is "how can we plan for a two year project when the plan can change every month?". This is a fair question.

The answer is that you can't plan the exacting details of a project two years out. You can try, which is the major problem facing many game development projects. Typical long-range planning tends to lock down features and adjust the budget, and schedule to match. Agile's approach is the reverse of this. Features are the most flexible "lever" we have in controlling the budget and schedule. Anyone who has been on a team that has had a lot of people added on at the end in an attempt to keep schedule has seen the folly of this. With Agile, we iterate on the features to insure that the feature value we choose to ship with consists of the best features.

Agile projects use "releases" which are version of the game that are potentially "release-able" every three to six months. Think of a release as a version of the game you would publish on a game magazine's disc. It's debugged, optimized and passes some of the more significant TCR/TRC tests.

Releases are superior to milestones because they are true measures of the game's value. They can be focused tested and shown to larger audiences at E3. Everyone that has developed a demo for E3 knows the value of having the team drive towards the goal of getting a real product on the floor for that show. You discover the reality of what you thought was valuable and what was not building that demo.

Great Dr Dobbs Article

I read this great article on selling XP to traditional (risk cautious) organizations. It addresses some of the reality vs. rhetoric out there. What really caught my eye was the cost of change curve on page 2. I've always thought of the XP CoC over the entire project cycle vs. the waterfall CoC curve. What he shows here simplifies that to one curve with the x-axis not the project time frame, but the "length of feedback cycle". He writes: "Comparing the cost-of-change "curves." The agile and traditional cost-of-change curves are identical. The difference is that agilists follow techniques that keep us at the low-cost end of the curve."

I like that it applies the CoC curve to all of Agile, not just XP.

High Moon "Insider's view" of Scrum

A tounge-in-cheek video on our use of Scrum (hat's off to "The Office")

http://www.highmoonstudios.com/

The video will be there until ~5/8.

Enjoy!