Transforming our organisations will require huge shifts in basic digital literacy and ways of working for almost every employee outside of technology & development teams. New digital hotspots are starting to emerge, but scaling and replicating these emerging areas of novel practice is more complex than just deriving new rules and asking people to follow them.
When we coach agile teams, especially those from “the business” rather than IT, we are often faced with a broken work system that is trying to knit together fundamentally incompatible paradigms, for example:
- work approaches that focus on single, unifying goals AND also coping with broad business-as-usual work packages
- senior leadership pushing for speed and to be ‘done’ transforming into an agile company already AND also handing down KPIs that reflect the current (or worse, old) product and service delivery approaches
Unless we help these teams change these contextual conditions, we are growing agile teams who can only follow the rules, and the moment something isn’t ideal they don’t know how to adapt.
“Almost any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.”
— Robert Heinlein
With organisations instantiating agile methods with little leadership understanding, but lots of political power, we are seeing a cult-like approach to agile, with:
- a language that creates “us and them”;
- a lack of real, deep blueprints for those who are slightly out of the normal tech/delivery mould;
- a focus on certifications rather than empowering training; and,
- placing emphasis on what to do, not how to do.
So how can we help teams turn away from this compelling, but limited view of how to create agility?
Writing A New Recipe
The truth is, non-technical teams need a lot more than just a new way of describing their value, a new working rhythm and better stakeholder engagement. But where to start? In the world of design, we use Principles & Patterns to share proven, transferable but complex approaches. Maybe it is time to apply this thinking to all types of team transformation?
Understand the Principles
The last time I facilitated a coaching session with a team who had hit a plateau, we chose some of the principles to explore together as our starting point. Here is an example of how the conversation progressed:
Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
A discussion followed, around:
- what it means to ‘welcome’ change, whether that implies always accepting it or whether saying no can be as powerful as accepting in showing clear, healthy behaviour?
- the importance of having a clear MVP definition along side a clear vision for the product or service being worked on.
- the power of saying no, and explaining clearly, based on customer feedback and stakeholder interaction why the answer is no.
- the need to discuss openly when the team has changed track from shipping early and gathering feedback to making assumptions and pursuing perfection.
- the need to educate leaders on the agile mindset and why it would be an unhealthy team rhythm to drop everything and address less strategic interrupts.
Focusing on principles can help us zoom out from the minutiae of the rituals to focus on why we are working this way. Just because something is written down in the Scrum Guide doesn’t make it right for you and your team, especially if you are a business-focused team. Having the confidence and the courage to change an element of the framework requires us to use the principles and patterns of agile as our backstop. If we are not breaking one of the 12 principles, it is probably OK to experiment with something!
Focus on Patterns
Instead of focusing all of a squad’s energy on whether or not they are getting roles 100% correct, or following what a sprint review, planning or backlog refinement should cover, it can be more advantageous over the long term to help them identify good patterns of behaviour. And, like habit stacking, you can link behaviours together to create more value with less resistance.
A good pattern to start working on, which offers clarity and simplicity is that of organising around the customer. How can we best serve the customer? What techniques are we going to use? What are the individual techniques you can leverage to build that pattern?
For example:
- how can you describe the service you provide to your customers (internal or external) so that they can easily find it, understand it and engage with it?
- how will you capture and resolve customer feedback?
- How will you check-in with you customers and ensure that the service you have designed fits with their needs?
- how will you identify parts of the service that can be self-service or automated?
The way organisations teach “agile” to business teams rarely pushes them to identify a single, most important customer, let alone link agile ways of working to frameworks that can help, such as service design or design thinking. By focusing on a customer-centric pattern, we are creating flow and broadening the knowledge of the team into what is required to build better digital products and services, rather than what is needed to run a good Scrum team.
Other common digital transformation capabilities also have principles and patterns – DevOps, Design Thinking, Digital Adoption – we need to be teaching teams to think for themselves and claim their autonomy, rather than follow the rules. Organisations will end up with a far more digitally savvy workforce as a consequence.
What principles and patterns would you focus on to help a non-tech agile team improve their game?