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 that puts us in the driving seat. strategy for improvements 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 required for a ‘thing’ to deliver. mapping capabilities 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: - representing the person, group or a process whose needs we are trying to satisfy. In my context, it is the agile delivery itself. Create an anchor - 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) Identify 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. Chain the components - Lastly, based on a form of evolution — given this context of mapping capabilities I used the evolution phases suggested by Simon Wardley for capabilities : , , and . position the components horizontally Novel Emerging Good Best This broadly translates to an X axis that models an evolution from “we’re bad at this to “we’re very good at this ”. (Novel)” (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 needs at least , and a . These are the first components added to the map. Delivery Production management Delivery team(s) Leadership team The next level down we have: - needs Product management product ownership and a roadmap - need , an , and a function Delivery teams a team management function onshore team nearshore team PMO - needs Leadership team Programme leadership - — in my model this is a direct need of the (anchor), but I chose to model it at lower level since I considered it to be less visible than the other immediate needs of , the first three components. Communities of practice Delivery Delivery 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 component but would have other elements. offshore Conversely, in some context it would be more valuable to further expand certain components — i.e. can be further decomposed into a larger number of components. Engineering practices 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 “ ” [1]. all models are wrong but some useful While I don’t dispute any of that, I would like to add an important nuance — the (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. quality of the 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 c the map and a “so what else do we need to add; what are the needs of a successful delivery ?”. What is the maturity level of each component? reate sk, They add their own c nd ask the experts “w . They drive, experts help. ontextual experience a hat else?” 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 L to H ow igh? Even when considering I wasn’t sure what it would the best categories — at one point I considered using the following ones: , , , ), inspired from Cynefin domains. Evolution, Novel Emerging Complicated Obvious (widely used 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 axis). Evolution 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 is one area that we can improve. Then we can bundle the and the as another area of focus with the being the third one. Team management Engineering practices Architectural practices Roadmapping tool 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

Map Your Improvement Strategy Because That Expert You Hired Has No Magical Bullets

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps