It was a Saturday morning. I was standing in line at a coffee shop, thinking about flow, as I often find myself doing when waiting in line. I reached for my phone to pass the time (while stuck behind a constraint in the cafe’s system of work) and sent the tweet above. This tweet went, relatively-speaking for me, viral, breaking in to triple digits of likes and retweets. It seems to have struck a chord.
This is the first of a series of posts, where I’m going to share a number of anti-patterns and corresponding patterns. It is worth noting that everything is context dependent. An anti-pattern for one scenario might be a pattern in another context. That said, I believe that the anti-patterns to be presented are applicable in the majority of contexts.
This is based on lessons learnt through doing including learning from failing. Along with many talented people, we’ve been servant leaders on better ways of working (the application of agile, lean , DevOps, design thinking, systems thinking and so on) across a large (80,000 people), old (300+ years old), global, not-born-agile, highly regulated enterprise, with personal experience of delivering change with an agile mindset, principles and practices since the early 1990’s, about a decade prior to the Agile Manifesto, when the term ‘lightweight processes’ was used. The anti-patterns and patterns are also based on learnings from the community, from other horses (rather than unicorns) on similar journeys, as we are all at a turning point in the Age of Digital.
Anti-pattern: Doing a capital ‘A’, capital ‘T’ Agile Transformation
A capital ‘A’, capital ‘T’ Agile Transformation, from the perspective of an employee, infers involuntary, mandatory change being done to you, whether you like it or not.
The capital ‘T’ denotes that you have to change and the capital ‘A’ denotes how you are going to change. Both of these words carry baggage.
Not surprisingly, this triggers fear and resistance for many reasons, including loss of control, uncertainty, changing habits, fear of failure, fear of incompetence, more work, change fatigue and ‘better the devil you know’.
From an evolutionary perspective, depending on the messaging of the why and depending on how the change is approached, and in particular for those with a fixed mindset, change drives a fear of survival, which leads to resistance and less rational thought as the primitive brain takes over.
Can I change? What if I can’t adapt? Will I still be able to pay the bills?
Looking at autonomy, purpose and mastery, as per Daniel Pink’s Drive and that human motivation is primarily intrinsic for knowledge work, two of the top three motivators have been taken away. There is a lack of autonomy (you have to do this thing) and a lack of mastery (you’re a beginner again, possibly after a long career). If the why is articulated as cost reduction or profitability, meaningful purpose is also removed, taking away all three categories of human motivation.
This evolutionary fear of change is also seen in loss aversion, which is people’s tendency to prefer avoiding losses to acquiring equivalent gains. This evolutionary tendency to loss aversion further cements people’s desire to maintain the status quo.
Agile should not have a capital A unless it is at the start of a new sentence. Agile is not a noun. It is not a trademark. You can’t buy Agile In A Box (really, you can’t). By the very fact that agility is optimal in complex contexts, where the What and the How is inherently unknowable in advance, where acting in the space changes the space, there cannot be a one size fits all solution. It is about exhibiting agility, being agile not doing Agile. It is first and foremost a mindset that informs every single deliberate decision and automatic reaction.
The capital ‘A’ Agile mindset leads to the Agile Industrial Complex. It leads to a number of anti-patterns, such as the imposition of practices on people and to certification schemes with questionable value. We don’t want agile for agile’s sake or DevOps for DevOps sake. This can lead to local optimisations where the expected business benefits, end to end, do not materialise.
There is a need to focus on Why are we doing this and what the desired business outcomes are. Then agile, lean, DevOps, Design Thinking and so on are bodies of knowledge, they are tools in the toolbox, to achieve those outcomes, applying what works in your unique context and continually improving through experimentation.
Pattern: Start with Why and focus on Outcomes
First, as well articulated by Simon Sinek, start with why. There should be a clear and well communicated Why for the organisation of the need to change ways of working, why constant improvement is needed, with nuanced context-sensitive and relevant definitions of why for the any sub-organisations within the parent organisation which may have their own cultural norms, history, folklore and legacy ways of working.
The ‘why’ should be more than profitability, shareholder returns or stock price. As per the article ‘The Irrational Side of Change Management’
Research shows that when employees are asked what motivates them the most in their work they are equally split across five forms of impact: (1) society (2) customer (3) company (4) team (5) the individual.
Teal organisations, the most evolved, are driven by a higher level purpose. This is echoed in ‘Drive’ by Dan Pink, where people are motivated by a transcendent purpose. Ensure that the definition of why has a higher level purpose and covers society, customers, company, team and the individual.
From there, identify high level, thematic desired outcomes. Start with what does awesome look like, what is the current reality and what are the obstacles. Next, derive, prioritise and theme outcomes which get you to your state of awesomeness.
For us, our desired outcomes are described as Better Value Sooner Safer Happier, each of which is measurable.
- Better => Quality => Production Incidents, Resilience, Static code analysis measures
- Value => context specific unique measures per quarterly Business Outcome (e.g. customer Net Promoter Score increased 10 points, reduced carbon usage by 10%, increased gender diversity by 15%, increased lending to small and medium firms by £100m, reduced Risk Weighted Assets held on balance sheet by 20%, etc.)
- Sooner => Flow => Lead Time, Throughput, Release Cadence, Flow Efficiency. Be wary of becoming a feature factory. Reduce Lead Time and spend more time with the end users, refactoring and innovating.
- Safer => GRC Control Compliance (e.g. InfoSec, Know-Your-Client, Data Privacy, GDPR type mandatory requirements). Speed & Control. Agile not fragile.
- Happier => increased customer and colleague satisfaction, via surveys and feedback loops
Ultimately, it is all about Flow. This needs balancing measures, as anything can be done badly, so that it is not Flow at the expense of quality, happiness, safety or value.
On a regular cadence, a one pager is sent to senior leaders with measures for the above, including vector measures, the rate of improvement. Everyone can see everyone else’s data. In addition, a real time dashboard with drill down is available.
The scope is the whole organisation, to enable organisational agility. It is Incremental and Disruptive, Exploit and Explore. It is equally aiming to delight customers in existing markets and to delight new customers in new markets.
Then, for the reasons above, rather than doing a capital ‘A’, capital ‘T’, Agile Transformation for the sake of agile and framing it as such, and commence the rollout of a set of prescriptive practices or a prescriptive framework, frame the change around the Why and around the improvement in the identified Outcomes.
This appeals to intrinsic motivation, it is asking people to bring their brain to work, to understand and internalise the mission, and in an empowered manner to take personal ownership for working out how to achieve the desired outcomes. Agile principles and practices, Lean, DevOps, Systems Thinking, Design Thinking and so on are tools in the toolbox, and are supported with training, coaching and psychological safety in a context sensitive, not one-size-fits-all, pull-based not push-based manner.
by Jon Smart, 15/09/22