When Agile Becomes Fragile

In my last post, I didn't addressed the issue of agile planning boiling down to "only planning 2-4 weeks ahead." Based on what I've seen, this is still a common misconception in game development. I've encountered skepticism about agile from managers at three different game companies who had seen agile projects go off the rails. One manager dubbed agile development, "fragile development." From what I understood, they attributed the failures to poor planning that focused on the short term.

Every project needs to find a balance between anticipation and adaptation. Finding a balance for a given project is part of being agile. Unfortunately, I think practices like daily stand ups and iteration planning are much better understood than longer-term planning practices like release planning. One game studio I know of was spending a lot of time rewriting the game engine for a franchise, and I wondered how that fit into their release plan, e.g., how would they fit that work in before full production needed to begin? I was told they didn't have a release plan. I think that's a recipe for disaster. Mike Cohn has explained the importance of release planning pretty clearly:

"A release plan helps a team avoid finishing a series of sprints and feeling that, while they always worked on the highest priority items, the collection of work completed does not add up to a satisfying whole."

I think this planning is especially important in game development with its different phases: concept, pre-production, production, and post-production.

I also surmise that projects run into problems with prioritization, risk assessment, and estimating costs, e.g., cost of delay. I think new agile adopters understand the practices for teams and the role of scrum masters much better than they do the role of the product owner. It's not always clear who should fulfill this role: design or production. I suspect this role isn't often filled well (or at all.).

Agile isn't synonymous with Scrum or time-boxed planning practices. I think that game development poses special challenges and tools in addition those used in Scrum are needed. I want to address this in "To Timebox or Not to Timebox (Part II)."