Musashi | Agile Software Development: The Cooperative Game (2nd Edition)

Miyamoto Musashi was a 17th-century samurai who never wrote software.

He claimed never to have lost a fight. Losing a fight meant serious body damage, and it was quite an accomplishment to be alive with all limbs in place at the age of 70.

A romantic novel series about Musashi depicts his early life, fights, and mental development. It is a wonderful read and also vividly portrays his fighting approach, which his personal book describes.

His personal book is the Go Rin No Sho, in English The Book of Five Rings (I have the Thomas Cleary translation, Shambhala, 2000), which he wrote at age 70. That book outlines his approach as clearly as he can make it, describing mental states, specific moves, and the use of large groups. It is short, clear, and wonderfully absent of the usual Zen doubletalk, "Be by not being, fight by not fighting, win by losing," and so on.

I include Musashi here because three characteristics of his fighting style match my software development style, and he describes them so well:

Do not develop an attachment to any one weapon or any one school of fighting.
Practice and observe reflectively.
Win.

The first recommendation is to use any and all schools and techniques, without great attachment.

At the time of his writing, warriors formed schools around particular stances, styles, weapons, and tactics. His view was that each had its merits and weaknesses; one should use the range of them without getting stuck in any one.

The same is true in software design techniques. Don't get stuck in UML, RUP, CMM, SEI, XP, CRC (insert your favorite school's or tool's acronym here). Use whichever you need at the instant you need it. Discover what you need at different moments, so you can develop a tool- and method-attack strategy that will tell you which one to pick up and when to put it down.

The second recommendation is to reflect on what you do and how you do it. Reflective practice has been discussed throughout this book.

The third recommendation is to pay more attention to winning than to looking good.

Winning the software development game is shipping the software. If you can do so without process, do so. My favorite-ever recommendation to a group was:

"What? You have a five-week project, with three developers who have done this before in the same technology? You don't need a development coordinatorjust do it and go home."

Musashi said, "Do not do anything useless."

Musashi cared about winning the game, which in his case was life-or-death. I am attached to delivering the software. The prettiness of the dance doesn't matter if the software comes out at the wrong time.

In the following, notice that even in the 17th century, Musashi describes Shu-Ha-Ri and the importance of developing skill.

The "opponent" in software development is the problem to be solved. "Killing the opponent" is delivering the software and winning the game. Here are some of his words (or Cleary's translation of them), presented as individual excerpts.

The Book of Five Rings

Now, in composing this book, I have not borrowed the old saying of Buddhism or Confucianism, nor do I make use of old stories from military records or books on military science. . .
The field of martial arts is particularly rife with flamboyant showmanship, with commercial popularization and profiteering on the part of both those who teach the science and those who study it. The result of this must be, as someone said, that "amateuristic martial arts are a source of serious wounds." . . .
The master carpenter, knowing the measurements and designs of all sorts of structures, employs people to build houses. In this respect, the master carpenter is the same as the master warrior. . . . As the master carpenter directs the journeymen, he knows their various levels of skill and gives them appropriate tasks. . . . Efficiency and smooth progress, prudence in all matters, recognizing true courage, recognizing different levels of morale, instilling confidence, and realizing what can and cannot be reasonably expected-such are the matters on the mind of the master carpenter. The principle of martial arts is like this. . . .
Speaking in terms of carpentry, soldiers sharpen their own tools, make various useful implements, and keep them in their utility boxes. . . . An essential habit for carpenters is to have sharp tools and keep them whetted. . . .
You should observe reflectively, with overall awareness of the large picture as well as precise attention to small details. . . .
Having attained a principle, one detaches from the principle; thus one has spontaneous independence in the science of martial arts and naturally attains marvels: discerning the rhythm when the time comes, one strikes spontaneously and naturally scores. . . .
In my individual school, one can win with the long sword, and one can win with the short sword as well. For this reason, the precise size of the sword is not fixed. The way of my school is the spirit of gaining victory by any means. . . .
When your life is on the line, you want to make use of all your tools. . . . We find that whatever the weapon, there is a time and situation in which it is appropriate. . . . Both the spear and the halberd depend on circumstances; neither is very useful in crowded situations. . . . they should be reserved for use on the battlefield. . . . [the bow] is inadequate for seiging a castle. . . .
In the present age, not only the bow but also the other arts have more flowers than fruit. Such skills are useless where there is a real need. . . .
You should not have any particular fondness for a particular weapon, or anything else for that matter. Too much is the same as not enough. . . . Pragmatic thinking is essential. . . .
Whatever guard you adopt, do not think of it as being on guard; think of it as part of the act of killing. . . .
Whether you adopt a large or small guard depends on the situation; follow whatever is most advantageous. . . .
(FIRST TECHNIQUE) . . . your sword now having bounced upward, leave it as it is until the opponent strikes again, whereupon you strike the opponent's hands from below. . . .
(SECOND TECHNIQUE) . . . If your sword misses the opponent, leave it there for the moment, until the opponent strikes again, whereupon you strike from below, sweeping upwards. . . .
(THIRD TECHNIQUE) . . . as the opponent strikes, you strike at his hands from below. . . . as he tries to knock your sword down, bring it up in rhythm, then chop off his arms sideways. The point is to strike an opponent down all at once from the lower position just as he strikes. . . .
Having a position without a position, or a guard without a guard, means that the long sword is not supposed to be kept in a fixed position. . . Where you hold your sword depends on your relationship to the opponent, depends on the place, and must conform to the situation; wherever you hold it, the idea is to hold it so that it will be easy to kill the opponent. . . . Even though you may catch, hit, or block an opponent's slashing sword, or tie it up or obstruct it, all of these moves are opportunities for cutting the opponent down. This must be understood. . . .
. . .how to win using the long sword according to the laws of martial arts. This cannot be written down in detail; one must realize how to win by practice.
. . .the power of knowledge of the art of the sword. This is something that requires thorough examination, with a thousand days of practice for training and ten thousand days of practice for refinement. . . .
Other schools become theatrical, dressing up and showing off to make a living, commercializing martial arts. . . . Do you think you have realized how to attain victory just by learning to wield a long sword and training your body and your hands? This is not a certain way in any case. . . .
. . .the views of each school, and the logic of each path, are realized differently, according to the individual person, depending on the mentality. . . .
Thus in my individual school there is an aversion to a narrow, biased attitude. . . .
In my school, no consideration is given to anything unreasonable; the heart of the matter is to use the power of the knowledge of martial arts to gain victory any way you can. . . .

Applying Musashi to Software Development

I share three views with Musashi. I differ on the fourth.

Appropriate Tool, Appropriate Technique

Know your tools, know what you need at the moment, and you will know how to get value out of the tools at your disposal, even if they aren't perfect. You can even profitably use tools that were not originally constructed for software development.

Here is how I work in two different circumstances.

When given a CASE tool to use, I first exclude from use all of the tool's capabilities that do not lend value to the project at hand. Although this is an underutilization of an expensive tool, my goal is not to use a tool to its maximum, it is to deliver software.

On a different project, we may select as our primary strategy having the CASE tool create the final code. On this project, we plan on extending the tool as we need to so that it performs the job we want it to do.

Know your favorite tools and techniques for key tasks without getting overly attached to any one. Learn to adapt to whatever is available.

Direct Solution

See if you can just "cut off your opponent's arm with a single blow," as in sword fighting. In software terms, see if you can just "do it and go home." Avoid waste.

When you have to feint, block, and parry, understand that you are doing that because there is no alternative. Do just enough of it to win. Avoid flamboyant showmanship, because it does not help deliver the system.

In software development, look for simple solutions to your process problems just as you look for simple solutions to your technical problems. Recall the one-sentence summary of Crystal Clear: "Put the people in a room with printing whiteboards, give them access to user experts, and have them deliver running tested software every two months." If you can do that, then just do that.

Reflection and Skill Development

Continue to develop your skill, and take time to reflect at regular intervals.

Microtouch Intervention

I do part company with Musashi in one area. He was in the business of killing or getting killed. I am in the business of helping people deliver software. There is a dramatic difference.

I like to cut quickly to the heart of the problem but keep the people fully intact. Arm-chopping is not an effective intervention strategy. I am after the smallest possible changes to the people on a project that accomplishes the job: micro-touch intervention. (Actually, I suspect Musashi would agree with me, if he were in my business.)

Microtouch intervention is based on two ideas:

With better understanding, smaller interventions are required.
Many microscopic changes can produce a very large effect in unison.

Better understanding, smaller interventions. Two centuries ago, syphilis patients died. A century ago they underwent near-fatal arsenic treatments. These days they are given antibiotics. Early antibiotics were broad-spectrum bacteria killers; nowadays the antibiotics are targeted to the specific bacteria they are to kill.

Early computers were made with large vacuum tubes. Then, they were made with transistors. Now they are made with only a few thousands of atoms, recently even just single atoms.

Less energy is needed to effect a needed change the better we understand what we are doing. When we understand enough, we need only move molecules small distances, and the consequences will ripple out to produce the macro-effect we are interested in.

In software development, we are still in the amputation stage. As we better understand the forces underlying our profession, we can make smaller and smaller changes to improve a situation. I know that asking people to change their personal habits is a big request, so I prefer to change team seating or a few job assignments and let the human communications mechanism effect the much larger changes.

Small changes add up. I find it remarkable that just aligning many, microscopically small magnetic domains in a metal converts a nonmagnet to a strong magnet.

Aligning people's purposes has the same effect on a project.

Imagine many people, working to their own value systems, pursuing whatever goals happen to hit them each day. They will sometimes, almost randomly, help each other or thwart each other.

Suppose you ask each person to make a tiny change, one that they find acceptably small. You can arrange the changes so that the people thwart each other less, help each other more. They are oriented in the same direction. With almost no energy change, the project team achieves a resulting power all out of proportion to the changes made (this is shown graphically in Figure 3-17 and Figure 3-18). This is summed up in Kent Arett's statement, "Paint the vision and get motivated people, and it's 'Game Over.'" (see "Fewer and Better" on page 195).

Microtouch intervention has its limits, of course. Sometimes, the correct move is not to continue with microtouch intervention but to replace the entire project structure with a new one. This happened once when we saw that a 30-person, colocated team could deliver the same as the failing 300-person multinational team.

The art, of course, is knowing when to rebuild the project and when microtouch intervention will work. Makes me wonder how Musashi would express that.