How Do You Learn Agile?

If you’re picking up a new skill, method, or tool, how do you learn to apply it?

Perhaps you like to read instructions and follow them. Or maybe you prefer to have an expert teach you. Another option is trial-and-error. There are multiple learning styles.

What if you’re learning something as deep and impactful as an overall approach to work, such as Agile?

This important question is a popular one at Agile conferences, where its thought leaders and teachers mingle with practitioners. A particular answer that seems to come up at every conference is called Shu-Ha-Ri. This model of developing mastery describes a simple sequence:

In stage 1, Shu, the student follows the teacher precisely. The student focuses on execution, not on theory, principles, or explanations.

In stage 2, Ha, the student learns the theory and abstractions behind the moves, and learns from more teachers. He then integrates this knowledge into his practice.

In stage 3, Ri, the student is now a natural, making some of her own rules.

You might recognize this sequence from martial arts, where this model was first identified. Or, if you’ve learned to play a musical instrument, and had a teacher, you probably followed Shu-Ha-Ri. You learned to drive the same way. But what about learning Agile? According to many speakers and writers, Shu-Ha-Ri applies there as well. First follow prescription, then master the theory behind it, then adapt all that to your specific needs. Which prescription should you follow? Popular ones are Scrum and SAFe. These, and a few other frameworks, are explicitly documented to the point that you can be certified in their application.

Sounds good in theory, right? In my experience, this is risky business for several reasons.

To start, a Shu-Ha-Ri assumption is that the student learns from a master or a teacher. The way most people learn Agile, their master is a trainer whom they only see once. The training is too short and rarely customized for them. For months, they try hard to follow the rules, which tend to conflict with their organizational reality. All this time, nobody is actively watching their learning and application — only their results.

Then, there’s technique vs. approach. If you believe that Agile is a process and a collection of practices, then you can in fact go through the motions quite precisely. But Agile is first and foremost a way of working, and no prepackaged set of techniques can yield optimal results in every context. For instance, many teams diligently perform the daily standup ritual, yet fail to share anything useful in that meeting. Some teams conduct wonderful, regular demos… in front of audiences that can’t give much useful feedback. They follow the prescription, but it doesn’t make a big enough difference.

Third, emphasizing techniques over theory, in the early stages of learning, will only work if the student is motivated to apply those techniques. When you learn to play the piano, it’s because you want to make music, not because pressing black and white keys is particularly appealing. Some Agile techniques are similarly less than exciting (do you know anyone who loves the daily standup, or someone who delights in sprint planning?) You have to know what those techniques are meant for — and care about that — to keep doing them. The answer lies hidden in the principles and values, which are de-emphasized in Shu.

Lastly, Agile is a team-centric approach. A team will perform well when every member wants to be a member. However, before the team gets to this point, it’s likely to spend months “storming.” During this time, some members don’t truly care to be on that team, yet they are all supposed to act as a team: plan together, work together, improve together. By placing emphasis on practices and techniques, the team will experience greater conflict. One time-tested strategy — popular in team sports — is to keep bringing conversations back to shared understanding, principles, and goals.

In my opinion, Shu-Ha-Ri is not suitable for adopting Agile, particularly due to “Shu”. Of course, you must have a concrete starting point — some process, some structure, some practices — and hopefully they fit your situation. But you also have to know the principles and concepts behind the moves and mechanics, and they have to matter to you. You have to keep studying them, so you can respond effectively to surprises that the process doesn’t account for. If you want to change how you think about work, you have to start with the thinking, not with the doing.