Getting Agile

Ok, I have been bribed to talk a bit about agile and gaming, two things I am very into, and which I like to pull back and forth between for inspiration.

For the unfamiliar, “Agile” is a term to describe a certain flavor of how to run a project, usually in software development. The term has become jargon, and there’s a lot of other jargon associated with it (Scrum, Kanban, XP, Lean and so on), and with that jargon comes a lot of strong feelings. With that in mind, I offer this disclaimer: I am virtually guaranteed to misstate something about agile, or present an idea at odds with your experience of agile. Please take no offense at this, and just accept it as a result of the breadth of agile as an idea.

So, that’s great and all, but what the hell does it mean?

At its most basic, a project is agile if it’s collaborative and incremental, rather than top down and all at once. There’s a very famous illustration of this, so famous that I dread using it, but I guess there’s a reason that it’s famous.
Agilecar

The idea is that if you build in small increments that each have a clear “done” state, then you can more easily change direction according to your priorities (Customer needs, market conditions) and you can morosely course correct when something goes wrong.

This can be very counterintuitive. If presented with a project that might take, say, 16 weeks to finish, the instinct is to plan out what needs to get done at the outset, then go heads down and work hard to produce the finished product by week 16. That feels efficient. In contrast, breaking it down into eight 2-week “sprints” of work, where each sprint produces a product that’s a little bit closer to the goal seems baroque on the surface of it.

The reality is a little more interesting. That first approach – to plan and then do a bunch of work – works well on paper but it is very rare that a project ever actually proceed with that kind of clarity. Things change or happen which cause disruptions, and 16 weeks quickly become 30. Agile’s apparent inefficiencies become advantages when disruptions come along (as they do) because when you change direction, you are only changing 2 weeks of work, not 2 months.

An analogy I like very much is that agile is like driving a car by your headlights. They don’t need to illuminate the entire route to your destination, only the part you need right now.

Obviously, there are a lot of complexities when this hits reality. Agile is usually associated with software development because the nature of the work supports this kind of incremental effort in a way that, say, building a bridge may not. And there are a lot of different ways to be agile. The 2 week sprints I mention are used in scrum (an agile methodology) but are just one way to approach things. In contrast, Kanban is less about periods of time and more about keeping workflow moving from moment to moment.

This is a big iceberg, and there’s no way I can show it all at once, but hopefully this gives a decent starting point.

So far I’ve largely talked about how agile is incremental, but I haven’t talked much about how it’s collaborative. Another reason that Agile has been embraced by software development is that is is strongly focused on the people doing the work, with very limited roles for others. The expectation is that the role of non-developers is to give the developers a clear understanding of what’s needed, and then let the developers do their job for a while. Eventually the developers will emerge and show what they’ve built, there will be some discussion about what works, what doesn’t and what’s needed, and then the developers return to their caves to work again. Outside of that, meetings are limited to just making sure everyone stays in sync.

But all of this points to the third leg on the stool, the one I haven’t mentioned yet: Continuous Improvement. This idea is tied to “Lean” (and that’s a whole story of its own) but it’s been adopted as an agile best practice.

What this means in practice is that a certain amount of the team’s time is spent talking about how the work has been going, what works, what doesn’t work, and what can improve. There are different tools for this, but the most common is the retrospective, a dedicated meeting where the team answers:

What did we do well, that if we don’t discuss we might forget?
What did we learn?
What should we do differently next time?
What still puzzles us?

There are going to be future posts that build on this one, about how agile intersects with games and game design, but I want to make sure there’s one practical takeaway here. Take a look at those four questions. File them away, and sometime in the future, when the game you’re running wraps up a little early or starts a little late (or maybe in post mortem email), bounce them off your players. See if any of the answers help your game.

Then do it again. Do it enough times that your players feel *comfortable* answering the questions. Once it’s habit, I suspect you may find that the discussions these questions inspire may be very fruitful indeed.

3 thoughts on “Getting Agile

  1. Kevin Danahy

    I was musing over this and realized the American space program followed a similar pattern; they didn’t try to go from zero to Moon in one step, but built Project Mercury first, then Project Gemini to solve specific problems (such as learning how to dock two spacecraft in orbit) which they applied to Project Apollo.

    Reply

Leave a Reply to Kevin Danahy Cancel reply

Your email address will not be published. Required fields are marked *