Why Mapping Maturity?

Jabe's three stickies.png

During a discussion of an early incarnation of Maturity Mapping in 2018, Jabe Bloom put these three stickies on a wall. They symbolise in a nutshell why we’re pursuing a better understanding of practice theory by exploring how to map (social) practices. 

Jabe introduced Chris McDermott and me to Social Practice Theory (SPT) a little earlier, but we needed that little nudge of motivation. Practice theory is exploring culture through investigation of its practices. SPT is a specific model of practice theory created by Elizabeth Shove that postulates that a practice is socially shared and integrates elements that can be grouped into three categories: meaning, material and competence (or skill). The repeatability of such integrations and sharing them is what makes a social practice. (We started learning about SPT here.)

Jabe explained that while common Wardley maps have a bias towards material, Maturity Maps have a bias towards skill (competences) – they are complementary and can be aligned by sharing meaning. Jabe emphasised in those stickies that the evolution of material is of particular importance, because it can accelerate the evolution of a practice, but that also implies it can wreck it. 

A little story ~~

The Chief Operating Officer (COO) comes back from the Galatic Transfabulation Leadership Summit and announces to his staff that we’re going full throttle with The-Greek-Company’s Soothsayer Cloud-DB service and abandon that pesky FrontFrame Enterprise-DB systems, because all the unicorns are using Soothsayer now. He is about to sign an Enterprise License agreement for the next 3 years. His architect produced a Wardley Map that shows how we have to transition all the necessary components. “Easy peasy, all established technologies.” 

Meaning maps COO.png

After about two months of exploration, his managers report.

“We’re way behind the roadmap. We have not enough people who understand mesh services. We discovered that we need to massively advance our resilience engineering and we need to rewrite our data dictionaries to get the benefits from having a mesh. Additionally, our salary bands don’t match the market rate for people with those skills, so we need to train up our existing staff, which takes more time. “ 

COO: “But, when I asked you 6 weeks ago, before signing the agreement, you were all excited?” 

Manager: “We still are. It is the right technology for the future. We just will need considerably more time to get there.” 

COO: “How much time?” 

Manager:  “We don’t know really. We decided that, rather than attacking it at all levels, we would start with one data service, but quickly discovered this has impacts in the entire value chain that service is used in and, with all the waivers we’ve handed out, all of the high utilisation applications need updated. So now we’re focusing on a couple of value chains where we’re more likely to see quick wins. We’ll gain the experience we need to then attack the rest efficiently.” 

COO: “And how long will that take?” 

Manager: “We hope to have the first product using Soothsayer up in another 3 months and a second a month or so later. We’ll have a better idea of the further roll out then. Some of the analysis for the other data services is underway, so hopefully we can then move quickly.” 

COO: “OK. I can still claim we did get it going in the new Financial Year. Not quite what I promised, but it’ll do. Keep going.” 

Two years later, we migrated about two thirds of services to Soothsayer, when Palmist disrupted the market and six months on from that, we’re now operating three database regimes and the COO is under pressure, because of the associated growing costs. 

~~ End of story

I changed the labels, but I have experienced this scenario of technology adoption too many times, as, I’m sure, have you. I absolutely concede that in the example, they obviously apply Simon Wardley’s advice only superficially. Simon is very clear about having to pay attention to culture and capabilities, but we (whose thinking is shaped by Western philosophy especially) have a desire for the material – the promise of the tool to make things easier – and an equal propensity to overlook the significance of competence. Even more so, if we think about competences of others, of competences we (who make the roadmaps) lack. 

Now, imagine an organisation that approaches “satisfying a need” based on applying its existing competences to leverage its strengths. It is less likely that they will choose a material (e.g. a database system) that doesn’t fit into its existing practices. 

Meaning maps SPT.png

Maturity Mapping is not an alternative (not a competing model) of Wardley Mapping. It is an application of the principles of mapping underlying Wardley maps (e.g. anchor, position, movement). In that sense, every Maturity Map should aspire to be a Wardley map. However, commonly, Wardley maps focus on strategy and components. Simon has already pointed out that his maps can be used for practices and how practices can be integrated in his maps. Maturity Mapping is a practice that focuses on learning how we can improve social practices (e.g. ways of working). 

Take the above described ambition of adopting a new technology. If Soothsayer could have shared their maturity maps from their experiences with the unicorns and the COO had been able to compare them with his own, he would have seen how much inertia he would inject into the system by forcing in Soothsayer. Maybe he could have discovered the lacking competences, if he’d explored this with his staff? 

If we accept the value in mapping practices as explicitly as mapping technology, it provokes the question: how is evolution articulated for practices? As far as Chris and I are concerned, this (and, hence, all the following) is WIP. Maturity Mapping is an emerging practice. 

SPT suggests that practices evolve in a dance of the three elements. Each leads or pulls the practice forward at a different time – but each also influences (constrains) the evolution of the others. Then, dancing becomes the art of the integration of meaning, material and competence and the evolution of the art is an increasing sophistication in integrating. However, this only shifts the problem of evolution into a different frame: how do we qualify that we have become more sophisticated? 

In a Wardley map, we improve our ability to create value as things evolve. I believe the same must be true for practices: evolution of a practice can be qualified as a system’s ability to create more value from the practice. Consequently, optimising just the material (parachuting in a new technology for a core capability) becomes an obvious fallacy: an organisation can only gain value from a technology (a material in SPT) if the necessary competences and meaning (purpose and needs, why are we doing this) are, in terms of their evolution, in sufficient proximity of the material. If you don’t have the right competences and/or only few people in the organisation share the value in the meaning of the practice, adopting the practice will result in a lot of friction. 

Markus Andrezak suspects that we might discover patterns in the configuration of connected practices (complexes, in SPT language) on a map that could be discernible, for example as healthy or unhealthy, without needing to understand what practices are shown on the map. 

That still leaves us with the problem of how to position the elements of a practice – meaning, competence and material – independently on a map. For material, we can happily refer to Simon’s work and his suggestions for practices make a good starting point for what STP calls competences. (BTW. If you think about applying the four competences model as axis for evolution of competences, I suggest you only put the last three onto a map. In Unconscious Incompetence, you don’t see the value of the thing, which means that stage is just the space under the visibility-axis line.) 

Chris pointed out before how, once you adopt the Social Practice Theory lens, you immediately start to see the value of mapping Meaning. An obvious application is to map Meaning across multi-silo value networks in the organisation that require alignment. It can facilitate peer level (horizontal) communication where this commonly only happens in close proximity (e.g. within the silo) and where, because of that limited view, we misunderstand what others do. We lack understanding of the meaning of their practices and we usually only discover this when our mutual misunderstanding (as a consequence of missing information) creates a problem for the organisation and somebody further up the hierarchy calls it out and forces us to talk directly to resolve the problem. But by that time, we have – lacking connection – invested into local optimas that cannot be easily made coherent again and in that conversation, we will be biased to protect the investment and promises we already made.  If we can map meaning together, ideally from the outset, we no longer have to depend on empathy to have authentic conversations. The map allows us to have rational compassion for each other and we can start to apply what Kahane says about conflict resolution for complex problems: progress is only made when we stop thinking about what others need to do to make things better for ourselves and start to think about what we can do to make things better for all. 

Chris Matts suggests that the maturity of Meaning can be assessed by looking at who (or how many) is (are) getting value from having the practice in the organisation. 

At first, a practice starts maybe in a single team as a coping tactic to deal with a problem and the practice has only value to a few people. Over time, they get better at the practice and find it also helps with other problems, at which stage other teams are getting interested. As the practice spreads, the organisation increasingly gets value from the practice and will start to ensure the spread of the practice, at which point it becomes “how we do things around here”: part of the organisation’s culture. In order for this to happen, the meaning has to change and its focus moves away from the needs of those early individuals to the organisation’s needs. You could map that too to show friction and conflict of interests. 

Another dimension to apply for Meaning is risk behaviour. When we talk about the practice, are we risk averse or do we manage the risk and, if we manage it, do we have appetite to take some risks? Risk averse means we don’t want to deal with it and we will give it to someone else to deal with. That would indicate a low visibility. Managing it well would mean it has high visibility. How much effort we spend on managing the risk (or on making it someone else’s problem) is an indicator for how much value we attach (evolution). Another possibility is to reflect risk taking against requisite variety as visibility. You probably can have bigger risk appetite with an emerging practice than with one your core business depends on. Risk, as Matts has taught us, is also a good proxy to uncertainty reduction. 

As I said, this is work in progress and I didn’t even touch on the whys for things like team retrospectives or mentor-mentee explorations or how you could use Hofstede’s power index. There is also more to say about mapping competences… some other time. 

As a final thought, again something Jabe pointed out: if you look at the SAFe big picture, what you see are all the practices that remotely can be associated to Agile and that have had some value for some organisations, but the SAFe picture is not a map. It does not inform you, which practices are suitable for you in your context (never mind that it inherently misconstrues the problem of scaling – although I think that’s intentional). It also suggests having the competence is a binary thing: just attend their course programmes, all of them, of course. The big picture is not a map. Though even if they map it (and I expect they will), what they show is some idealised state of an organisation and wasn’t that the problem we started to dig into with Agile in the first place? 

Wardley on Attribution


Simon Wardley  @swardley

From Twitter 7th December 2018

X : How do we attribute you?

Me : I’m not fussed. I don’t care about attribution. It’s nice if people occasionally mention it.

… I’m only fussed about keeping mapping open for everyone, to include as many people as possible. Think of it like “pay it forward” … I gave this gift freely so others can benefit, if you build upon it then do the same.

X : But what if we call it “Smith Mapping”?
Me : Will it be creative commons, share alike?
X : Yes
Me : Then fine by me. I have no expectation other than to be a footnote somewhere. That’s enough for me. I’m more interested in progressing the community and the conversation.

X : Aren’t you claiming copyright on mapping?
Me : I’m claiming that the use of mapping, derived from my form of maps that are based upon use of evolution as an axis should be free to all. If you derived from my work, then share. Claim your own attribution but make it open.

X : But what about other forms of maps.
Me : There are none that I’m aware of in business. The first maps I know of business that use anchor, position and movement are my own. The first using evolution are my own. It’s why I made it free to everyone all those years ago.

X : So, I have to share my maps?
Me : No, the maps you create, are yours. But if through using my method then you find a better method then share that method of mapping. My gift was the way, the method of mapping and so by all means build upon it, keep it open, share with others.

X : But what if our method of mapping is much better than yours?
Me : Was it based upon my work, did my work influence you, are you simply refining the axis, the layout and improving on what you’ve learned? If so, share …

… I made mapping creative commons over a decade ago not to foster some consultancy peddling a copyrighted form of mapping based upon it but to free us all, by that I mean everyone, to explore context and to learn. Give more than you take, you’ll sleep more soundly if you do.

X : But, if you had licensed mapping wouldn’t you make more money?
Me : I did license mapping a decade ago. I made it CC by SA. I find great joy in three things – contentment, my family and watching others grow. Not in little bits of green paper.

… if I have used some proprietary license then the only person mapping today would probably be me. Yes, I could have used that to make vastly more money as a “voodoo” strategy consultant, a guru of gurus. But life isn’t about making money. You can’t take it with you. Do better.

… I have many friends who make huge piles of money, own several houses and drive flash cars by selling other people crap they don’t need. They don’t help others, they impoverish them and their future. I won’t judge them, it’s their choice but I refuse to follow such a path.

… the essence of society, what makes us human is not what we take but what we give. We all have failings, no-one is perfect and it is up to each and everyone one of us to try and find a balance that we’re content with and resist the worst excesses. Greed has never been good.

X : But won’t people exploit mapping, claim it as their own, demand others pay license fees?
Me : Of course, that’s bound to happen. But believing in humanity and a civil society doesn’t make you a pacifist. I’m not that, I am prepared to fight, tooth and nail, blood and claw.

… just because greed is not good does not mean that greed will not exist. Whether at the individual or at a nation state, we should always fight for what is right for all … for the many, not the few. That is the essence of what society means.

X : We’re all selfish genes.
Me : You realise I’m a former geneticist? If the limit of our imagination of what society is becomes simply procreating genes, a survival of the fittest where we define the fittest as those who survive then we are doomed and no more than a virus.

… if you’re happy with defining humanity as simply a viral infection of the earth then I can understand your point. I’m hoping that as a species we aim for something more.

X : How do you know other business maps didn’t exist before yours?
Me : I am certain they did. Sivowitch’s Law applies – whenever you think someone was first, the harder you look then you’ll find someone who was more first. I simply state that I was not aware of them.

… the problem with “first” is always attribution. People want to claim to be the first, to have their name immortalised (despite the fact it’s only ever temporary). I prefer to assume that maps existed before and better maps will come after. My focus is on fostering the after.

… it’s why attribution isn’t a big thing for me but creative commons share alike is. I want to see the idea of context grow. I don’t care what name a future maps carries – that is not important.

X : So why call it “Wardley” maps
Me : Several reasons. First, I’m lousy at naming things. Second, it opens the door to “Smith” maps or “Mercator” maps of business. It allows for the future to supplant the past. My maps are little more than clay tablets, they will be superseded.

X: Are you against people commercialising your form of mapping?
Me : Not at all. @kda (a good friend) took my blog posts, turned it into a book and sold it. I had no issue with this, nor do I have any issue with people making money from my form of mapping or derivatives of …

.. my only requirement is that you keep the field open, you allow others to build upon and develop it and those who come after to do the same.

X : You seem opposed to intellectual property rights?
Me : I know of no field that has done more harm to human society and limited progress in pursuit of greed. I am not a fan.

… you once asked me why we weren’t travelling among the stars in spaceships. The answer I will give is intellectual property rights. I can think of nothing that has damaged society and limited progress more over such a long time.

X : Warfare surely comes close?
Me : Yes. I did quite a bit of research on this and by all measures that I found, despite the common ideas of “innovation through war” that it harms progress. But as far as I can tell, IPR is the most harmful. In my view, it should be abolished.

X : I have combined your mapping with this other unrelated work that is proprietary. What should I do?
Me : As far as my mapping work goes, you are free to share and to share freely all the elements you derive from my mapping with others.

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.


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.


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.


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.


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.


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:


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.


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.


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.