A friend who is working towards learning to be a game developer, and whose instructor is exposing him to some agile concepts, asked me this:

[O]ne of the problems I see with Agile Development with relation to Game Development is on the ‘creative’ end, and with research and development. Researching new technology (speaking in software teams) takes time, usually an undetermined amount of time. But, given the methods used in Agile development, it seems that there is little room for allowing ‘creative freedom’ in order to innovate a genre.

I answered this way, which is rough and unedited.

I believe, on the contrary, that agile is one approach that explicitly allows for creative freedom by focusing our energy away from deadlines towards minimum marketable features. I see R&D fueling agile development in a simple way: the ongoing R&D activity uncovers something, which we decide to turn into or add into a product, from which we create stories, then we deliver those stories. Agile focuses on making those stories as lean as possible: maximum business value per unit of effort. A traditional perspective on R&D is that it generates projects or product lines, while an agile perspective is that it generates ideas for features. The difference is batch size.

One consequence of an agile project’s heartbeat is that the team delivering stories forgets to spend time innovating because they simply deliver stories. A high-functioning agile team is probably producing enough business value to be able to add slack into their schedule for innovation. Read DeMarco’s “Slack: The Myth of Total Efficiency” for some specific cases. I recommend two kinds of slack: (1) Split the year into 4 quarters, each 13 weeks; spend 12 weeks delivering stories and 1 week doing anything except delivering stories; this follows a natural business rhythm of one release per quarter followed by a solid week of creative time. (2) Within an iteration, spend up to 20% of your time on innovation: exploring technology, exploring business ideas, or just plain gazing into the distance; most teams don’t do this because they’re buried under a mountain previously-promised and not-yet-delivered projects; such a team has no slack, whether it does agile or not.

I have taken many of these ideas from well-respected sources of opinion on strategic thinking. Most notably, although I can’t remember where I read it, I remember reading about spending a half-day per week, a full day per month and a full week per quarter purely on strategic thinking. I wish I did a better job of following this advice myself. I did not mention gold cards, but you should look for “Innovation and Sustainability with Gold Cards” by Julian Higman, Tim Mackinnon, Ivan Moore and Duncan Pierce as another source of information on how to save time for innovation in an XP project. I don’t remember where I first read the 12 weeks/1 week idea. I’d appreciate a reference in case you read it, too, and remember where.

Follow-Up

Tobias Fors brought his Visible Planning Calendar to my attention, and while I don’t think that’s the reference I was thinking of, it’s a damn fine one. Read it, if you can find it. By early 2016, the link I used here had disappeared, and I couldn’t find a replacement. If you can suggest one, please click here.

References

Julian Higman, Tim Mackinnon, Ivan Moore and Duncan Pierce, “Innovation and Sustainability with Gold Cards”. Still the gold standard description of how to get innovation out of an agile software delivery system.