Of course, this was said in jest, but you can still gain value from Wardley Mapping without actually learning it in depth. I’m here to show you how.

​

What if I told you that you can benefit from the strategy during your next retrospective, whether agile or not, and it will only take 30 minutes to prepare yourself for a session and Q&A?

​

That is certainly possible by reducing the scope.

​

You do not need to learn the entire framework and educate your team. You can just take some of the universally-applicable Wardley Mapping principles that everyone considers obvious but nobody talks about, and talk about them. Your team and company will appreciate it.

​

Think about the first principle: "Use a common language." Nobody will ever disagree that being able to efficiently communicate with the rest of the company is a good thing. Yet, when was the last time you evaluated whether the rest of the company understands your team well enough?

​

In Wardley Mapping, there are forty similar principles that form a body called "Doctrine." Unfortunately, the word "Doctrine" brings negative connotations, such as blindly following beliefs or trying to implement rules and policies without practical considerations.

 

Had Simon Wardley decided to use an alternative translation of Sun Tzu's "Art of War,", this part of mapping could have been called "Method and Discipline" - a set of activities you need to master if you want to succeed. Simon also uses the term "Principles," which emphasizes that Doctrine pieces are not recipes, but areas to look after.

 

In other words, it is up to the team to decide how a particular area should look, and the primary measurement is how the team feels about a given principle and how consistent those feelings are. If most of the team says they do not use a common language, then it is clear something isn’t right.

​

I bring good news, because the only thing you need to do is draw the team's attention to a few of the principles. The list also contains links to book passages in which Simon introduced them, if you are particularly curious.

​

• Use a common language (Simon's description)

• Challenge assumptions (Simon's description)

• Focus on high situational awareness (Simon's description)

• Know your users (Simon's description)

• Focus on user needs (Simon's description)

• Remove bias and duplication (Simon's description)

• Use appropriate methods (Simon's description)

• Think small (Simon's description)

• Use a systematic mechanism of learning (Simon's description)

​

There is nothing on that list you can disagree with, right? And you do know you should have it covered, right? That will be the stance of your team, too!

​

The doctrine can be also formatted as a table, which may be easier to consume and evaluate, as in the image below: