Why do we need permission to be empowered?
As Chris Matts would say, ‘in a risk managed culture’ the organization takes responsibility for learning, experimenting, and adapting for…
As Chris Matts would say, ‘in a risk managed culture’ the organization takes responsibility for learning, experimenting, and adapting for their benefit.
I’ve witnessed some intriguing behaviour in response to an organization moving to a common way of working (for the first time). An artefact gets created (a playbook) to articulate the approach, it is intended as guidelines towards a north star rather than an instruction manual (not an Ikea instruction set).
The playbook is treated as an instruction manual and holy text. People are using what is written to justify their own behaviors. If they identify a gap, they quickly want to get something added to help justify their own issues, rather than figuring out how to solve the issues.
It is healthy to keep changing and updating the playbook, look out for people wanting to print this out and keep it as a once created document that never changes. Look out for people wanting to create new roles, responsibilities, and map all their legacy behaviors rather than solve the issues differently.
The playbook is aimed at articulating organizing structures, roles, interactions, values, and principles and some recommendations for resources that people should explore (books, blogs, videos etc).
The playbook is a way of distributed / asynchronous understanding to help people align on intent. In a weird twist of events, people aren’t allowed to implement the structures in the playbook until they have been pushed through the transformation conveyed belt, with a re-org, setup of roles and some basic education to help them on their ways. Somehow, magically after this multi-month phase the department is then equipped to start on their continuous improvement journey.
This approach to ways of working in an organization is not conducive to learning, experimenting, and collaborating. It’s too fast and too furious and it simply doesn’t give an organization enough time to react and adapt.
There is a very real risk of reverting to the mean whilst having adopted the updated terms and rituals (what some people may call cargo culting, zombie scrum, wagile etc..).
It has been mentally and morally taxing to rationalize the inner conflict of having organizational top brass support such radical changes, whilst simultaneously knowing that force feeding people is not sustainable.
I don’t profess to be an expert on this topic at all but what I have read and observed thus far is consistent with the anti-patterns expressed by Open Space Agility and Better Value Sooner Safer Happier.
Large scale Agile Transformation has reached a fever pitch, it is so over commoditized, it missed the point entirely.
If you are relying on a big consultant to make your company agile, you have much much bigger problems to worry about.
I’ve yet to find a great analogy for this but, it’s a bit like having someone telling you the answers to an exam so you pass but then you are reliant on those answers to help you fly a fighter jet the next day (without the hard-won experience and learning, all you have are the words in your mind).
Does that work or can you think of a more appropriate comparison?
This is agile in a box at scale and pace.
“Buckle up your seatbelt, Dorothy, ’cause Kansas is going bye bye” — Cipher (the Matrix)
This rollout visualized in a series of ‘waves’ which look a lot like a Gantt chart are used to communicate the sequencing of the departments scheduled to be ‘transformed’. Think a modern / new age baptism to bootstrap your agile cultural revolution. You are newly baptised and now ‘so freaking agile!’.
This is akin to putting on your favorite sports team’s jersey and expecting to play as well as they do.
Awarding a badge only ensures gamification of the badge, it doesn’t get the outcome.
“When a measure becomes a target, it ceases to be a good measure.” — Goodhart’s Law
Departments line up to go through the transformational meat grinder, which churns out departments to become ‘so freaking agile!”. Only, things don’t work like that. The transformation office (or any other name for PMO) pulls together so-called experts to help make everyone successful (this is centralized and context free).
This approach creates a weird relationship between experts and the individuals, whilst there’s nothing inherently wrong with experts — the value is in the learning, experimenting, and going on the journey.
A journey which takes far longer than the time allocated for transformation, only without the same focus to change and improve.
Typically, the department will revert to its previous state, as they are unwilling to get worse before they get better (sometimes referred to as unlearning). People cannot consider slowing down to speed up.
Telling people what to do and how to do it isn’t empowering and when they fail (they will fail, that is how people learn) they will blame you, instead of getting back up again and trying it again or experimenting with something else.
This ‘transformation roadmap’ is incomplete, it doesn’t show you who is involved outside of those currently in progress moving through their x-month period with the help of the consultants. Everyone is on-pause waiting until they can be baptised agile as well.
Other than getting an organizational pat on the head from the top brass, very few people want to genuinely adopt these new ways of working.
Departments simply want the social kudos, they don’t want to do the arduous work, the reality is they’ve had 20+ years to be curious.
Their behavior is driven by the top brass wanting the organization to be nimble and now agile is no longer a dirty word at the board of directors.
Departments just want to be seen as doing the thing so they can tick the box, they aren’t expecting or wanting to fundamentally change how they work and think about work, let alone how they manage and trust people. This means no long-lasting outcomes, no change in behavior and going back to old ways during times of stress and pressure.
Worse, now the department is ‘agile’, departments think they can get their technology ‘counterparts’ to deliver faster with better quality, all without having to change their own waterfall steps to planning and breaking word down.
They have fallen victim to the same issue that IT did many years ago, focusing on team level agility without understanding the organizational system.
See customer-vendor anti-pattern.
I’m sure that this ‘approach’ is common in large organizations, who are finally (the agile manifesto itself is now 21 years told) getting around to adopting ‘organizational’, ‘business agility’.
Moving from a grass roots / bottom-up approach, which has yielded inconsistent results, competing terminology, operating models, and interpretations of ‘agility’.
The death of agile
You can find countless examples of this trope through several ‘agile is dead’ videos online to help elaborate that point.
Agile (capital A) has been productized for some time but is now truly commoditized to the point that large consulting firms are offering ‘agile in a box’ solutions — magic pill style transformations anyone pay for (regardless of culture / drivers / dysfunction).
The choices manifest in a cost to the organization that will only surface long after the consultants have left and those with enough foresight have left the organization too.
I suspect this is how organizations become immune to changing operating models and ways of working. Organizations build up cultural scar tissue that makes people justifiably immune to change and resistant to the perceived snake oil ‘Agile’.
The departments have tried it before and it didn’t work, why is it going to be any different this time?
When you are ready to change
Things can only change when the organization wants to change, not just the senior brass or the teams on the ground.
There are informal networks that act as a mycelial network through the company that spread experience, gossip, and share how things are unfolding — even if the leadership is self-congratulatory.
Support from the top helps but unless their management team are truly aware of the material change to behavior and expectations is needed, then things won't change, only names, roles, and meetings.
Anti-pattern: Sheep dipping — the organization celebrates the number of people that have been transformed.
This cost is much more than the price of the expensive consultants. Although working with consultants (rather than against them) is a great way to escalate genuine issues to the top of the company to think about, you do so at your own peril.
The devil you know
Working with consultants, rather than fighting them, is going to give you far more ownership and ability to influence some of the approaches and outcomes, if you deviate too far from their approach you will be too radical for their tastes.
Their playbook / knowledge base is the collective observations from their previous engagements and organizational ‘health’ surveys they conduct, not often hard-won experience gained through doing and learning.
The consultants are used to parade around in front of senior leaders to provide a level of professionalism around the topic of agility, to lull them into a sense of calm and control. The leaders are continually told that this type of agile gives them more control, greater transparency, and improved time to market. (translation — business case, cost savings and efficiency).
This is thinly veiled to the ‘teams’ (or on the ground, as they like to say) as empowerment, autonomy, self-organizing or self-managing (a term that many micro-managers detest).
I hear them cry, ‘we are not a Silicon Valley startup’ or ‘we are not a technology company, we are an “xyz” company (financial services / manufacturing etc.)’ or some other derivative.
Guard rails vs Guide rails
There are many ways to skin the proverbial cat, you can use guard rails (try to stop people from doing dangerous things like driving off a cliff) and guide rails (help people along a path if they choose but without forcing them). I see far more trust and flexibility in guide rails; however, you will need to think about how you support people so that they have help when they need it rather than after they’ve driven off the cliff.
Guard rails — the organization needs to meet specific organizational sizing and reporting layers, free of context for the type of department involved or their proximity to the actual customer. SAFe uses this approach with its teams, products, solutions, large solutions, and portfolios. Everyone is treated the same from customer facing products (differentiating and revenue generating) to internal platforms (an ERP, CRM solution from a company like SAP, Oracle, Salesforce).
Guide rails — provide the organization with options, practices, and patterns to experiment with. This guidance aligns with your values and principles. (Take inspiration from the agile manifesto but consider making them your own if you are looking broader than software delivery). Use community and experience reports to build up social proof and learning. This is a wonderful way to scale safe to fail experimentation.
Josh Kerievsky has recently posted some other suggestions on on LinkedIn
Josh has graciously allowed me to refer to these items:
1. Assess them where they are (challenges, obstacles, what’s working well, what needs improvement)
2. Inspire them with what could be. I describe and show (via video) practices of high-performance teams.
3. Learn if they want to improve. (Ask them to anonymously score their interest in improvement)
4. If the majority want to improve, figure out what’s possible and help them achieve it efficiently and effectively.
I don’t call the above “meet them where they are.” My goal is to help people go far beyond the status quo as quickly and gracefully as possible.
Warning: agile zealots will scoff (agile heresy) at this, so be prepared to justify. This isn’t about writing a better agile manifesto; it is about embracing your organizations values and principles.
I love Josh Kerievsky’s Modern Agile approach (Josh is also going to publish a new book later this year called ‘the joy of agile’ so keep an eye out for that):
Modern agile methods are defined by four guiding principles:
Make People Awesome
Make Safety a Prerequisite
Experiment & Learn Rapidly
Deliver Value Continuously
Source: Modern Agile https://modernagile.org/
The amazing book Better Value Sooner, Safer, Happier by Jonathan Smart with Zsolt Berend, Myles Ogilvie and Simon Rohrer supports a similar ethos too! An all-round amazing group of people that continually inspire my thinking and learning journey!
Iterate and tweak, rather than force
Rather than squeezing every detail in your agile bible / playbook, challenge the readers and practitioners to think for themselves, experiment in a safe to fail way and share their learning within your organization.
Offer guides, experience reports (social proof) and help them (with empathy) when they want help. Don’t give up on the sceptics, they are your best chance of embedding long lasting practices. If you can convince them, then everyone else is already won over.
Evolve the content over time, publish release notes to let people know when things have changed (what has changed and why).
Any SMEs who see changes to the content that they weren’t involved in will quickly panic and want to know why they weren’t consulted and who made the decision to change the content without their engagement.
The agile mindset trap
Rather than focus on ‘the mindset’ which tends to send sceptics into anaphylactic shock, provide concrete practices that they can learn and experiment with.
Spend some time with them but equally put them in front of others who are successfully learning themselves. Have them share their war stories and journey of experimentation.
Consider using metrics that help rather than hinder driving positive behavior e.g. do not use velocity, test coverage or lines of code for such things, these will be gamed quite effectively (people are not stupid).
Focus on things like DORA metrics, alignment of work to meaningfully linked OKRs, captured feedback from users / customers and continue to iterate.
Organizational learning
In organizational learning, experimenting, stumbling, sharing, adapting are all key qualities of creating muscle memory and creating social proof for the broader organization.
This is in stark contrast to a production line, mass transformation model that pushes departments in a compressed timeline (often due to resource constrains of central functions and expensive consultants rather than each department needing to take the time it needs to change).
The steering committees, becoming management forums or quarterly planning (big-room planning, PI planning etc…). Then who is allowed to join the meetings, if we invite the stakeholders (all of them) it will be chaos, but if we don’t invite them, they won’t feel aligned with the roadmap being set out.
Riding off into the sunset
The people who make the most noise get the highest priority, the more senior the stakeholder or sponsor the higher priority the work. All without a clear validation of value and all with multi-year long efforts.
Moving to quarterly planning and prioritization is terrifying if you are a senior executive and you want something done that will take years. How is your multi-year thing going to be continuously prioritized and delivered? You must constantly battle it out against other stakeholders and now ‘product people’ who are allowed to say No! (If they are brave enough or recently joined the organization). These product people are prioritizing work that can be validated and broken into small increments, what madness is this?
Why do they keep talking about business value and minimum viable products, the products are only viable once they have all features the executive has made determined?
This so-called agile thing can quickly become disorganized chaos that no longer respects authority or funding to prioritize the work.
Moving to capacity / product-based funding is a key nail in the coffin to the old way of getting stuff done. Instead, people need to articulate outcomes and goals without solutions, and they may not even deliver everything, they may only partially deliver as these goals are now aspirational rather than committed deliverables.
The organization uses words like a tech company, but s perceived to be running like a set of lunatics at the asylum (the lunatics are now running the asylum). Executives used to be able to be able to tell teams what to do and by when, the teams used cost and timing to negotiate.
The executives / stakeholders don’t know the user / customer needs, they only know what they (themselves) want. They used to do the job of the users 15 years ago, so they think they know what is needed but never actually speak to the users. They cannot justify how what they are asking for is going to yield any value and it surely cannot be broken down into smaller pieces.
How else will the executives wish list be fully delivered? No longer can executives dictate outputs, only outcomes (tip: look out for OKR manipulation describing tasks rather than outcomes and results).
Feedback
I’m interested to see if other people have experienced similar patterns as well, I’d love to know your experiences and approach. Reach out in the comments!