“Agile is not appropriate in all situations”​. Hmm, what’s that smell?…

I’ve heard this phrase a lot recently; “you can’t use agile in all situations”. It’s usually preceded or followed by talk of “regulatory” or “compliance” projects, or a reference to “Cynefin” as justification. (Don’t worry — I’m not bashing Cynefin here! It’s a great framework. When understood and applied correctly…). Or, it might be “we’re just replacing something with a new platform, like-for-like (having not worked out if all the features in the old platform are actually used…). Whatever the justification, there seems to be this “self-evident truth” that “agile won’t work in situation X”

And this got me thinking.

What aspects of agile aren’t applicable in these “you just have to do it and have no choice in the requirements or solution” situations? Given we’ve set up a kick-ass agile organisation with a fantastic flat hierarchy and an amazingly collaborative culture (I assume…), and one of these “Just Do It” (JDI) requirements comes in, what parts of our agile practices, behaviours or values are we actually going to abandon. As a few examples:

• Are we going to stop collaborating with our customer on a regular basis?
• Are we going to stop reducing risk by releasing small and often? Stop doing CD and wait until we’ve built everything and then do a big bang release?
• Are we going to disempower our teams, and just tell them to build what we tell them rather than everybody — stakeholders, PO, UX, devs — collaborating and defining what to build between them? (Even though it may not be technically feasible because we haven’t involved the devs in the definition of the solution)
• Are we going to stop being transparent? Are we going to tear down our boards and just do a monthly report summarising that we’re 80% done (for the majority of the project. Because that’s what happens; “Watermelon RAG Status”)
• Are going to remove all WIP limits on our Kanban boards and stop trying to improve flow efficiency or reduce lean wastes?
• Are we going to remove psychological safety from our team and give (say) the tech lead ultimate power and sign off on every decision?
• Are we going to stop collaboration? Are we going to insist of reams of documentation that never gets read? Are we going to not follow agile principles like maximizing the amount of work not done?
• Are we going to have quality/sign-off gates and handovers between requirements, design, development, QA and UAT?
• Are we going to re-build all that hierarchy and bring in droves of Project Managers?
• Are we going to stop inspecting and adapting?

Of course not (I hope?) — that would make no sense. Why would we abandon all that wonderful mindset change, that fine new organisational structure, all those excellent practices — that all work, by the way — and all those high performance behaviours, just because, in this one, isolated case, “agile isn’t appropriate”. I’m no expert on Cynefin — I’ve read some stuff and seen some presentations — but I very much doubt it suggests we do any of the above just because we believe our current problem — in a sea of Complex problems — just one that is Complicated or even Simple.

I believe this is a smell.

This, to me, is really saying we don’t trust agile to deliver in these situations. We’ve forgotten the coin game; forgotten how releasing small and often, and receiving feedback, rather than defining everything up front reduces risk, rather than reducing the illusion of risk. We don’t believe that developers with up-to-date knowledge of best practices and the domain they work in can make better decisions about software solutions than experts who’ve never written code. We fully believe that we know better than our customers what they want — be they regulators, compliance bodies or any other kind of body giving us JDI requirements — and that there is no risk we’ve misunderstood what it is they require (so we don’t need to discuss it until big bang delivery date…)

In short, it suggests to me that we’re in “Agile is a Methodology/Process/Another Layer of Control” territory, and have not embraced the principles, values and philosophy of what it really is; are we actually really saying “it’s JDI, so we can’t use Scrum/Kanban/Scrumfall/My Unicorn Framework”.

So, here’s my challenge. Next time a project comes in (and it’s usually “a project”, we’re usually not thinking constant value delivery…) — in the comments of this post, please tell me which bits of “agile” you are abandoning — just for this one piece of work — and why.

And I’ll tell you why it’s wrong.

Now, there’s a challenge :-)