If all you have is a hammer…

… everything looks like a nail

But is it? Not everything, certainly.

The manifesto, in its day, was written by a bunch of software development consultants. “Development” being a key term here.

“Operations” was so much of a different organizational silo then, that it took another eight years1 before the term “DevOps2” was coined. So…

“Software”, you say?

Also not. Attentive readers of the Manifesto will be aware that even in 2001 there wasn’t a clear line keeping “software developers” in and others out. Quite the opposite. “Business people and developers must work together daily throughout the project“, they said, and “sponsors, developers, and users” and “architectures, requirements, and designs emerge from self-organizing teams“3. So if the criterion is neither the domain (“software”) nor the function (“programmers”) – how do you decide where to apply “Agile”?

It’s complicated

…or rather: complex, chaotic or disorderly. Using the Cynefin4-framework, we would cast our net at any problem domain outside of “clear“. Whenever there isn’t a simple, “best practice” approach to what we intend to accomplish, whenever the “unknown” sneaks up on the “known” with some regularity5, we’re better off being ready to adapt rather than “following a plan”6.

But how can we know

… what is “unknown”? That one is actually easy: “f*** around and find out“, they say. And there really is way around. Or, if salty language isn’t your thing, let’s call it “the scientific method7“:

  1. form a hypothesis
  2. test the hypothesis
  3. if the hypothesis was true – publish
  4. if it wasn’t – back to step 1

Experiments and Waterfalls

…and where to draw the line? The answer to that one is slightly more uncomfortable and yet another question: “how much can you afford to lose?”. I’d suggest to take inspiration from the Agile Manifesto already and limit yourself to “working” [software]8 as the minimum and “a couple of weeks […], with a preference to the shorter timescale” as the maximum.

Within this shortest possible timespan from hypothesis to proof, feel free to “waterfall9” the following to your heart10‘s content:

  1. plan what you are going to do, investigate, design, sketch … for as much time as you have set aside for this
  2. resist extending the timeline for your planning, resist going back and changing any of your planning, stay on track so you can make the deadline you have set yourself for the doing of what you planned in step 1
  3. once you are done / the deadline has arrived (whichever happens earlier) – check what you have created: is it what you wanted? What your customers wanted? Is it “working”?
  4. then: act11 on what you have learned

Did you get what you wanted?

If so, feel free to increase your bet to a more ambitious definition of “working”. Feel free, eventually, to increase your bet to a longer timespan.
Feel free, eventually, to say that “Agility” isn’t what you need, because the problem domain is obviously “complicated” at most and how you’re solving it is “good practice” at least, maybe even “best practice”, because it is “clear”.

In any other case

… “classical project management” and “Waterfall12” are not sufficient and most likely will not be so in the future.

“If only we can be a 100% right in our Planning,” the thinking went, “then we will reap never-ending economies of scale in our Doing” … ignoring the mathematical truth, if inconvenience, that the time needed to “Do” something will never quite converge towards zero, while the multiplied probability of getting the “Plan” right for lots of different things certainly does.

So if “Planning” really only works for very simple things and “Project Management” can’t compensate for more than the very simplest of planning errors,

…what better tools do we have?

Follow me here for more…

  1. 2009 – https://en.wikipedia.org/wiki/DevOps ↩︎
  2. if you want to read up, a better starting point might be https://www.goodreads.com/book/show/8686650-continuous-delivery ↩︎
  3. principles 4, 8 and 11, respectively: http://agilemanifesto.org/principles.html ↩︎
  4. https://en.wikipedia.org/wiki/Cynefin_framework ↩︎
  5. if not predictability – easily confused topics, for sure, but quite different in how they should be treated ↩︎
  6. “Responding to change over following a plan” is what gave “Agile” it’s name, after all ↩︎
  7. https://en.wikipedia.org/wiki/Empiricism or https://en.wikipedia.org/wiki/Scientific_method respectively ↩︎
  8. feel free to drop “software” and enter any problem domain of your own choosing ↩︎
  9. https://en.wikipedia.org/wiki/Waterfall_model ↩︎
  10. intuitively, I will admit, “Waterfall” just feels right. “Plan perfectly“, then “do not deviate from this perfection” even has some logic to it. If only perfection were a thing… ↩︎
  11. https://strategicmanagementinsight.com/tools/pdca-plan-do-check-act/ … the “Waterfall” before someone tried saddling it with “economies of scale” https://en.wikipedia.org/wiki/Economies_of_scale and forgot all about “lot size one” https://www.allaboutlean.com/one-piece-flow/ ↩︎
  12. …which even Winston Royce, who is credited for writing “the paper” on it called “risky and [inviting] failure“. For whatever reason, the paper is rarely read and historically misunderstood in that Mr. Royce actually tried to warn against adopting such an approach ↩︎

Origin Story

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…

—

  1. yes, I am proud: https://www.pocketgamer.com/space-invaders-evolution-mob/space-invaders-evolution/ ↩︎
  2. 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 ↩︎
  3. 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 ↩︎
  4. https://dictionary.cambridge.org/dictionary/english/project-management ↩︎
  5. https://ipma.world/ipma-certification/4lc/certified-project-manager-level-c/ ↩︎
  6. “The best architectures, requirements, and designs emerge from self-organizing teams.” => https://agilemanifesto.org/principles.html ↩︎
  7. https://en.wikipedia.org/wiki/Space_Invaders ↩︎
  8. “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 ↩︎
  9. https://www.mobygames.com/game/47519/space-invaders-evolution/credits/j2me/?autoplatform=true ↩︎
  10. see above ↩︎
  11. “Respect” being on of Scrum’s core values. For a number of reasons => https://www.scrum.org/resources/scrum-values ↩︎
  12. https://www.mobygames.com/person/509794/richard-skews/ ↩︎
  13. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” => https://agilemanifesto.org/principles.html ↩︎
  14. can’t link to that often enough, can I? => https://agilemanifesto.org/principles.html ↩︎
  15. 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 ↩︎
  16. 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 ↩︎
  17. did I mention feedback? ↩︎
  18. Turns out: players don’t mind winning if it looks like the game’s fault. Who’d’a thunk? ↩︎
  19. 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 ↩︎
  20. “Customer collaboration over contract negotiation” => https://agilemanifesto.org/ ↩︎
  21. https://www.goodreads.com/book/show/19288230-scrum ↩︎
  22. Scrum is one of those “easy to learn, difficult to master”-things. More on that here ↩︎
  23. https://scrumguides.org/ ↩︎
  24. https://agilemanifesto.org/ ↩︎
  25. https://www.goodreads.com/book/show/67833.Extreme_Programming_Explained ↩︎
  26. no. But it’s a good place to start ↩︎
  27. 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. ↩︎

About this site

The purpose of this site is to be a cookbook of all my favorite Agile recipes. The Agile Manifesto1 itself being no more than two screens of text, the Scrum Guide2 very purposefully leaving out any kind of implementation details and Kanban, Lean and TPS never having arrived at any kind of “definite” stage – one thing I find myself doing a lot as an Agile Coach is starting answers with “It depends…” [on your situation], then being asked to provide the “how are other people doing this?“-[see above: non-existent]-Industry standard, before relenting and responding on my own with “before we schedule a training, please have a preread here“.

While nobody serious about that first line3 in the Agile Manifesto will sell you any kind “best practice”, there certainly are plenty of well-tread stepping stones from shu to ha to ri4. Or recipes, if you so like. You’ll not always have the right ingredients ready, you’ll not always like the taste, but you’ll also not need to re-invent the proverbial wheel.

This site exists as my own personal little cookbook of such Agile recipes, to provide the “here” to link to from that first paragraph. Since I launched the first version of this site in 2018, the majority of the links I collected here has gone stale, was hidden behind paywalls or otherwise become unusable; so for my re-launch this time (2024) I have set myself the goal of having each entry stand on it’s own, with links only for reference. This is also the point where I ask you for help: please let me know when something here can not be understood without external context – I’ll try to fill in the gaps ASAP.

  1. https://agilemanifesto.org/ ↩︎
  2. https://scrumguides.org/ ↩︎
  3. “We are uncovering better ways of developing software by doing it and helping others do it” – emphasis added by me. While not explicitly stated in the Manifesto, many words have since been written on Agile subscribing to Empiricism (https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum) vs the rather misleadingly named paradigm of Scientific Management (https://en.wikipedia.org/wiki/Scientific_management) ↩︎
  4. https://en.wikipedia.org/wiki/Shuhari ↩︎