“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?

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 :-)

--

--

Building online versions of agile workshops such as the No Estimates game, to see how close we can get to the face-to-face experience for remote or hybrid teams

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Steve Wells

Building online versions of agile workshops such as the No Estimates game, to see how close we can get to the face-to-face experience for remote or hybrid teams