How will this save me money?
Remove friction between practices, capabilities or silos of practice (e.g. departments, teams, experts within teams) by highlighting misalignments in how the work is configured.
Shorten the time to embed new technologies and ways of working by pointing out what practices have to change and how.
Facilitate most organisational change and ensure that the effort is spent effectively by locating where to focus the change effort.
Inform and support attempts of reorganisation by suggesting how to change the arrangements of practices to deliver the desired outcome.
How will it make me new money?
Discover new ways of interacting with customers and the wider environment in which the organisation operates by locating friction between practices and/or capabilities in meeting these needs.
Allow emergence of new capabilities by setting direction (e.g. articulating a new yet unmet need, i.e. new meaning) and using Maturity Mapping to play through new combinations of existing practices and capabilities to meet that need. In combination with carrying out experiments, this is a deliberate form of exaptation (and making exapting a practice in itself).
How long does it take?
The short answer is that it depends on the problem we are trying to solve. Maturity Mapping can be scaled to fit the desired size.
A single half day mapping session with a small team around a focused problem can produce new insights and options for improvement. To map the capabilities in an agile software team usually requires 3 workshops of 2-3 hours each when facilitated by a Maturity Mapping expert, plus maybe half a day for the analysis and clean up of the artefacts, if that is desirable.
Investigating the problems in cloud adoption for an operational team serving 8 product teams (i.e. 9 teams of various sizes) can be done in a month. Including experiments into the time frame of the mapping exercise can stretch this to 6-7 weeks of work carried out over a period of 3-4 months (depending on the time it takes to carry out the experiments), with most of the facilitated workshops happening in the 1st half.
For any multi-team engagement, time with the leadership will be required as well, up front to scope and plan the engagement, during the actual mapping activity to reframe some of the scope of the engagement based on the feedback from early mapping sessions and at the end to reflect on what was discovered and how to apply it going forward. Again, these need to be facilitated workshops, so add 2-4 weeks for that.
What’s roughly the process?
Ideally, find someone who can facilitate the process who is not part of the organisation (or organisations) in which you are mapping. This is to minimise bias in the facilitation itself.
Start by having a good problem statement (or statements) to frame the scope of the exercise, what needs are to be explored and know who has those needs (because you should consult them when validating if improvements were achieved). If possible, you should capture some hypotheses around what you expect to observe on the maps you intend to make.
We suggest starting with collecting the practices that are performed to meet that need on practice cards. Depending on the problem, you might want to add specific attributes for these practices, but make sure you keep the three core attributes (Meaning, Material, How to do it well).
Then place the practices on the map and connect them, they should build a network. If you get a linear, or close to linear, connection of practices, you are likely to have missed important aspects of how the need is met. You might need to observe how the work is getting done to discover these. You want to make all practices that are needed to meet the need visible.
What’s the theory behind it?
Maturity Mapping is based on Practice Theory and uses Simon Wardley’s mapping technique as its main visualisation method. We were specifically inspired by Social Practice theory. It sits within the domain of socio-technical research and analysis and has been influenced by Design (the academic type, as well as some other applications of Design), but we do not claim to be Designers. It has grown out of our own practice as organisational coaches and consultants. We use models from complexity and network research to inform experiments, e.g. Cynefin.
Using the lens of practice theory, we could say that Wardley Mapping has a bias for the material, for the “thingness” of what is being mapped and Maturity Mapping has bias for doing, the socio-material enactments that enable the things. As Maturity Mapping evolves, we expect that deviation to become more articulate. We are relying on Simon’s technique because we have not (yet) found a better visualisation for maturing practices.
Social Practice Theory aims to describe a practice by inspecting three elements:
- Meaning
- Material
- Competences
Under Material we mean any physical (and sometimes even meta-physcial) material that is necessary to perform a practice. A practice is performed in a physical space at specific times as an interaction with material (e.g. technology).
With Competences we mean any kind of knowledge, knowing of, as well as knowing how, that is necessary to perform the practice. This includes skills, knowledge of reference systems, categorisations, policies, domain knowledge, social knowledge etc.
When capturing practice cards, we usually focus on these core elements to the extent that the information is or could be relevant to the problem we explore. Friction can then be observed when either *Meanings, Materials *or Competences (or, of course, a combination thereof) between connected practices do not align. The information from the cards will inform the discussion of how better alignment could be found between those practitioners.
On the practice card, we decided to replace asking explicitly for competences by asking for “Doing it well’. Answering the question allows us to think about positioning the practice on the Evolution axis as well as implicitly asking for competences.
We often can also describe capabilities with these three elements, which can help understand friction between capabilities. There is a somewhat fractal nature to the lens of practice. We can configure practices into capabilities and practices themselves can often be seen as configurations of smaller practices (e.g. tacit practices or routinized behaviours). Capabilities can then be seen as a higher order system emerging from integrated practices, where their meaning will be different, sometimes transformatively so, but the materials and most required competences will be the same as in the underlying practices.
Regarding Simon’s mapping technique, we believe that Maturity Maps are Wardley Maps, i.e. satisfy his criteria for a map, but what we’re mapping is informed by practice theory, i.e. we are taking a different approach than Simon suggests for practices.
Using the lens of practice theory, we could say that Wardley Mapping has a bias for the material, for the “thingness” of what is being mapped and Maturity Mapping has bias for doing, the enactments that enable the things. As Maturity Mapping evolves, we expect that deviation to become more articulate. We are relying on Simon’s technique because we have not (yet) found a better visualisation for maturing practices.