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 no other way. 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: “how much can you afford to lose?”. I’d suggest to take inspiration from the Agile Manifesto already and limit yourself to “working” [software8] 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 can 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 another problem domain of your own choosing here ↩︎
  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 ↩︎