Tuesday, May 14, 2019

Shamrock Mapping - A simple tool for improvement


I am a big fan of Wardley Maps and draw simple maps on a white board or napkin during every discussion of strategy.

Simon Wardley says they are imperfect as all models are and that's true - they are also the best way I know to facilitate a strategic conversation.

Chris McDermott has created a nice variation - Maturity Mapping - that combines Wardley Maps and Cynefin to help teams understand and address their maturity in different areas.

I have recently been using yet another variation that I call Shamrock Maps. A Shamrock Map is super simple and can be used for any part of the value chain. I usually draw a regular Wardley map using Visibility and Evolution as the axes and then zero in on the area(s) of strategic interest.

For those areas, I change the axes to Autonomy and Mastery - autonomy is our ability to move freely without interference from external factors; mastery is our ability to move freely without interference from ourselves.

I have been starting with a guess about where a particular activity/outcome lives. From there we observe the external WEIGHT. What policies, external dependencies, governance etc. impede us from releasing our work product into the real world and benefitting from feedback?

Having identified the top of mind factors weighing us down, we move to LIFT. What can we do to overcome or remove weight? Can we negotiate with an external approver to show our compliance as part of the process? Can we remove our dependence on other teams? Do we need to lobby for a policy update? There might be a lot of actions or only a few - this is a good time to think creatively.

Having discussed the autonomy axis it's time to move to mastery. Again we start with the impediments DRAG. Are we one deep in a critical skill or knowledge of the domain? Is crucial tooling missing? Is the codebase scary and dangerous to work in?

Finally we consider THRUST to overcome that drag. Would adding characterization tests help? How about spending a small amount of time doing some structural re-factoring to learn about the codebase while making it easier to reason about? Would making or buying some tool help? Could we use pairing or mobbing to overcome specialization?

One big advantage I've noticed over the last couple of weeks using this is that we end up talking about impediments and ways to overcome them that had not been identified as addressable. When we're in an environment for a long time, the constraints of the environment become normal to us and almost invisible. Firewall changes take 3 weeks - make sure to account for it in the plan. No! Let's figure out how to make that a non-event.

Anyway, I have found this approach useful and I'm writing this post because people I have shown this to are starting to use it and then tell me they can't find any information about Shamrock Mapping - now maybe they can :-)

Thanks for reading and hit me on twitter @mikeonitstuff with any feedback

No comments: