During week 10 we learnt more about the agile process and the various practices.

I’ve been a software developer now for almost 20 years, and have a fair grasp of the agile process. I was especially immersed in the agile process during my tenure with GOV.UK. I’ve seen teams use a mix of different processes, anywhere from extreme programming all the way to longer sprints called “mini waterfalls”.

My favourite two concepts from agile practice are “iteration” and “the prototype”.

Iteration

Iteration is the time-boxed analyse-design-build-test cycle, after which feedback informs the next cycle (Rasmusson n.d.). The middle ground between over- and under-planning is iteration:

Iteration is the practice of making short-range plans, implementing them, testing them, and repeating.

We don't only iterate on an entire game. We can iterate on a level, a tool, or an interface.

It exchanges deep planning for reality checks. It tests the broad structure before investing in detail polish. And it requires that designers not get too invested in plans for the future, and instead adapt continuously to unpredictable test results.

(Sylvester 2013: 283-284,287)

Iteration is such an eye opener if you come from a world of waterfall development (which I’ve had a taste of very early in my career). A good first iteration for any module or feature is getting its rough structure down, or what we called the “steel thread” at the Land Registry:

That work provided us with a useful starting point for this year’s project. Think of it like bridge-building. The first thing bridge-builders used to do was throw a steel thread from one side of the valley to another, then use it to help build the rest of the bridge. Last year we threw the steel thread, and found the point where new ideas crystallised and we began to understand what should happen next. Now we’re building the bridge itself.

(Bracken 2015)

Prototype

Which brings us to the prototype. One of the most valuable parts of the agile process is the learning process (to know what to build), which is achieved by way of a prototype. A prototype is meant to take a short time to build, and be a rough approximation of the final product.

Sure, you could take a longer time to build a more perfect prototype — but doing so would only slow down the learning process.

(Knapp et al. 2016: 166)

In game development terms, a prototype would be a grey-boxed (or some say white-boxed) vertical slice of your game with which to prove out the base game mechanic:

After chopping up the outline for the game we have been white boxing the chapters, one after another. White boxing for us literally means placing out white boxes and placeholder items instead of final props and beautiful 3D art. The goal for this is to get the backbone of the whole game in place as quickly as possible, it’s almost like doing sketches before you paint a canvas. What we want to do here is to test the story pacing, puzzles and the core game mechanics. This is quick and dirty, but it helps us build the game in an organic way, and we can test things straight away.

(Casen 2016)

I’ve been in a few hackathons now (both for fun and at work) to know in my bones that the MVP (minimum viable product) works wonders for learning. However, I’ve also seen the MVP get in the way of serendipity, as the learning directs a team away from what a product wants to be. As such, the most important skill for a game designer is listening (Schell 2019: 5), not just to their playtesters, but also to their teams and their inner voice.

On BioShock:

It was only several years into development that the game shifted into an art deco undersea city and gained its failed Objectivist utopia theme. Its designers did not plan that world on paper; they developed it through years of work on the game itself.

(Sylvester 2013: 282)

And The Sims:

Wright followed the opportunity he saw, and the game became more and more about the human characters until they became the focus of the game. He didn't plan this result; he discovered it.

(Sylvester 2013: 282)

In conclusion, I will almost certainly maintain agile practice in my future software projects, but also be mindful of those serendipitous moments which gives the end-product that touch of magic.

Bibliography

1. BRACKEN, Mike. 2015. “Building on the Steel Thread - Government Digital Service.” Available at: https://gds.blog.gov.uk/2015/07/24/building-on-the-steel-thread/ [accessed 27 Nov 2020].
2. CASEN, Sarah. 2016. “White Boxing Your Game.” Available at: https://www.gamasutra.com/blogs/SaraCasen/20160713/276970/White_Boxing_Your_Game.php [accessed 27 Nov 2020].
3. KNAPP, Jake, John ZERATSKY and Braden KOWITZ. 2016. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. London New York Toronto: Bantam Press.
4. RASMUSSON, Jonathan. n.d. “Iterations.” Agile In A Nutshell. Available at: http://www.agilenutshell.com/iterations [accessed 26 Nov 2020].
5. SCHELL, Jesse. 2019. The Art of Game Design: a Book of Lenses. Third edition. Boca Raton: Taylor & Francis, a CRC title, part of the Taylor & Francis imprint, a member of the Taylor & Francis Group, the academic division of T&F Informa, plc.
6. SYLVESTER, Tynan. 2013. Designing Games: a Guide to Engineering Experiences. First edition. Sebastopol, CA: O’Reilly.