It‘s a busy summer (we will soon be moving house), so Weekend Reading will remain a bit erratic for the next few months, my apologies…
(tldr) Recently I had one of those Agile/agile discussions again. 20+ years into the Agile Manifesto, a key misconception still seems to linger.
There are organizations, often with a very successful engineering and manufacturing history, where certain management feels stuck in traditional and somewhat bureaucratic ways of project management. Under the pressure of digitalisation, they call us to help finally introduce Agile, hoping to improve their organisation’s agility overall.
The misconception, however, is that agility can be brought about by a method or a set of tools that one can introduce. Yet it is a character an organisation possesses, or it doesn‘t.
Agile (with capital “A”) on the other hand is a well-established set of methods – think Scrum, Scrumban, … – that applied in the right context – enables organisations to deliver more value faster, in particular under uncertainty.
For this reason, Agile has the potential to improve organisational agility. Yet this comes at a prize, that many hesitate to pay: a major change of management style.
In order to improve agility via the introduction of Agile, they have to let go of deciding the minute WHAT and HOW (as well as possibly the WHEN), and instead focus more on the WHY. To think more strategically, if you will. And leave most of the WHAT and definitively the HOW to empowered and largely autonomous (Agile) product teams.
Here is where our conversations tend to become difficult. Some of our prospects would just like to see the introduction of methods that deliver the results of their – in a fast-paced environment frequently changing – decisions quicker and more predictably.
To reap significant benefits from introducing Agile methods though, we need to ask them to transform their ways of working at least as much as their teams’. To start thinking about longer-term goals and strategic (product) initiatives. To decouple teams as much as possible. To create the technical platforms that these loosely coupled teams can deliver value on – reducing dependencies requiring management involvement dramatically. To empower Product Managers and Product Owners to decide HOW to deliver maximum customer value. Based on clear goals and well-defined initiatives.
This is requires a certain standing, sometimes even guts. Not everybody feels empowered or is ready to take the plunge. Therefore, these organisations often end up with some type of “managed” or “planned” Agile (e.g. SAFe) that improves delivery, but not agility.
For that reason they remain very susceptible to the ripple effects of any change.
Worst of all, they stand little chance of becoming truly agile (with a small “a”) at all.
A few ideas how to become more product strategy driven (plus a rant!) below:
How to Define Your Product Strategy
– by former Netflix CPO Gibson Biddle – almost a book (12 installments), but VERY deep.
WHY IS PRODUCT STRATEGY CONFUSING?
– by Steve Forbes. Concise read with actionable insights.
Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness
– by Sean Dexter. A bit of a rant. But not without a point.
It’s been a very early start for me today. Time to sign off.
Have a great weekend!