Mapping Maturity: create context specific maturity models with Wardley Maps informed by Cynefin

When organisations and teams are looking to understand how good they are and where they should look to improve they often reach for the latest maturity model. The use of maturity models to perform assessments is also an approach adopted by consultants. Whether that’s a health check or a 4 stage stepped model there are a few problems to be aware of.

• Most, if not all, maturity models are context free. They presume to know what is universally good in order to give you a clear way of assessing your current capability and then plotting a path to perfection. But as software development is a complex (as in Complex Adaptive System) problem there is no universal perfection let alone a path to it. For example, Adrian Howard points out that maturity for a 30 person company is entirely different to that of a multinational.
• As Marc Burgauer highlights “they also bias thinking towards the model, i.e. blindfold for context”. That is most maturity models encourage “gap thinking” which involves envisioning their view of an idealised future state and closing the gap. This, in turn, discourages options that might otherwise present themselves.
• Jason Yip points out “they’re suggesting a poor learning order, usually reflecting what’s easier to what’s harder rather than you should typically learn following this path, which may start with some difficult things. In other words, the maturity model conflates level of effectiveness with learning path”.
• In some context being categorised as immature could also been seen as shaming. This then creates an extrinsic motivator for improvement but for that we want teams to be intrinsically motivated.

Trent Hone likens them to a treasure map where X marks the spot. The problem being the terrain you see around you isn’t reflected anywhere on the map. You know something great is out there, you just have no way of navigating your way towards it.

To improve what really matters is that we understand our own context, the challenges we face and our ability to adapt and learn to meet these challenges. That is, we need to focus on “present thinking”. I’d suggest that for a maturity model to provide utility it must reflect the context, and provide some guidance for improvement that can be selected dependent on that context.

When exploring this challenge it struck me that we have a way of understanding our current landscape, the climate, doctrine and context specific approaches to apply to make movement within the environment towards a desired state. Simon Wardley’s mapping gives us all of these things but in the context of strategy. What would happen if we turned it towards team or organisational maturity, what would that look like?

Note: If you’re not familiar with Wardley Maps please watch this before reading on as the rest of this posts assumes a familiarity with Wardley Mapping.

When describing Wardley Maps Simon uses Sun Tzu’s five factors. These are purpose, landscape, climate, doctrine and leadership. Let’s exam these in the context of a development team.

Purpose

This is the moral imperative, what we are doing and why we are doing it. For a software development team this could be the product they are building, the project, the user need, their mission etc. This is the first point that we realise our maturity map is set in the context of the problem we are trying to solve.

Landscape

This is the map that shows the value chain that represents how we act towards our purpose. What is the value chain of practices that we use to satisfy our customer need and the maturity, in our context, of each of these practices.

Climate

These are the forces that act on our environment. In the context of our software development team we could consider WIP, deadlines, quality, dependencies, team dynamics, work environment (co-location, wall space) etc.

Doctrine

Simon describes these as standard ways of operating, Trent refines this to be a “set of heuristics that inform decision-making”. This could be things like… focus on flow, develop feedback loops, visualise, inspect and adapt etc.

Leadership

This is about the choices you make, about how you act to improve your situation considering your purpose, the landscape and the climate you operate in.

An example would be good around now

Let me set the scene, to keep it simple we’ll focus on a one team one product example. The Big House company run a popular website for the housing market. One of their teams has the responsibility for the search function and their mission is to ensure home buyers “find the right home”. The team comprises of a Product Owner, 3 back end developers, a dedicated front end developer, a user experience designer and a tester. The team also work with a separate team of DBAs and have an Agile Coach supporting them.

Building the Map

To create a context specific Maturity Map we’ll first need an anchor. Given our example this seems straightforward, our anchor is our mission “find the right home”.

Value Chain

From this anchor we can then create a value chain that reflects how we as a team go about satisfying that customer need. To help guide this I start by considering 3 paths:

• Building the right thing
• Building the thing right
• Building it fast enough

If we follow one of these paths this could lead us to a value chain that looks like:

Evolution

Most Wardley Maps you’ll see describe the evolutionary axis as genesis to commodity but we need to use language that more accurately reflects what we’ll map or we’ll find ourselves continuously performing a mental juggling act. What we are mapping is practice. For evolution of practice Simon uses Novel, Emergent, Good and Best. To now map our practice we could ask ourselves to categorise each practice along the evolutionary axis using these guidelines:

• Novel — this is new to us, it’s not well understood by anyone in the team.
• Emerging — we are trying this out, it’s something we can begin to explain to each other
• Good — we are getting to grips with this, we know there is room for improvement and can improve it in our context
• Best — we’ve nailed it. It’s a practice we’ve established in the team and might not even mention it in a retrospective

I’d suggest this is a team exercise and practices aren’t mapped without first discussing the reasoning within the team. Our map might then look like this:

If we follow their other two paths we could find ourselves with a landscape that looks like this.

Movement

We’ve now got a landscape so our discussion can move to “what would be the most effective movement we could make here to ensure we have the best outcome”. For this we exam the landscape identify the moves we think would benefit the team the most. Looking at the map we see that client side testing is something that we might want to improve along with our ability to understand user need.

At this point we and then consider the climate, what environmental factors influence our ability to improve our situation, and what doctrine exists to help inform our actions. To do this we could ask the team, “how could we make this better?”, the team can then brainstorm ideas for improvement and call out impediments. Once we have all these ideas on stickies we can then group them using the following criteria:

• Any of us could do that: improvements that anyone on the team could action/impediments anyone on the team could remove.
• We know someone who knows how to do this: we know an expert that could make the improvement for us/remove the impediment or could teach us how to do it.
• We’d need to try a few things: We’re not sure how to act on this and we don’t know anyone who could so we’ll have to experiment.

What we’ve now done is introduce the Cynefin framework which gives us advice how to act with the various kinds of problems we’ve identified. This approach is very much informed by Liz Keogh’s and Kim Ballestrin’s approach to using Cynefin for estimation.

With this insight we can now add to the map the possibilities for improvement.

We can see that improving our ability to understand user need is something that we can act on but there is an impediment to improving our client side testing. The fifth of Sun Tzu’s factors now comes to play with the leadership decisions we make to improve the situation. Do we choose improving our understanding of user need over building another feature… I’ll leave that for you to decide.

Summary

As with most improvement techniques the value exists in the conversation. Building a Wardley Map for something like team maturity, informed by Cynefin, can act as enabling constraint helping us develop a shared understanding of our situation and where we can best focus our improvement efforts.

Through conversations with Marc, Karl, Chris and others we can begin to see application of these ideas at an organisational level, evaluating transformations, as part of a multi team workshop and in other areas. We’re just beginning to scratch surface I feel!

If you decide to try this out I’d love to hear how you get on. Either comment below or message me on Twitter.

Many thanks to Marc, Trent, Markus, Adrian, Jabe, Sal and Simon for their thoughts and advice on this post and the wider idea.