Frameworks are often the first topic of conversation when teams and organisations start to think about agile. They can enable agility, but in the wrong context they create disengagement and become a disabler.
Choosing a Framework
A good place to start is agreeing, what do we need a framework for?
Have just enough conversations to agree a hypothesis together about which one is best suited, and align around giving it a go.
Discuss what would be needed for success, the pitfalls to avoid, and what support or resources might be needed, but in the context of the experiment, in order to iterate and improve overtime.
I’ve worked with teams that started without a framework, selecting a few key practices to get going. Others used one framework for a period, and then switched to another for the same length of time to evaluate the differences. I’ve also offered teams the suggestion of a little structure when they have been struggling. These scenarios were real decisions made together, not a fait accompli.
When I see frameworks used effectively, it’s because people are engaged, enabled to learn, and ultimately grow beyond the framework.
That’s the purpose of a framework: to enable teams and organisations to discover more effective ways of working. That would be my biased answer to my starting question, but others will disagree.
I don’t believe it matters if you are following a framework. It matters if you are learning. A key indicator is if you are discovering where a framework is incomplete or has elements that don’t work in your context, and making adaptations. What didn’t work and why? How could you get the same intended benefit, but in a different way?
Scaling
The size, format and investment needed in choosing a framework will vary depending on scale, but fundamentally it needs to be a participatory decision that engages people, gives them a say, and enables an experiment.
That becomes more difficult with scale, so avoid scaling as much as possible. It’s much easier to find ways to descale, than to scale. Consider the size of the experiment. It’s much safer if your experiment is small. Try deep and narrow, not wide and thin, where there is a willingness to give it a shot and learn.
Getting Stuck
Organisations that have difficulties with frameworks make a choice centrally and impose it, considering it ‘best practice’. They go for a big roll out and devise a step by step implementation plan. That sets in stone one fixed approach which cannot be adapted or improved.
In such organisations the framework debate rumbles on for years. People become stuck with the starter for 10 conversation. The discovery of what’s truly needed for that specific organisation to become more effective lies out of reach, implementing the framework was enough, because that was the goal.
Where this is the case, if you go and see what teams are doing, you often find that while they appear to be complying, they have found ways around the constraints, and for good reasons.
Training Wheels
When I have heard the training wheels metaphor used to describe a framework, I infer its part of a narrative forming justification for control by someone who ‘knows best’.
Sometimes this arises from fear and lack of understanding of mechanisms by which self organising teams can be supported without being told what to do or how to work.
I think there could be better metaphors that don’t imply a parent / child relationship, and even if the chosen framework is the best, imposing it will prevent you from getting the benefits you perceive, and teams are likely to work around it anyway.
As such, the control sought by imposing a framework is an illusion.
The standardisation myth
Framework imposition is often disguised as a need for standardisation. There are lots of reasons people feel the need to standardise on a framework, but I’m yet to find one that feels rational to me.
Here are some things often expressed, and my thoughts when I hear them.
We need to standardise on a framework so that......
We can easily move people between teams
Moving people between teams is never easy, but frameworks are only a small part of it. Moving through stages of development, building trust and sharing a sense of purpose? That takes months or years regardless of the framework.
Consider whether you should be frequently moving people between teams. Teams benefit from stability, and this seems to be an attempt to optimise for the opposite.
We can ensure quality of practice / we have a repeatable path to ‘maturity’
What works well in one context may work really badly in another. The nature of the work may be different, or it might simply be that group of people work better in a different way.
That’s why it’s so important teams can experiment and find what works for them. Imposing a standard will stop you from getting the benefits you want.
Teams can co-ordinate / we can consolidate reporting / we can operate at scale
With all of these needs, what we’re typically talking about is cadence. If you agree some wider cadences in the organisation, teams are typically able to organize their local ways of working to accommodate them. Those cadences can usually be agreed together without imposition.
If you really do need to operate at scale, then you need to look at ways to gradually de-couple teams, not coupling them with a fixed standard that can’t change.
Try to reduce the conversation down to meeting needs, and find the simplest way of doing that. More often than not, solving a delivery challenge is just about that very conversation, as opposed to which scaling framework we need.
We have clear roles and responsibilities
I think looking to frameworks to define roles and responsibilities is back to front. Often what’s expressed in a framework is actually a sub set of responsibilities needed to help that framework function. We need people to think and go beyond this.
I recently heard someone from HR describe roles and responsibilities as a box that you stand on, not one that you are put in. When you make someone’s job the role from the framework, I fear that is a form of putting them into a box.
If you define a role that delivers the value the organisation needs, ‘wearing the hat’ described by the framework is either an obvious subset of the role already undertaken, or a way for that person to grow within the role they were doing. That can become a great way for communities of practice to share experiences and learning, and help your orgnisation become more adaptable.
Our people only know framework [x]
Now we’re into the age old ‘if all you have is a hammer, everything looks like a nail’ problem. In addition to this, I think this is often about confidence. It’s ok for leaders not to be experts in the framework the team(s) are using. Go on the journey together.
As a leader, you can use your expertise to ask questions and play coach for a while, and watch as your team(s) grow their understanding of what great delivery requires! Teams will also respond to your vulnerability, and understand that you are trusting them to choose the best way to work. There are still plenty of ways to serve them that don’t look like teaching them to use a framework.
Have a tool box
As my knowledge of frameworks has grown, so has my ability to offer teams options. If they have a specific problem that’s solved by one particular mechanism in a framework, then it’s possible to take just that one element of the framework and use it to solve just that problem.
I find the scaling frameworks are particularly good for this. I’ve yet to see a scenario where I thought it was sensible to have a big scaling framework, but I have found definite uses for specific parts of them where they solve a clear problem.
In conclusion
The theme throughout these thoughts is ‘context is king’. Unless you have the exact same context as the one a framework was designed for, you will never find the perfect framework.
The people who understand best what will fit are the people doing the work. They are clever and smart people and if you engage them properly with the support and resources they need, they will eventually find what works.
Comentários