" /> Shu Ha Ri — An Agile warrior's journey on The Way


Shu Ha Ri is the principle by which Japanese martial arts are taught. The principle can be applied to learning other arts as well, like Agile project management and software development. Its application in this context is explained really well in the Agile In a Flash cards.

I study both Japanese martial arts and Agile. Expect posts on both from time to time.

The meaning of shu-ha-ri

April 15, 2013 · By James Holmes

Debate of the usefulness of shu-ha-ri seems to be common right now. However, much of the debate may be framed in a misunderstanding of the original meaning of the concept. For clarity, I’ll give an abbreviated quote from the Encyclopedia of Japanese Martial Arts by David Hall:

Shu-ha-ri is a metaphorical equation describing the three stages of development through which exponents of classical martial disciplines may pass on the way to attaining expertise.

Shu; Lit “protect.” This refers to the trainee’s dedication to study in a chosen martial ryū. This inculcates him in the techniques and underlying principles of the ryū. Shu is meant to be experienced and intuited as explanations are often non-verbal.

Ha; Lit “break.” Traditionally, upon completion of shu, a trainee was permitted by his original headmaster to examine and train in another ryū. Ha recognises the trainee’s having obtained a solid technical basis in the ryū he has been studying, able to perform naturally and automatically. The trainee should naturally feel an obligation to maintain his skill in the original ryū.

Ri; Lit “to separate from.” Ri relates to the natural evolution of seasoned martial artists aspiring to create their own systems or schools. He may create an entirely new ryū, or he may become headmaster of one or more of the schools he has studied over the years, or he may create a branch tradition of his former ryū. He has separated himself from his original relationship with his primary tradition and has become a leader in creating a new - or renewed - tradition.

There follow some important points from this.

  • Shu level is hard. A high level of technical skill and understanding in a difficult art is gained during shu. There is no implication of rote learning or cargo cult mindset. Instead, experience under coaching brings understanding; this understanding changes over time as progress is made.
  • An experienced (senior) person studying shu will be teaching others at shu level. Teaching others solidifies one’s own understanding.
  • Once a student commences ha, their experience learning a new ryū will not be the same. They have all of their previous experiences on which to draw and they will learn more about both the new ryū and their original ryū than they could learning either alone.

Through shu and then ha, good coaches will lead a student to their own understanding, rather than forcing the coach’s own understanding upon the student. The role of the coach is to

  • provide a system that protects the students from harm during the learning process and provides real skills at the beginning of the learning process
  • ensure the student performs the kata correctly, thus allowing them to find the deeper meaning and ensure that safety is maintained

They will begin by telling you how; they will later ask you why.

So why might one apply shu-ha-ri thinking to software development? Some possibilities:

  • Common Agile techniques have been thoroughly tested by others. When correctly employed under the guidance of a good Agile coach, they provide a safe way of spending customers’ money while allowing understanding of the agile values and principles to develop.
  • Existing systems (e.g. Scrum, XP) allow for a quick agreement on techniques, without the overhead of inventing everything up front.
  • Software development is design work and design is an art, not a science.

Do not engage in useless activity

March 03, 2012 · By James Holmes

The last of Musashi's rules for learning the art:

"Do not engage in useless activity. Do not argue about useless things. Concentrate on your duties."

As my co-workers will attest, this rule is dear to my heart. It's not just relevant for studying Zen, it's also derived directly from the fact that anything you do that doesn't deliver value to your client is wasting their money.

Long philosophical debates over whether pointers are evil are not delivering value to your client (most noticeably when the language you're currently employing doesn't have them). They also waste your energy, which should be spent on improving the software on which you are working.


Do not be negligent

March 03, 2012 · By James Holmes

The 8th rule of learning the art as per Musashi:

"Do not be negligent, but pay attention even to the smallest details. Keep them in mind all the time, so as to avoid unexpected failure."

The direct equivalent in Agile of this is the buildup of technical debt. Quality in a project is non-negotiable and any debt you accumulate will bite you in the arse eventually.

Pay attention to the things you know you need to fix; don't forget the "refactor" step in red-green-refactor. There is nothing as nice in an Agile project as the last week, where everything has already been done properly and you're just tidying up. Leave the last minute scramble to the waterfall-driven abortions that other teams are producing.

Don't rely on what you see

March 03, 2012 · By James Holmes

The 7th of Musashi's rules for learning the art:

"Be aware of those things which cannot be easily seen with the eye. Develop intuitive judgment and a mind that freely controls one's body."

Perception is strong; sight is weak. What you see happening is only what people want you to see; their motivations, feelings and intent are far more important. 

Agile has tools that help. The client comes to us with what they think they need; in rare circumstances, they are right, but more often than not they have no clue. The iteration process lets us put a built product in front of the user as soon as possible and this gives us the opportunity to observe them use it; that's where the real feedback happens. What they tell you could be less important that what you observe while they're using it.

See the truth in all things

March 03, 2012 · By James Holmes

Musashi's 6th rule for studying the art:

"Nurture the ability to perceive the truth in all matters. It is important to build up an intuitive judgment and understand true values."

There is a lifetime of study in this, but just being aware of the principle is a start. Your judgement is important. Poor choices made early on in the project can have wide ranging consequences and even though Agile delays decisions to the last possible moment, those decisions still cost development time if they need to be reversed. The experience you build up over time will help you make better decisions, without having to see everything up front. Architecture, frameworks and all sorts of major decisions get simpler over time.

To the beginner, there are thousands of choices; to the master, there is only one.

Know the difference between loss and gain

September 25, 2011 · By James Holmes

Musashi's rule number 5 for learning the art:

"Know the difference between loss and gain in worldly matters."

Things change. People often focus on what we miss when something changes, the effort required when we let go of something or the negative repercussions of a failed project. These things are usully seen as a loss. They are not.

Change is inevitable and every change is an opportunity. If a tool isn't working for you, drop it; use what you've learned to make the next one better. If a team member leaves, you'll quickly learn what knowlege was in their head instead of written down; capture the info and reap the gain in improved knowlege transfer in the future. Even a failed project isn't truly a loss unless you don't know why it failed and you didn't know about the failure as soon as possible. Learn to see the signs and take the lessons into the next project.

Be knowledgeable in a variety of occupations

September 11, 2011 · By James Holmes

Number 4 in Musashi's rules for learning the art:

"Be knowledgeable in a variety of occupations, and learn the thinking of people who work in them."

The client is seldom another developer and their software is something they need to use, not you. Becoming familiar with how they do their work is essential to establishing how to deliver value during development. Being familiar with how people who aren't the client do their work might even open up possibilities for doing things a new way, delivering even more value. Just as the thinking of traditional engineering led to the awful mess that is waterfall software development, the thinking of a computer savvy coder by itself may not lead to the best solution to a problem.

Cultivate a wide range of interests

September 06, 2011 · By James Holmes

Musashi's third rule for learning the art:

"Cultivate a wide range of interests in the ten skills and ten arts. Then one can definitely find the benefits of hyoho and develop oneself."

Agile practitioners need to be able to wear many hats. This isn't just true for programming languages, frameworks and tools; it's also true of all the other roles within the Agile team. One day you may need to run a retospective; another you might need to be a BA or a tester. Each of these roles requires a different mindset and proficiency in all of them makes you a better designer when it comes to cutting code.

Remeber, all the patters, algorithms and other stuff you did in your degree is science. The Agile part is an art.

The Way is in training

September 06, 2011 · By James Holmes

The second of Mushashi's rules for learning the art:

"The Way is in training. One must continue to train."

It's important to continually learn new things, practice the skills we don't use as often and approach every development task as an opportunity to improve. If you get to the point where you think you know everything and you stop learning, you've stopped being Agile.


Do not harbor sinister designs

September 05, 2011 · By James Holmes

Number one of Musashi's rules for learning the art:

"Do not harbor sinister designs. Think honestly and truthfully."

This is the key to Agile development. Agile is an honest process that faces up to reality. Time, money and resources are limited and Agile demonstrates this by showing the client what can't be done in the chosen timeframe or alternatively how long it will take to deliver a chosen set of functionality. The release wall shows the real state of the project; the burn up chart shows the real rate of progress. Problems are discovered early and change is accepted as a fact of life.

Honesty is, after all, the best policy.

← Previous Entries