Miyamoto Musashi on Lean and Agile

The legendary swordsman, Miyamoto Musashi, understood the Lean/Agile mindset perfectly 400 years ago.

Here is an excerpt from Musashi’s Book of Five Rings. Two translations are given, as each brings out different nuances of the original text.

Translation by Victor Harris. This translation is commonly available as a free download from many online sources, most of which do not credit the translator.

 
It is necessary in strategy to be able to look to both sides without moving the eyeballs. You cannot master this ability quickly. Learn what is written here; use this gaze in everyday life and do not vary it whatever happens.

Translation by Hidy Ochiai. I find this translation to be clearer, although in this case the translator does not explain the meaning of kan and ken (perception vs. sight). It’s published in the book, A Way to Victory: The Annotated Book of Five Rings.

 
It is important to be able to see on both sides of yourself without moving your eyes. You will not be able to do this suddenly in an emergency situation. You must try to cultivate this method of seeing in everyday life and maintain the same type of eye focus at all times.

The spirit of this advice is consistent with the saying, “Think globally and act locally.” We should apply craftsmanship and precision to each little thing we do, but without losing sight of the larger context in which the thing exists. This may be harder to do than it sounds. Most people I meet tend to be big picture thinkers or detail-oriented “do-ers,” and few are comfortable with both perspectives simultaneously.

In Ochiai’s analysis of Musashi, he notes:

 
I see many connections here. Connections with behaviors that I observe in the field. Connections with LeadingAgile’s pragmatic approach to organizational transformation. Connections to the mountain-climbing or “expedition” metaphor for driving organizational improvement.

The common element in these connections is expressed nicely by Musashi’s description of the warrior’s gaze. It comes down to a holistic perception of the small and the large, the near and the far, the immediate and the deferred, and the ability to maintain consistent focus on what is significant on all those axes.

Behaviors I observe in the field suggest this mindset is not so easy to cultivate. Tell-tale questions include:

• “Whose job is it to refine the backlog?”
• “As we combine technical job functions, who will test my code?”
• “Why should I consider security issues in my design if they aren’t explicitly mentioned in the User Story?”
• “How can we convince business stakeholders to give us permission to refactor our code?”
• “If we’re tracking delivery performance by team, how do we assess individual performance?”

Questions such as these suggest the person sees but does not perceive; they see rules, and do not perceive meaning. They have not cultivated heijo-shin.

In all these cases, and countless others, people are considering one specific job-related task in isolation from its larger context, and they are hoping to find a recipe to dictate what they must do in every situation that may arise. The “task” may be of relatively large scope—something the CTO does, or something a Portfolio-level team does—or of relatively small scope—something an individual programmer or tester does—but there is always a single, overarching organizational context, and it is within that context that people make judgments about what to do from one minute to the next throughout the day. It isn’t a question of rules, although you might benefit from a few rules initially to help you find the path forward.

Such questions would not occur to a person who had cultivated heijo-shin. They would perceive the whole and do the right thing in context naturally, without strain. But cultivating heijo-shin is a challenge that requires mindful practice. Musashi is clear on this point: Reading isn’t enough; you must apply the ideas. Whatever you practice every day is what you will do when the heat is on. Therefore, it’s important to practice the right things. How does one know what to practice? With guidance and a compass, you can find the right path.

LeadingAgile’s approach takes into account three levels of abstraction in the organization, which we call Portfolio, Program, and Delivery Team. Each has its own broad set of responsibilities and scope of work, but all are part of a single cohesive whole. One can view this as an example of Musashi’s notion of perceiving the near and the far in a spatial sense. What we do at the Delivery Team level is part of what we are doing at the Program and Portfolio levels. What we do at the Portfolio or Program level must be done in a way that doesn’t impede Delivery Teams. Each task must be done with high quality but does not exist in isolation.

The LeadingAgile roadmap, which is based on the expedition metaphor, comprises five Basecamps. These represent milestones of improvement. One can view this as an example of Musashi’s notion of perceiving the near and the far in a temporal sense. What we do on the journey from Basecamp 1 to Basecamp 2 will set us up for reaching Basecamp 3 in the future, and Basecamp 4 after that. Each Basecamp is a milestone but not an end state. The real end state is that people no longer think in terms of an “end state” at all, and instead they practice continual improvement as a habit.