Agile 2014 – Stuck in Shu – Time to Change How to Teach Scrum

August 3, 2014 — Posted by Al Shalloway

It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. - Mark Twain

 The problem ain't what people know. It's what people know that ain't so that's the problem. – Will Rogers

 A man who carries a cat by the tail learns something he can learn in no other way. Mark Twain

There are three kinds of men. The ones that learn by readin’. The few who learn by observation. The rest of them have to pee on the electric fence for themselves. – Will Rogers

Experience by itself teaches nothing... Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning. – Edwards Deming

I’ve never liked the Shu Ha Ri metaphor for learning applied to knowledge workers. In fact, I believe it has been a cause of bad Agile and a justification for bad training/coaching.  Shu ha ri means to:

  • Initially obey traditional wisdom – that is, just do the techniques without question
  • Break with the traditions to go further than the initial practices
  • Transcend the traditions to do what is truly needed

This all sounds great except for a few things.  The metaphor implies many things that are contrary to our needs.  We’re not learning karate or any Japanese martial art.  It ignores that in learning a martial art, one wants to disengage the mind and just get the body to learn without thinking.  Repetition of the same move is the key.  The body learns in a different way than the mind.  In the software development world, it is useful to understand why things work, even when one is following practices.  Yet it sounds so cool (and we all want to be that martial artist who can whip the opposition – even better than being a cowboy who needs a gun).

In the Karate Kid, when Daniel is first learning Karate, he isn’t even aware that that’s what’s happening.  The Shu Ha Ri metaphor inadvertently implies that understanding underlying principles while learning is not important.  That we can learn by blindly following practices, being unaware of why those practices are good.  In Karate, it probably is helpful to not have the mind involved at this stage.  But in software development, even while in shu, it is very important to understand why the practices work.  People learn practices faster when they understand the principles underneath them.  The implication of Shu Ha Ri is “if you do this, things will work.”  The reality is quite different.

This metaphor seems to be most prevalent among Scrum coaches because in Scrum you are supposed to follow Scrum practices to uncover impediments that you are now supposed to remove in order to improve your methods.  If you don’t follow Scrum properly, you are doing “Scrum-but” and held up for disdain.  Ironically, moving from Shu to Ha should have you do Scrum but.  While this implies there is good “Scrum-but” and bad “Scrum-but” the Scrum community never describes what the good would be.  See my The Right Way to Do Scrum-But

This understanding not only speeds up learning, it speeds up the detection of impediments. Scrum promoters take great pride in that they can discover what these impediments are in 30 days – ignoring the reality that if one understood Lean, one could likely see most of one’s impediments in 30 minutes.

Virtually all models of learning have flaws, but I believe the Dreyfus Model of learning has some value.  It has people start at a novice level and move to advanced beginner, competence, proficiency and expert.  It does not imply the value of a lack of understanding at the beginning.

The challenge is that at the novice stage, people like to be told what to do.  They don’t want to start something new without some guidance.  But, as they move into advanced beginner and competency, they want a different kind of guidance.  This lack of guidance by Scrum thought leaders implies one never gets out of Shu or that merely following the practices one can, in fact, solve all of one’s problems. Either attitude is troubling.

However, there is more than stages of learning.  Chris Argyris’ double-looped learning, where we look to see if our approach is correct, is sadly missing in Scrum.  I’ll leave it to the reader to decide why so many of those promoting Scrum don’t discuss how you transcend it – either by practice or by deciding there is a better way.  However, this lack of how do we go beyond Scrum practices and even the Scrum approach, are clearly important questions that should be being asked.

If you've had an experience of being stuck in Shu and want to get out, please let me know. We're here to help.

Al Shalloway
CEO, Net Objectives


 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

I have enjoyed thinking through what this post is proposing but I'm not sure I totally agree with you. I do believe that in order for process improvement to happen, you need to understand not only the underlying principles of what you’re doing, but also what it is you’re trying to achieve through that process. My experience has been that depending on the maturity of the team, there may or may not be fertile ground for them to readily understand or accept Lean concepts. It’s also a matter of practicality. If half my team are people with no technical degree but who are able to test software, I need to be aware of their starting point. I feel Shu Ha Ri buys me some trust to teach those same concepts through the team’s experience. Just-in-time learning, if you will. Starting at Shu, I explain concepts as issues show up in the day-to-day work, and work to deepen the team’s understanding at the same time as they are noticing the benefits of a new process.

I have often struggled with Development teams who were ready to disband the Scrum process as soon as possible because they "know" better. Yet what they would naturally propose or tend to was the same "silo-ed", non-collaborative approach they have used for years. There was sometimes however, the exceptional team, who used the Agile concepts, was receptive to the principles, made them their own, and effectively evolved their process needing less and less of my help to do so. Either way, I think what Shu Ha Ri is helping us do is to teach either type of team through experience. Help them discover the principles through their work. I’m not sure why that is such a bad thing.

I would argue that whether you use Shu Ha Ri or start the team with a class on flow, the success is probably more dependent on where the team is in terms of maturity to try out these concepts objectively. For some people these concepts are truly alien, so the experience may be much more approachable than a class on the theory behind Agile. My experience is that most people really won't get it until they live it, and that’s when you can explain to them the concepts behind their experience.

When I’ve used Shu Ha Ri with a Scrum team, I never intended to minimize the importance of understanding the underlying principles. Totally the opposite! Once a team can "taste" what successful flow is all about, they are hungry for the deeper understanding of why and how this all works. That makes them more receptive to learning the underlying principles. That knowledge, together with the fact that they have seen the connection between the new process and an improvement in their goals, equips them to critically analyze and improve it.

While I respect the desire to take Scrum to the next level, my experience is that the next level happens after teams have internalized lean and made it their way of life. If we can help them get there because they trusted and lived the new process until they got it, with education happening along the way, I’d say we’ve done a very good thing.

Thanks for the thoughts. So many comments I'll intersperse mine with you.

You: My experience has been that depending on the maturity of the team, there may or may not be fertile ground for them to readily understand or accept Lean concepts.

Me: The most important lean concepts are systems thinking and delays cause waste.  I think anyone, regardless of technical background, can see these from their past experience.  Scrum is much more understandable when these two concepts are introduced.

You: I feel Shu Ha Ri buys me some trust to teach those same concepts through the team’s experience.

Me: I don't see how anything evers buys you trust except for helping folks and them seeing you are on their side.  I suggest you are taking the trust you have and using it in a less effective manner.

You: I have often struggled with Development teams who were ready to disband the Scrum process as soon as possible because they "know" better. Yet what they would naturally propose or tend to was the same "silo-ed", non-collaborative approach they have used for years. There was sometimes however, the exceptional team, who used the Agile concepts, was receptive to the principles, made them their own, and effectively evolved their process needing less and less of my help to do so.

Me: You are making my point here exactly.  The ones who understand principles do better - even in Shu.

You: Help them discover the principles through their work. I’m not sure why that is such a bad thing.

Me: It's not bad.  But it goes a lot faster if you tell them the principles and help them see how their practices are reflections of it.

You: For some people these concepts are truly alien, ...

Me: What concepts are alien?  I find that Lean concepts are quite understandable once pointed out.

You: My experience is that most people really won't get it until they live it,

Me: That's pretty much my experience as well.  No one gets anything until they do it.

You: and that’s when you can explain to them the concepts behind their experience.

Me: This is not Shu, btw. Shu would be to just give practices without telling them the concepts behind their experience.

You: When I’ve used Shu Ha Ri with a Scrum team,

Me: I suggest that if you teach the principles they will stick to them more to see if they can understand them - and will pick them up faster.

You: While I respect the desire to take Scrum to the next level, my experience is that the next level happens after teams have internalized lean and made it their way of life. If we can help them get there because they trusted and lived the new process until they got it, with education happening along the way, I’d say we’ve done a very good thing

Me: What can I say.  I am saying I have seen Scrum teams go at a certain pace without the understanding of Lean and I've seen teams with that understanding going much faster.   I haven't heard you say you've tried what I've been saying (I've done both ways).  Rather I hear you defending Shu.  Have you tried teaching principles and practices concurrently?

Hi Al,

I get it. You are correct that I have not tried your approach of teaching them Lean at the same time as they are learning the practices. That is a learning opportunity for me! I will work on that for a team I am currently coaching to see how that works out. Thank you so much for such a detailed response!

Regards,

Maridali

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban