IMPROVE YOUR TEAM PERFORMANCE WITH DOCTRINE
It’s worth considering whether learning a new framework is a good investment. If the author says you need seven years to learn it, it may not be worth it in the end.
Image 1: Simon's tweet.
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:
Use a common language (necessary for collaboration)
Know your users (e.g. customers, shareholders, regulators, staff)
Think small (as in know the details)
Use a systematic mechanism of learning (a bias towards data)
Challenge assumptions (speak up and question)
Focus on user needs
Focus on high situational awareness (understand what is being considered)
Remove bias and duplication
Use appropriate methods (e.g. agile vs lean vs six sigma)
Table 2: The first nine doctrine principles arranged in a table.
Using Doctrine To Enrich Your Retrospective
There is a three step agenda to follow to help your team improve the first nine areas of Doctrine.
1. Have your team evaluate how well they think they are doing
Each team member should individually use the green, amber and red flags. Hint: You can either print out the template in a large format and use post-it notes to mark the rating, or paste the template into your Miro/Mural board.
Image 3: Result of a session. Opportunities for improvement are clearly visible.
2. Analyze & Discuss
Ask the team why they have chosen a particular flag and let them discuss. They should tell stories that will illustrate what worked well and what did not in specific areas.
Identify the most significant deficiency and commit to one, small, safe change you want to make. You know how to take it from there.
You do not need to learn entire mapping to get value out of it!
Doctrine points are the general business capabilities every company should master (or the business will eventually fail)
Using Doctrine for retrospectives requires almost no preparation but can add ton of value to the company. It is definitely worth testing.
Let Chris know how it went!