I’ve been carrying this bit of paper around in my bag for about six months. It’s a scribble I drew once while on one of ‘those’ conference calls. You know - the one where someone is talking and you are not entirely sure why you are dialled in, let alone why you are attempting to listen.
At the time I was trying to work out a simple way of showing different Agile adoption approaches and how they can so easily go awry.
So what in the world does this scribble show?
Well, basically, the idea that the scribble is trying to get across is that you shouldn't adopt frameworks without the manifesto or principles. In the same way, stepping into the Agile manifesto statements and principles will undoubtedly lead in some way to practices in Agile frameworks. Common sense really, but how many of us are working in teams and organisations that are solely focused on one side of this picture?
It’s a common problem, and as a coach this is a situation I've seen time and time again. It mainly falls into the ‘Scrum-But’ scenario, which is inherently a problem of the organisation not looking to the wider principles, behaviours and culture to support the framework adoption.
Let’s have a closer look at the picture.
On the left side of the picture we have the manifesto with its principles shaping behaviours and culture. Under this I wrote ‘legacy’. By this I meant established software development organisations that are failing due to not looking at the principles, not looking at their culture and not looking at its behaviour to improve performance. Arguably they may well be employing Agile practices from the frameworks, but without the behaviour change it will ultimately revert the way of working back to the old ways with just the terminology changed to sound more Agile. Yes, we’ve all been there. :-)
On the right side of the picture we have the frameworks. Similarly, under this I wrote “new”. By this I meant new projects, programmes or, in best cases, brand new organisations that look to Agile frameworks to solve their change and uncertainty challenges. This is again another common approach but without understanding why Agile is beneficial to manage change, or how frameworks help, the purpose will quickly separate from the business strategy and ‘JFDI’ will take effect.
The underlying reasons for organisations looking at Agile is written in the big box at the bottom: Control.
Control is an interesting term alongside Agile. I hope we have all seen the Agile myths by now, understanding that both the principles and frameworks suggest more control than we would usually draw into our way of working. So to me, the need for control should not eliminate Agile in any way.
The fact that your teams and organisations are shifting to an Agile way of working is a great thing - whether it is a conscious quality or time to market decision, or just ‘Ooh look, Agile is the coolest thing right now’, it’s a great shift. Anything that spawns continuous improvement and introspective criticality is great.
To support this, the more interesting word that should be in a much bigger box is measure. Only by measuring can we learn. Again, thinking of the Agile basics of empiricism, learning through measuring will only strengthen our organisations and teams, and allow them to make informed decisions around principles, behaviours and frameworks.
So that is my scribble; maybe it’s a decision matrix? Should you find yourself on one side, maybe it’s time to ask yourself: What are we missing? What could we be doing? How can we improve?