Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
Explore our extensive library of experience reports.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
Weekly discussion around “Deming’s Journey to Profound Knowledge” with author John Willis.
VIRTUAL — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
Venue: Fontainebleau — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
August 10, 2022
The practice of how to Wardley Map is difficult. Anyone who claims they are an expert mapper should be immediately discounted. In this post (excerpted from the book The Value Flywheel Effect by David Anderson, with Mark McCann and Michael O’Reilly), we’ll break down a little of what you need to know to get started with Wardley Maps. But keep in mind that mapping, like any skill, takes practice. And the more you practice, the better you get.
In Wardley Maps, the y-axis (vertical) represents visibility to the user. Like a traditional value chain, the higher the component, the more the user can see it. For example, a web page might be at the top, while a database or a server might be near the bottom. The x-axis (horizontal) is more complex and contains the four stages of evolution— I, II, III, and IV. They are usually labeled as Genesis, Custom Built, Product, and Commodity. It’s okay to change the labels, but the progression should be similar. Let’s break them down further.
The object is rare, poorly understood, and uncertain. There is the potential to have high future worth. The object is described with wonder, and it’s different from anything else in the market in this context. It should be a competitive advantage and experimentation is rife.
More people are starting to consume and understand the object. The market is forming, and there is potential ROI. As understanding increases, users start to find its value, but inconsistently. The key focus is learning.
Consumption is rapidly increasing as the market grows. The object is profitable, new features can differentiate it, and there is a refinement of needs. Things are starting to get competitive, and the profit margins mean it’s a crowded market.
The object is widespread and stabilizing. It’s a mature and ordered market. The high volume has decreased margins. Operational efficiency is king, and failure is not tolerated in the market. This is the cost of doing business (like electricity).
As we stated above, the labels on these four stages can change, but it’s more important to place components in the correct stage. It’s not a precise act; it should feel about right. Sometimes an easy way to start is to place the least common elements to the left on the x-axis (Genesis) and the more common elements to the right (Commodity).
Most maps will have one or two users at the top; this is the anchor component and forms the top of the value chain. It’s often helpful to discuss the user in detail, almost like a user persona. The user will have needs (which are components), and those components will have dependencies. The full link from user, to needs, to dependencies equals your value chain.
The dependencies between components are often shown as lines or arrows— both are fine. Some people add a label to the dependency to add extra context, but this is not necessary. Don’t add too much additional information and overload the map unnecessarily. There are several types of components, but describing components is a more advanced notation. For example, is the component built, rented, or bought? You could mention many other aspects, but when starting to map, it’s best to keep it simple.
Once a value chain has been mapped out, arrows can be added to show a component moving to the right along the x-axis. This denotes a future evolution as a product becomes more commoditized. Compute is a famous example—it took forty years for computing to move from Genesis (a new differentiator in a business) to Commodity (something you rent from any cloud provider).
It’s also essential to show inertia in your maps, where components are being blocked from moving to the right on the x-axis. Inertia blocks are usually things like regulation, company culture, cost, immature technology, etc. Inertia is represented by placing a block to the right of a component.
Any number of reasons can cause inertia. Sometimes it’s helpful to write the reason on the map. In the example map below, the staff would like to upgrade the kettle to speed up service. The inertia point is the café owner doesn’t see the benefit and is prevented the staff from making the upgrade.
When you’ve got the basic shape of the map, it’s often helpful to overlay two separate views (either one of them or both) onto the map. The team overlay denotes that Team A works here, Team B works there, and so on. Seeing which team does what can help you assess if the technical ownership responsibilities are correct. If everyone owns everything, you’ve got a problem (likewise if there’s no ownership).
In the “cup of tea” scenario, the map below shows two different groups: “front of house” and “kitchen.” This is quite a clean grouping. In your map, you might see teams that either overlap or are all over the map. This suggests that teams might be doing the wrong work or that they are spread too thin.
The second overlay is pioneer/settler/town planner (PST). This will be discussed more as we move on, but in short: Pioneers love uncertainty and thrive in building the new. They’re likely to create “the first-ever X.” Settlers can scale; they will refine, harden, and understand the concept. Settlers love to learn and share their learnings. They listen to customers and build things they love, and they’re likely to create “that fantastic product.” Town planners build well-defined things well. They industrialize well-understood concepts and create the building blocks for pioneering teams. They are likely to make things that are fast, cheap, and failure-proof.
All three groups are equally important, skilled, and critical. When the PST overlay is combined with the team overlay, you might find that a pioneering team is working on a commodity, or a town planner team is working on a custom build. These mismatches may be the source of some of your pain.
The figure below extends the “cup of tea” scenario map to include some artisan ingredients. A pioneer/settler/town planner lens has also been added. The buyer is living in uncertainty, trying to find novel new ingredients, and is thus a pioneer. The “front of house” is very customer-centric and learning as they go about what works and what doesn’t—typical settlers. The kitchen represents the town planners: focused on efficiency, little failure, and established processes. All three groups are critical to the success of the café but in different ways.
Another useful mapping element is the pipeline. A pipeline shows the continuous evolution of a component, usually when there is a clear path of evolution, not just a shift.
In the next figure, we can see the tea component represented as a pipeline. On the left, fresh tea (or loose leaf tea) is novel and evolves from a nice pyramid tea bag to a regular tea bag. Cost is likely high on the left and lower on the right.
The right-hand side of the pipeline includes more mass-market tea and represents a more evolved state. You can think of a pipeline as a slider from which you can select one component, fresh tea (loose leaf) or a tea bag, not both together. When reading the map, we select one component from the pipeline to use in our example.
Wardley Map Example of a Pipeline on a Map
When a map becomes complex, you might need to make a submap. In the figure below, we’ve replaced the components of the kitchen with an annotation for a submap. Usually, this is illustrated on the main map by a square or simply via an annotation. You would then create the submap on a separate board or paper. Make sure to keep it close to your master map.
The best way to start mapping is to go to a board or grab a pencil and paper and just try it. There are some fantastic tools available for virtual mapping, but it’s important to keep early sessions simple. When mapping, think about these three phrases:
Don’t copy a map. Use another map or document to understand your organization’s dependencies. For example, a mobile app may have some key dependencies. In time, the mapping community will share these common patterns to accelerate first-time mappers.
Designing a practical collaboration session is essential. There are a few key areas to consider. First, ensure all participants are willing to try the session. Provide some simple preparation work or contextual materials that people can read ahead of time. Allocate enough time to create the map; don’t rush. Set the right tone: everyone is participating in the map—it’s not a presentation. Finally, facilitate fairly—let people speak, make their point, and add to the map. Welcome all suggestions and don’t dismiss ideas out of hand. Just like a good meeting, a good mapping session relies on participants being prepared to contribute. The facilitator should allocate enough time so everyone can share without rushing the work.
Weeks or months after the fact, you may well come back to the map to see if the story still makes sense. If the map instantly builds the story in your head, then that’s a good sign. If it takes time to understand your map, then you might need to revisit the map or make a new one. A second test is to present the map to someone who was not at the initial meeting and ask them to tell the map’s story. Did they get it?
—
Next week we’ll explore some principles and antipatterns of mapping. You can read more in the forthcoming book The Value Flywheel Effect by David Anderson, with Mark McCann and Michael O’Reilly (Coming November 29, 2022).
David Anderson has been at the leading edge of the technology industry for twenty-five years. He formed The Serverless Edge, and continues to work with clients and partners to prove out the thinking in his book, The Value Flywheel Effect. He is also a member of the Wardley Mapping community.
As a business leader, you know that artificial intelligence (AI) is no longer just…
Welcome to the twelfth installment of IT Revolution’s series based on the book Investments…
In today's fast-paced and ever-evolving business landscape, organizations are constantly undergoing transformations to stay…
Holy cow, Enterprise Technology Leadership Summit Europe Virtual is happening next week, and I’m…