The Ninja and the Samurai
You may have heard this (Gartner 2014) metaphor - of the ninja and the samurai - to describe the difference between waterfall and agile. The Ninja is agile. Fast. Nimble. Low ceremony. The Samurai is high ceremony. More deliberate. But just as likely to be effective. Of course, Gartner have long since dropped this analogy. I heard the reason was "both were still cool" and they wanted to send a clearer signal that agile=cool. Hmm. As you can imagine, this does not impress me at all. I actually liked the original "bi-modal" concept; i.e. that some things are better done in mode 1 (Waterfall) and other things best done in Mode 2 (Agile). I doubt, for example, you would put your own child on a "minimum viable product" (MVP) rollercoaster. Or personally take an MVP Space Shuttle to the moon. Let the monkeys 'fail fast'.
I might sound like I am against agile. I am not. I am against people who apply it badly.
> For a tool to help you decide Mode 1 vs Mode 2, check out my Agile-o-meter
> If you'd find a little case study helpful, check out "the mayor of Kingston Town"
> Or read about my "three best situations to use pure agile"
People don’t plan to fail
They fail to plan. In truth, you wouldn’t be a very good ninja if you went into a fight with no clear intelligence on what you were up against. Or any plan to deal with that. This would not be cool. This does not stop people from doing exactly that, particularly when they first try agile adoption. Zero-requirements Kanban is actually a thing! I call this the “make it up as we go along brigade”. It rarely goes well.
Developers are usually happy to go along with this, because it allows them to more or less do what they want (which is to focus on doing cool work, rather than necessarily useful outcomes). They like to call this “the principle of self-organising teams”. I like to call it “letting your teenage kids look after the house". And I say this with the greatest of kindness, as someone who (a) came up via the dev route, and (b) loves his kids.
So, having established (I hope) that having some sort of plan is useful, what next?
The Discovery Phase
Ask any organisation with mature agile adoption and they will talk about the vital importance of a discovery phase. This more or less equates to what is often called (the completion of) a “high level design” in Waterfall. In other words, you have (a) gathered high-level requirements (probably expressed as a set of "user stories"), (b) designed the broad solution design you plan to engineer, and (c) sized the duration, costs and resources you think you need to deliver. Sounds like a good idea to me!
At this point, some of you might be thinking “isn’t this waterfall”? And in all material respects you’d be right. It is. At least, so far. Whatever anyone might say. This is not something to freak out about. Chill. We will get to that in a moment.
Suppose our Ninja (in a scouting discovery phase disguised as - I don't know - a sushi delivery guy) determines there are 40 people with big swords guarding his assassination target. When the time comes for the mission proper, he might take a few friends and go at night! Perhaps with an automatic pistol and certainly with a plan. He wouldn't go along with a little knife in broad daylight and make it up as he goes along!
So, a plan. Tick. Some sort of discovery. Tick. What next?
Introducing Tri-Modal Projects
At the risk of inventing a mouthful, I would like to propose a new terminology of "tri-modal"; where Mode 1 is (fully) Waterfall, Mode 2 is (fully) Agile, and Mode 3 is a Hybrid (of Waterfall and Agile) - i.e. Waterfall Discovery to HLD, then Agile Delivery for Build/Test/Release:
Note I am deliberately not calling this WAgile, as this seems to me a pejorative term used by shallow thinkers of a zealous demeanor. More specifically, WAgile is variously described as a "mix" (as in "mixed up") of Waterfall and Agile. Or Waterfall Project Management thinking imposed on top of Agile Development. I am not proposing mixed up thinking. Nor am I suggesting Project Management should ever be associated with (as in tied to) any SDLC- whether Waterfall or Agile - but rather remain abstracted from it (as it should).
I am also not calling this "big design up front". Because - again - this terminology irritates me. It seems to me those words are chosen deliberately not as a contrast to the small, iterative design components of each agile sprint, but rather to suggest some sort of excess of over-engineered design before the developers make a jail-break for freedom.
So Waterfall Design / Agile Delivery (or WD/AD for short). Catchy, eh? I would like to humbly suggest that tri-modal WD/AD is actually what all sensible organisations actually do. Whether or not they actually call it this. And whatever funny fags they might be smoking. You might think I am overly labouring the point. But as one gets older, one can't help but observe what utter nonsense people actually say and do when (particularly at first) attempting agile adoption. At the risk of simply annoying you, I am going to look at two further areas - quickly - to hopefully illustrate what I mean:
The Agile Business Case
If you are routinely in the business of preparing investment cases for a project (usually a pre-requisite if any work is actually to proceed) you might recognise this challenge. Your decision-makers want some certainty (within a limited tolerance) of how much it is actually going to cost you to complete the work. This - annoyingly - tends to include little details like what software products or hosting provider you propose to use and how many licenses and capacity you need to buy & when. In general, these are questions that can only be answered with at least a high-level design. "Can't we just make it up as we go along?" is unlikely to wash.
The Agile Partner Contract
If you are using a third party to resource the work, your procurement advisor is likely to start with that glorious opening gambit of "we need to fix-price this work" to avoid the risk of cost overruns. The next question is likely to be "what is your specification for the work?" or even - if it is an especially bad day at the office - "we should tender this and get it out to variety of competing companies to drive the best price... have you written an RFP document yet?". Again, "why don't we just make a start and see how we get on?" is unlikely to get much traction.
Tri-modal Financials & Commercials
If you are tri-modal, there are simple answers to both of the above (plus to a range of other parties like your Risk & Controls team, your Security team, and more): Waterfall to Design, then Agile for Delivery. Your first business case (and vendor contract) is time & materials for "discovery", most probably time-boxed to limit risk of overrun. You will get to the maximum specificity you can in the time and money you get approval for. You then come back with a second business case that will include a more precise fix on (for example) software & hosting costs, plus a much more reliable estimate of build resourcing, duration, and costs. That, in turn, can form the basis of a fixed capacity (or capped T&M) vendor contract or SoW. Or even more exotic innovations, like a "cost-per-story-point" (or piece-rate) agile contract.
> I cover this in much more detail in my "creating an agile enterprise" article [3]
Final Thoughts
I suppose what I am really saying - as usual - is that dogmatic zealotry doesn't really survive first contact with reality. If you are serious about greater agility in your solution delivery projects, you must first accept that no-one is going to give you a blank check and say "just crack on". You wouldn't build your own house that way. You wouldn't trust your children's safety to that. And you wouldn't spend your own money like that. Time to embrace "tri-modal". You know it makes sense!
© David Viney 2023. Licensed for re-use with attribution under CC BY 4.0
Preferred Attribution Code Snippet
The <a href="https://www.david-viney.me/post/tri-modal-for-agile-project-management">Tri-modal for Agile Project Management</a>, by <a href="https://www.david-viney.me/">David Viney</a>, licensed under <a href="http://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>Footnotes
[1] Forthcoming articles in this series; please check back soon
Like the Post?
Comments