A river as a metaphor to explain agile ways of working

One of the biggest gripes agile practitioners have these days is the increasing appropriation and codification of agile concepts, often through branding and commercialisation of frameworks, methodologies, etc.

The great thing about standardised agile methodologies / frameworks is that they are accessible to folks; i.e. it's much easier for a team to adopt Scrum than to create their own way of working from scratch.

But, there's a potential downside as well, sometimes:

1. Folks adopt a framework in a dogmatic fashion, not understanding that any given approach isn't always going to fit their situation well. And only being aware of a single agile method/framework means they often fail to try alternate approaches even when they recognise their current efforts are not working. Branded agile methods & frameworks are often a great place to start - but that's often how they should be regarded - as a start. If 2 or 3 years later, you are still practicing the same way, then I'd suggest you've missed the point.
2. It places the focus on specific practices first and foremost, and folks will often forget the principles upon which those practices are based. This means it's entirely possible that folks might actually become quite good at those specific practices (i.e. as dictated by that brand of agile) and they then assume they are a mature agile shop - whether that's the truth or not.  I'm sure you've heard that saying that 'good is the enemy of great'.

So you can see why some agile practitioners bristle at various agile 'brands'. They can be a great way to get people started on the agile journey, but also act as a straight jacket and can become limiting when held on to too tightly.

A few years ago, Alistair Cockburn (one of the original creators of the Agile Manifesto) produced 'The Heart of Agile', to remind folks of the underlying truth behind the branded agile methods and frameworks. While there is nuance to it, the overall message is very simple. We should:

• Collaborate
• Deliver
• Reflect
• Improve

So, what this boils down to, is that even if you aren't following a specific methodology or framework but are delivering value to customers early, getting fast feedback and quickly iterating / course-correcting...

Surprise! You might be more agile than any given team that is following a doctrine. And don't let anyone tell you otherwise - especially if they have a commercial or self-interest in doing so.

But this type of messaging is often lost in the marketing collateral.

To help combat this, I think there is complimentary messaging that adds important context to simple messages like The Heart of Agile; and I'd come across a metaphor I'd like to share, that of agile practices being likened to a river.

Let's think of the agile team as a flowing body of water... a river; the team itself is represented by the water and the movement of the water represents the team delivering value (i.e. to customers). So, when the river is flowing freely, this means the team is consistently delivering value to customers.

But the reality is that few teams are ever unhindered - just as rivers flow with varying degrees of hindrance. That's where rocks come in to the picture. In this metaphor, a rock represents some thing that may be slowing or otherwise preventing the team from delivering value; often we might refer to these as bottlenecks, blockers, dependencies, etc.

So, removing bottlenecks, blockers or dependencies is like removing rocks from a river; sometimes you need to do this right away (e.g. when it prevents the river from flowing), but sometimes you will simply bypass the rock (and return later to remove it so it doesn't hinder you again in the future).

But every now and then you will encounter a dam; something that genuinely prevents the team from flowing altogether. What does a river do in this case? Does it stop flowing? Maybe for a little while, but then the relentless pressure, and the pursuit of a path of least resistance leads the water to eventually overcome the dam (hopefully demolishing it, and not just flowing over the top leaving the dam in place).

There's another important agile concept that relates well to this metaphor; and that's Empowerment and Autonomy. For a team to 'flow', it needs to be able to make its own decisions about how it delivers value. Like a river, it cannot flow if it needs to stop and ask for permission every 20 meters (a ridiculous proposition, I know, but it's a relevant point).

So, perhaps it might be helpful to folks when trying to understand agile methods, to think of a river - and how it constantly flows. Rocks are often encountered, but the water always finds its way around (or over).

The point... always keep moving... think about how you can continue the flow, while staying true to Agile principles.

Side note: You can see how agile methods align so well to Lean Systems Thinking because that focuses on improving the 'flow' of work through a system.

Another side note: taking the path of least resistance does not mean you have an excuse to cut corners on quality. Sticking to the metaphor, compromising quality would represent polluting that river, sometimes to the point of slowing its flow and harming the customer.