The way I stumbled onto Agile was – as these things go – mostly by accident. We did a project, it turned out very good1, and eventually I wondered: apart from the obvious reason of us being bloody geniuses2 – could we do this on purpose? Could there be method to the madness? Would we be able to repeat this3?
Let me start by describing
where we started from:
- We did have a guy doing “project management”4 (lower case), but way too little bandwidth to do “Project Management”5 (upper case). Meaning: in terms of project execution, we were pretty much on our own6.
- The project being a re-imagining of one of the earliest video games ever7, which is to say: simple8-to-the-point-of-being-trivial.
- Gottfried9, Armin10 and me were in awe11 of the source material… we could not mess this up!
- Our customer contact – Mr. Rik Skews12 – just as enthusiastic about the source material as we were and willing to engage with us early and often13.
As you can see – several of the Agile Principles14 were already in place when we started. Others apply to
how we went about it:
- First, we built the most basic re-engineering of the Space Invaders core15 concept: a grid of „Invaders“ moving in a zig-zag pattern from top to bottom, a „Defender“ able to move left, right and shoot; Winning and losing.
- The first milestone was about a month in. We had: a feel for how quickly the Invaders, the Defender and the bullets should be moving, a first version of how all of it was going to look; and not much more.
- The feedback to the core game was very positive (well: it’s a classic16 for a reason, no?). But the feedback to our graphic design was a hard no: no messing with the Invader designs. Pixel-by-pixel as in the ’78 original. No glowy outlines, no new designs, no adaptations whatsoever … which on a minimum screen-resolution of 124*124 creates a bit of a challenge, believe you me!
- So what did we do? We fixed what we had according to this feedback17 and used only the originals. And only those. Different-sized versions needed to be exactly twice, thrice (etc.) the size of the originals. For resolutions where this looked awkward… it just did. The „hit-boxes“ for the Invaders stayed proportional to the screen-width, though, so every once in a while we counted something as a „hit“, even though the „shot“ and „the Invader“ didn’t actually overlap18.
- You will probably already be able to guess one trend many agile teams see early in their life-cycle and which is highly frustrating to all those being sold on „the iron triangle“19 of project management: Scope suffered. Scope suffered badly. Of all the things that were planned for the next milestone, a month after the first, we delivered about a third. The second milestone is not something any seasoned Project Manager cries wolf about… but they do get concerned. It’s around that time that Gottfried’s assignment to the project was bumped from „you keep a close eye on Sepp, ok?“ to „as much of your time as you can spare, considering the other things you’re involved in“.
- Yet: the customer was happy. The new version of the graphic design would pass the license-holder’s requirements and the (few!) things we managed to add made what we had just a little better, rather than worse (I think we started with multiple waves of attackers and a scoring-system … very simple stuff, technically, if we’re honest).
- And so on for the next milestone and so on for the next. Way less than what had been promised when the contract20 had been set up, but for every milestone the customer feedback was in and we had just a little more than the milestone before.
- Fast forward to the last one or two milestones: yes, by this time management become concerned. But then: we had a customer heavily bought in to the thing we already had. This was his baby as much as ours and he loved it just as much as we did and when push finally came to shove, he preferred to compromise on scope of what was still left from the contract and focus on quality.
- „Twice the work in half the time“21? Not really. Not at all, actually. A customer satisfied, this indeed. A team proud of its work, oh yes. Eternal riches? I never found out, tbh.
- Happy ever after? Not quite. A lot of things went right in the – let’s call it: accidental – Scrum described above. A lot of things went wrong in the naive22 Scrum we did next. It took me a couple of years before I felt compelled to write this thing here. But allow me to summarize
what happened next:
At one point during the project, Gottfried had forwarded me a link to the Scrum Guide: „You should read this. I think this is pretty much what we are doing here.” I read it then, judged it smart – if a bit “duh” (of course that’s how things should be done!) – and duly forgot.
When we were done, I read it again. Read the Scrum Guide23 again, read the Agile Manifesto24, read that XP25 book and started to take the whole thing seriously.
Fast forward several years. „Scrum“ was very much officially how video game developers here in Vienna worked. But „Scrum“ isn’t „Scrum“, as you will no doubt have realized. One „Scrum“ fails where another succeeds and the guide is anything but specific on how to do it right. „It’s a framework“, they say, „not a methodology“. And leave you there, bewildered as to what should be the difference.
Is “Scrum” even necessary26? Isn’t it all just “a mindset27“? Ask yourself
should you be doing „Agile“?
That’s an interesting question. It all depends on the „why“. Your „why“ might differ from mine – actually: most definitely yours will be different from mine, sometimes by a little, sometimes by a lot. „If all you have is a hammer, every problem looks like a nail“ they say and boy do I love to hit things with my Agile hammer… but is your problem even this proverbial nail? Follow me to find out…
—
- yes, I am proud: https://www.pocketgamer.com/space-invaders-evolution-mob/space-invaders-evolution/ ↩︎
- well yes, of course, we were. Admittedly, somewhen during the course of the project Gottfried even forwarded me a link to the Scrum Guide. Which I read, considered smart (if somewhat “duh – obviously that’s how things should be run”) and duly forgot until it became time to reflect ↩︎
- mostly repeatable: https://www.pocketgamer.com/galaga-x/galaga-x/ … there’s a number of reasons the next one turned out good-ish, but not quite as good as our first run. More on that later ↩︎
- https://dictionary.cambridge.org/dictionary/english/project-management ↩︎
- https://ipma.world/ipma-certification/4lc/certified-project-manager-level-c/ ↩︎
- “The best architectures, requirements, and designs emerge from self-organizing teams.” => https://agilemanifesto.org/principles.html ↩︎
- https://en.wikipedia.org/wiki/Space_Invaders ↩︎
- “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” => Gall’s law ↩︎
- https://www.mobygames.com/game/47519/space-invaders-evolution/credits/j2me/?autoplatform=true ↩︎
- see above ↩︎
- “Respect” being on of Scrum’s core values. For a number of reasons => https://www.scrum.org/resources/scrum-values ↩︎
- https://www.mobygames.com/person/509794/richard-skews/ ↩︎
- “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” => https://agilemanifesto.org/principles.html ↩︎
- can’t link to that often enough, can I? => https://agilemanifesto.org/principles.html ↩︎
- let’s not call it “Minimum Viable Product” – I was naive about the term then – an to this day it’s often misused. I’ll add my 2 cents here at another time, for now read up here: https://en.wikipedia.org/wiki/Minimum_viable_product ↩︎
- legend has it that at it’s original launch it caused a shortage of 100-yen coins, that’s how much people loved it: https://allincolorforaquarter.blogspot.com/2013/11/video-game-myth-busters-space-invaders.html ↩︎
- did I mention feedback? ↩︎
- Turns out: players don’t mind winning if it looks like the game’s fault. Who’d’a thunk? ↩︎
- The “Iron Triangle of Project Management” states that you can fix two, but only two of the following parameters: scope, quality or time. Reality for most project managers is that they’re expected to keep all three. Pity them. The practical result is that while one of these parameters is usually upheld, this happens to the detriment of (at least) one of the others, but late in the project and to everyone’s “surprise”. => https://en.wikipedia.org/wiki/Project_management_triangle ↩︎
- “Customer collaboration over contract negotiation” => https://agilemanifesto.org/ ↩︎
- https://www.goodreads.com/book/show/19288230-scrum ↩︎
- Scrum is one of those “easy to learn, difficult to master”-things. More on that here ↩︎
- https://scrumguides.org/ ↩︎
- https://agilemanifesto.org/ ↩︎
- https://www.goodreads.com/book/show/67833.Extreme_Programming_Explained ↩︎
- no. But it’s a good place to start ↩︎
- also: no. As much as you may want to get something done – you have to do it to see results. This is as true for “Agility” as it is for doing your chores, obeying traffic rules or exercising your body. No such thing as a free lunch. As always, actually doing it requires work and at least an idea of where to start. ↩︎