The Myth of Doing Agile vs Being Agile
This post is aimed at those who have started their path in agile and are faced with the wash of positions about it.
As a consultant I get into discussions all the time about doing agile versus being agile. Note the italics: most folks I talk to have it that there’s a difference, that you can do one and not the other. That’s a myth — and I’ll unpack it here.
It results from looking at teams who are using a process describing itself as agile but for some reason aren’t seeing much of the benefits of working in what can be quite a confronting new way. Perhaps they’ve adopted new words, like story or ceremony, and they’re having shorter more frequent meetings. It might be going kinda well, which is to say it’s running like a smooth version of a normal project. But there’s something missing, something intangible. The touted benefits that empower a team and chop away needless work aren’t really there.
The flipside is teams that haven’t been drawn into a particularly rigid version of agile, and might not be using any of the accompanying language. No SAFe, no Scrum, just a bit of structure here and there, that is useful when it’s useful. These teams seem to kick goals and have a great time when doing it.
The apocryphal iceberg
The above is often explored in a PowerPoint slide with an iceberg on it. The bit of the iceberg above the water is the process-related stuff, and everything below is unquantifiable material pertaining to behaviours. Doing on the top, being below the surface. There are as many variations of this slide as there are cat gifs on the internet, and they can be equally confusing. The diagram is often whipped out to help sell an agile transformation, a form of sophistry suggesting that the seller knows about all the things underneath and the buyer would do well to trust them.
The idea here is that the stuff on the top is ‘doing’ agile, and the stuff on the bottom is ‘being’ agile.
Myth and reality
Here’s the thing — there is no such concept as doing versus being agile.
If your team is following an ‘agile’ process but is not responding to change, learning, performing, and adapting, then it’s not agile. Simple as that.
No amount of process can make you or your team agile, even if those processes are themselves called ‘agile’.
Processes that describe themselves as agile are a misnomer until someone acts otherwise.
Or, to put it another way, a process is only agile if it demonstrates the qualities of agility: responsiveness to change being the most important.
You might point out that I’ve contradicted my own argument, and that I’m splitting hairs around doing and being. Demarking process and behaviour and outlining the importance of the latter is the whole point of the dichotomy.
I’d say that the dichotomy itself, in attempting to be useful, misses the point. It implicitly suggests that you can do agile without being agile. And that’s nonsense.
Simply put, without the ability to respond to change, no amount of process will help you do agile. You can’t do agile without being agile. There is no difference.
Good and responsive
In the rare instance that the team is performing well and hasn’t really needed to respond to change then the point is moot: you’ve got yourself a great team, so make the most of it.
That’s not the same as an agile team. However, in this case forcing agile for the sake of it might not be necessary. It’s antithetical to agility to meddle in things that don’t need to be meddled in. Don’t fix what isn’t broken, especially if there are other teams in your business that need such attention.
No thin ice
The metaphor of the iceberg is still rubbish. It implies that an enterprise, no matter how large or small, might misinterpret the gravity of agile and crash upon it, making for a titanic mess. Unintentionally, myriad consultants (including me when I’m not my best) have acted as the fog in this marine metaphor, descending on steady-going ships and baffling them with gusts of new terminology.
In truth, there is no iceberg, because all the things that enable you to be agile are entirely visible, all the time. And they’re easy to change and to fix.
