Improvements, experts and the elusive silver bullet
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 the working practices of an organisation. It is very tempting to rely solely on experts to fix our troubles, but there are no silver bullets in life. While experts can help, there is always a risk that they will match their most recent experiences with the new situation and apply those solutions to the new context. This most recent pattern matching doesn’t guarantee that past solutions will work in the new context; 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 put 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 systematically drive change. 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 an agile digital delivery programme context.
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 you can build them by following these steps:
- Create an anchor representing the person, group or 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 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 , 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 establish what I wanted 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, a 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, a nearshore team and a PMO function
- The 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 a lower level since I considered it 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 contexts, 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” . 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) directly depends 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 I didn’t appreciate the role of expert consultants at the beginning of this write-up. 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, and experts help.
A final point on the role of experts. They can also help assess 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 of creating the map. Should it represent an evolution or a measure of capability, from Low to High?
Even when considering Evolution, I wasn’t sure what would the best categories — at one point, I considered using the following ones: Novel, Emerging, Complicated, Obvious (widely used), inspired by Cynefin domains. I settled, after all, with what Simon suggests, but I believe this is a space for further explorations.
Now let’s resume with the map. Following the same process outlined above, fast-forwarding my map looked like the one below. It now had 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 decide on where to improve.
We can look at the map and debate where to put our energy and which component is worth improving and evolving (moving it to the right on the Evolution axis). Assuming that we can improve on all areas simultaneously 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 we can improve. Then we can bundle the Engineering and 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 to 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.
 George Box
 Read more about Wardley Maps here https://medium.com/wardleymaps