Something is not right. We ought to do better, I know that. But how? I think I need to consult an expert.
This is a common thought process for someone who cares and wants to improve working practices of an organisation. It is very tempting to solely rely on experts to fix our troubles, but the problem is that in life there are no silver bullets.
While experts can help, there is always a risk that they will match their most recent experiences with the new situation, and will apply previous solutions to the new context.
This pattern matching doesn’t guarantee that past solutions will work in the new context and, quite often they don’t.
So, I guess we’re all doomed. Well, not necessarily. There is something else that we, those running delivery programmes, can do to identify improvements and to create a strategy for improvements that puts us in the driving seat.
When it comes to strategy (I know, big words) there is no better place to start than Wardley Mapping.
We can use Wardley Maps to create a strategy for improvements by mapping capabilities required for a ‘thing’ to deliver.
My argument is that once the concept is understood this can be done by the people who are seeking to drive change.
It becomes a tool and a way of thinking, a tool for validating our ability to know and drive change in a systematic fashion. The strategy will be driven from within the delivery team.
The rest of the write-up contains my take on how I think about change in the context of an agile digital delivery programme.
Establishing the delivery landscape. Creating awareness.
Let me continue with a very brief introduction to Wardley Maps.
If you haven’t seen them before, they are quite intuitive to understand and build by following these steps:
- Create an anchor representing the person, group or a process whose needs we are trying to satisfy. In my context, it is the agile delivery itself.
- Identify components of interest needed to satisfy those needs — in this context of driving improvements of an agile delivery, the components are capabilities and other aspects needed for delivery (such as tools or artefacts)
- Chain the components using a dependency or value chain. This chain will form the Y axis of the map. Position them vertically based on their value or visibility — the higher the value or visibility the higher the component will appear on the Y axis.
- Lastly, position the components horizontally based on a form of evolution — given this context of mapping capabilities I used the evolution phases suggested by Simon Wardley for capabilities : Novel, Emerging, Good and Best.
This broadly translates to an X axis that models an evolution from “we’re bad at this (Novel)” to “we’re very good at this (Best)”.
There is much more to Wardley Maps [2], but this should be enough to introduce the concepts.
To bring this to life, let’s build a map interactively.
The anchor is the delivery function of a programme/project/product.
While now seems trivial, it took me a while to really establish what I want to put as an anchor. What am I mapping for? Wardley Maps are typically created to model the creation of a product or a service, where the anchor is obvious — the end user.
Once I had this mini breakthrough, the rest followed quite easily.
A Delivery needs at least Production management, Delivery team(s) and a Leadership team. These are the first components added to the map.
The next level down we have:
- Product management needs product ownership and a roadmap
- Delivery teams need a team management function, an onshore team, nearshore team and a PMO function
- Leadership team needs Programme leadership
- Communities of practice — in my model this is a direct need of the Delivery (anchor), but I chose to model it at lower level since I considered it to be less visible than the other immediate needs of Delivery, the first three components.
Before we continue with the interactive build of the map, I thought to talk a bit about the components of the map. How did I decide what to add or what to leave out?
I added those components that I thought were needed for the delivery for which this map was created (ok, it was done for a fictitious delivery, but you get the gist).
This is not an exhaustive list of components, and other contexts might have a different composition. For instance, some deliveries might not have an offshore component but would have other elements.
Conversely, in some context it would be more valuable to further expand certain components — i.e. Engineering practices can be further decomposed into a larger number of components.
This can be done on the same map, or on a dedicated one (in which case the component would become the anchor).
Simon Wardley, the creator of the Wardley Maps always says that no maps are perfect, and that a map is a model and we consider that “all models are wrong but some useful” [1].
While I don’t dispute any of that, I would like to add an important nuance — the quality of the map (and subsequently of the model) is directly dependent on the quality of the identified components. Poorly identified components will result in a low value map.
And this is where expertise can play an important role. You might say though that at the beginning of this write-up I didn’t appreciate the role of expert consultants.
That’s not what I meant. The nuance and the behavioural shift I want to draw out is that the team drives the improvement process.
They are the people who create the map and ask, “so what else do we need to add; what are the needs of a successful delivery ?”. What is the maturity level of each component?
They add their own contextual experience and ask the experts “what else?”. They drive, experts help.
A final point on the role of experts. They can also help assessing capability levels (the horizontal position of the components on the map).
But I propose the same approach — the team uses their contextual knowledge to assess the maturity and consult the expert for a second opinion.
Before resuming with the map, a quick note on the X axis — I found settling on what it should represent one of the hardest parts in the creation of the map.
Should it represent evolution or simply a measure of capability, from Low to High?
Even when considering Evolution, I wasn’t sure what it would the best categories — at one point I considered using the following ones: Novel, Emerging, Complicated, Obvious (widely used), inspired from Cynefin domains.
I settled after-all with what Simon suggests, but I do believe that this is a space of further explorations.
Now let’s resume with the map. Following the same process as outlined above, fast forwarding my map looked like below. It had now enough elements that allowed me to work with it.
Establishing the landscape is only the beginning. The question is, “so what now?”
Landscape done. So, what now?
Once the map is done, it shows the current landscape — where things are. Now we can use it to play the ‘strategy’ game — to make decision on where to improve.
We can look at the map and debate where to put our energy, which component worth improving, evolving (moving it to the right on the Evolution axis).
Assuming that we can improve on all areas at the same time is a naive view.
There is value in limiting the work in progress of improvements.
For instance, we can decide that Team management is one area that we can improve. Then we can bundle the Engineering practices and the Architectural practices as another area of focus with the Roadmapping tool being the third one.
The improvement process starts with using the map to establish what are the concrete actions we want to perform. We then move to execution, placing some probes along the way so that we can measure progress.
We then loop back, re-evaluate the map and continue the cycle.
The value of mapping is limited if it is done in isolation. Mapping is meant to be done in collaboration to:
- Identify the right components
- Debate the right levels of maturity (evolution axis)
- Discuss the strategy, where to attack and why
Is this approach a silver bullet? I wish, but there are no silver bullets. However this is something that we can all do together as a team, and make better decisions based on our contexts.
[1] George Box
[2] Read more about Wardley Maps here https://medium.com/wardleymaps