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.
LLMs and Generative AI in the enterprise.
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.
New half-day virtual events with live watch parties worldwide!
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 17, 2022
Now that you’ve learned the basics of how to Wardley Map in our last post, let’s look at the principles and antipatterns of Wardley Mapping as outlined by David Anderson in the book The Value Flywheel Effect.
The first principle of mapping is to admit you are unsure of the way forward. It’s worth exploring this principle and others deeper before we dive into mapping. Mapping is not an easy skill to master, and it’s worth understanding these key principles first.
Admit we are unsure of what to do next. Embrace the unknown by admitting the way forward is unclear. We need to explore and map out the territory, and then we’ll be better informed when we decide to act.
Mapping is a collaborative exercise; debate is essential. Mapping in the open reduces tension and creates alignment. Creating a map individually and showing it to the team as “the plan” is not a good strategy. Using the elements of mapping as a “common language” helps the team connect, even outside the mapping session. Simple observations like “that’s a commodity,” “this feels like custom build,” or “that’s an inertia point” carry much more weight when the team understands the impact of those statements.
The user’s needs come first. Every mapping session starts with the question, “Who is the user and what do they need?” This gives the session an “outside-in” lens and sets the scope of the conversation. It’s also important to discuss what we need to do for the customer, not how we make things easy for ourselves.
Either dive down into the weeds or go big. Set the scope at the start of the conversation and try to stick to it. It’s one of the most challenging things and may require a “parking lot” for submaps you’ll draw later. It also reduces complexity: “This component represents data; we can deep dive on the data landscape in a separate map.”
Find the story. Ultimately, many maps will create a narrative. Part of the joy of mapping is that it’s difficult to predict what that story will be. Once found, it’s easy to describe the map using that story. This is also an excellent way for people new to mapping to understand it.
Don’t map the world. It’s very tempting to put everything down as a component. Once you have more than twenty elements (or components) on your map, it’s gone too big—break it down.
The conversation is more important than the map. Mapping is not a formal notation; the point is not to create the perfect diagram, put it in a document, and send it to everyone. The map is merely a stepping stone to key observations. Treat the drawing as a throwaway and make sure meaningful conversation is captured on the map.
Challenge the map, not the individual. The hidden magic of mapping is the facilitation of challenge. Compare these two statements: “I think that component should be more to the right,” versus “I think this slide is incorrect.” The first statement is straightforward, as the effort needed to move a component is tiny. The second statement is a popcorn moment. Just sit back, start snacking, and wait for the fireworks. But a single slide could be days or weeks of work. Maps facilitate the challenge of ideas by focusing on the map, not the person who suggests the idea.
Just as there are things you should do during mapping exercises, there are things you shouldn’t do. We outline a few antipatterns to avoid below.
Don’t preempt or influence what the map will look like. It’s a collaborative exercise, not a tool to influence others. Use the map to explore, to discover new information, and come to a shared understanding.
If you bring a map into a team, then it’s your map— not the team’s map. The act of cocreation is one of the superpowers of mapping—remember, the conversation is more important than the map. A map represents a conversation and a line of thinking. Mapping by yourself is a good way to flesh out a thought process, but it’s your thought process, not your team’s. There are some things you can do to save time with the team, but don’t do all the work up front.
Don’t draw an architectural diagram and try to squeeze it into a map. Architectural diagrams are complex and important. Maps don’t need the detail, and the relationships in maps are dependencies, not calls. Architectural diagrams rarely include the customer, apart from a token stick person. Maps revolve around the user’s needs.
A map should simplify. It’s okay to leave things out. There’s a rule that the less experience you have in mapping, the simpler your map should be. Expert mappers: use no more than fifty elements in a map. Intermediates: no more than thirty elements. Beginners: don’t use more than fifteen elements.
Maps aren’t formal notation; focus on finding the flow of users and needs. Identifying a component is an art form, not a science. You’ll eventually find a “right size” for your map. It’s sometimes helpful to think of a component as a service or capability. Think about what the thing does, not what it is (e.g., disposes garbage, not sanitary worker).
If you’re excited by the technique, don’t overuse it. You’ll drive your coworkers crazy! Yes, it’s useful when thinking about value chains, user need, and the evolution of components. But mapping takes time to fully comprehend, so forcing mapping on people who have not been on your journey may not have instant success.
Start with the conversion and observations. Some people will not care about the map. Every map has a narrative, and that narrative starts with an observation. Many people will only care about the observation and never need to see the map, while others will be interested in the narrative that led you to the observation. The narrative is not the order you drew the map in, it’s the value chain narrative, starting from the anchor.
If a bad environment exists in the room, collaboration will suffer. It’s not productive to force people to map. There are many techniques for creating psychological safety, and often preparation is required to get people into the room with the correct attitude. Facilitation is still required and critical for successful mapping sessions.
—
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.
No comments found
Your email address will not be published.
First Name Last Name
Δ
You've been there before: standing in front of your team, announcing a major technological…
If you haven’t already read Unbundling the Enterprise: APIs, Optionality, and the Science of…
Organizations face critical decisions when selecting cloud service providers (CSPs). A recent paper titled…
We're thrilled to announce the release of The Phoenix Project: A Graphic Novel (Volume…