Transitioning scaled agile systems of delivery
Nice Agile at Scale Target State Pictures Can Mislead
There are a lot of scaled agile frameworks showing idealistic ‘target’ states that look great in infographics. We all know though that getting a large delivery system to adopt these frameworks is a lot harder than it first appears.
Lately, I’ve been talking with clients who are keen to realise the vision of what agile at scale promises are the benefits.
The challenge of ambiguity in a transformation
I wanted to write this article to call out one of the biggest challenges consultants and agile coaches face when helping their clients adopt better ways to work at scale; the dreaded “interim state”. Between the target state and the current state, there is an interim state which is messy, confusing, scary, a little chaotic and necessarily ambiguous for those in the system of delivery.
Most people want to feel safe, have certainty and stability in their work environment but during a transformation those things are usually not there; it is a difficult time.
In facilitation workshops, there is a common term used to describe the middle of the workshop where participants are in an uncertain period, where they have to co-create the outcome and navigate through uncertainty. We call this the “groan zone”.
See the illustration below to visualise what I’m saying.
Life in the groan zone is uncomfortable for people and the same is true for employees transitioning to a new scaled agile delivery system with new ways to work and behave.
Sometimes the target start is not clear, it might be emerging and being worked on and people want to know the “answer” of where they are heading when the answer is not available.
So what’s the solution to this groan zone problem?
Good coaches together with their sponsor agree on when and how to communicate an interim state. This allows everyone to ‘anchor’ on the next version of the way to work whilst understanding it will iterate.
Even a sketched out rough interim state picture with associated roles, responsibilities and practices greatly helps everyone to calm down and relax a little.
Even better is if the coach/consultant can publish when and how they will communicate what the next iteration of the interim state to everyone.
What this approach solves for is people making up their own stories when they have no information on where the organisation is heading. In the absence of a published interim state people will make one up (or multiple versions); then you have a change management and communications problem on your hands.
Having a roadmap of states as the organisation moves towards its target state is one way to avoid having to do a ‘Big Bang’ approach to change. It allows for inspect and adapt cycles and learning to be fed into each iteration of the way of working. This approach always avoids doing the change to everyone in one big push ensuring change resistance is minimised.
Interim states carry risk too
Using interim state introduces the risk of not facing into the big things that have to shift to unlock agility; common examples include leaving organisational redesign to the end, not changing the funding model, not organising around value, not addressing behaviour/mindset, not coaching leaders, only changing technology teams, not managing impediments, overuse of consultants/contractor instead of building capability etc. etc. there are many more.
How to create an interim state model
Here are some tips and advice on the steps you would follow to prepare and iterate an interim state way of work for an agile at scale delivery system:
- Run some future foresight workshops to help imagine what your future could look like. What would your organisation look like, how would people behave, what would be the type of conversations you’d be having 3 years from now. Why is this critical (meaning you must do it); well this is what will provide the energy and drive to pull everyone towards a new better way to work. Done well it is energising, exciting and motivating; done poorly and it is fake and everyone knows that what happens on the ground does not match the well-crafted communications messages. I’ve seen both and prefer the former.
- Seek strategic advice from someone who has been down the road before, learned (the hard way) what to be careful of and what might be for your organisation. This may be just one person acting as an advisor or a team of coaches/consultants. I’ve seen organisations try to go it alone by asking, talking and reading but nothing replaces what I call ‘learned experience’. This is what real ‘knowing’ means. Literally having ‘been there, done that’”. I’m not just saying this because I provide such services. I’m truly saddened when transformations fail because people do not get the right help they need when they need it.
- Do not, I repeat (please), do not implement an agile transformation waterfall style and I don’t just mean running a pilot then going Big Bang. I mean genuinely learning how to do your transformation as you roll out successive waves of change into the organisation; then stopping and re-assessing your whole approach to check it is still working and a fit for your desired outcomes. See leanchange.org for more on this.
- When the ‘wind’ starts to change and everyone is all of a sudden realising that the tipping point has been reached (“this agile thing is not going to go away”) you need to resist the pressure to release more change into the organisation. Scaling up and starting to mobilise more areas of the organisation concurrently introduces exponential risk into your transformation; here’s why:
- Only a relatively small number of people know what to do. When you start off a transformation there is a small expert group of people in the know who get what needs to be done. If you mobilise more transformation activity it is extremely difficult to ramp up the people ‘in the know’ about the way change is to be managed.
- Also, support from roles such as coaches and other cultural enablers is going to be limited and in short supply or too expensive to hire on mass.
- Money and resources are spread thin leading to what is known as “lipstick” agile transformation. It looks nice but doesn’t last. Thin and pretty but represents cosmetic change, not deep acceptance of a new/better way to work
Final thoughts and a challenge
By now you have probably figured out that I have learned experience of a transformation (or two). I’m talking about the end-to-end experience over a multi-year period. Agile transformation is a long game and at least 3 years for an organisation with 1000s of employees and contractors.
Even a small 300 person system of work I was coaching took three years to have end-to-end agility from customer to operations/idea/value realisation. It takes time, is complex and requires that you learn as you go through the groan zone interim states that are a necessary part of transforming to the future organisation you want to become.
My challenge for you is to build out your next interim state and start to communicate and collaborate around it with the people in the system of work undergoing the transformation. Run this as an experiment; get feedback as you share it, ask if it is welcome and useful as a means to provide (some) certainty as the system of delivery moves towards the target state. My hypothesis is that if you do this well you will be thanked and appreciated for your effort. Why? Employees in the transitioning system will be very appreciative of having something to aim for in the short-medium term. Try this out, test it and let us know how you go.