Sunday, March 9, 2014

Shu-Ha-Ri Applied

Shu-Ha-Ri  Applied

edited: 2014-03-10 - grammar issues

The Issue

Shu-Ha-Ri and the Dreyfus model are very helpful tools I have used to help understand the point of view of a person I am working with and guide me in how I coach them. I am seeing a use of these models that concerns me and appears to hurt our ability to change more than help. These models are quite helpful at the individual level for a specific skill. Shu-Ha-Ri seems to always be described, in its initial context, as a relationship between teacher and student. Applying it beyond that without potentially significant changes appears to be an abuse of the model.

I intend this article for experienced coaches, change agents and change organizations and think that other individuals and groups with a global, enterprise or other large scope will find benefit in thinking about this subject. This article is focused on when these models are applied to a software organization moving towards Agile and Lean.

More background

Articles, such as this one by Rachel Davies have implied the models are wrong to apply for forcing someone to do agile practices. I tend to agree with Rachel on this issue and would like to expand on where I see the problem. The biggest issue I seen is when applied in a larger scope of people, team or organization, they seem to be misleading and guide us to treat knowledgeable people as overall beginners. The danger here should be obvious, smart people treated as beginners will be put off at best and likely fight against us.

Interestingly, when I read Alistair Cockburn's article, where he introduced Shu-Ha-Ri, he applied this to training courses. These can be targeted at individuals at a specific level. Books and articles as well can easily target and let people know who the intended audience is. Many people have no problem reading beginner material or attending a introduction class to start understanding a new skill or topic. These are all targeted usages of the models that allow the individual to choose to be a part of.

Jeff Sutherland also uses shu-ha-ri in guiding Scrum implementations. Notice that this is also a shu targeted at the Scrum Master. In the shu state, the ScrumMaster sets up the process, helps the team get to a sustainable pace with known velocity and uses the
Retrospective to introduce change that improves velocity. I disagree with the velocity target but I will use it as an example goal. In this description the scrum master is looking at the team, though the article seems to mix abstraction levels between Scrum Master level and team level. Sutherland could have said the Scrum Master doesn't allow them to vary the process but he does not. He does not say the Scrum Master tells the team to do practice X. Instead the Scrum Master guides towards achieving goal Y via retrospection. He might recommend a practice to help achieve goal Y if the whole team cannot identify a possible practice to improve the current situation but the Scrum Master does not dictate the practice.

Looking for guidance in helping an organization change

I think Sutherland starts to imply a difference in applying the shu-ha-ri idea in a larger context beyond the individual, we target goals and outcomes to a less mature group and guide them towards that. This is not the same as you do exactly the one practice taught by the teacher. I believe it is a bit more than simply a goal. I like the way Don Reinertsen states a similar idea, "decentralized control with decision rules". See the video LSSC12 : Decentralizing Control: How Aligned Initiative Conquers … 

Based on my experience organizations fight back against the absolute one way given by a enterprise or global level group. They often do so with the right intention. The group fighting back knows their context and see weaknesses in the one practice for beginners. Having the organization work at the shu level as a directive is where we lose supporters. We are not talking about people new to software development, shu in Aikido is someone completely new. It is a rare circumstance that we are talking about people that have not delivered software in the past. Agile and Lean are not the goals or at least should not be. They are mechanisms to help us think about the situation and see it more clearly. If we are guiding a team or organization we should be guiding them towards the goal. Let's assume for example, in the rest of this post, that the goal is delivering value more often to our customers and other stakeholders.

What does team level maturity look like 

I think I have jumped a bit far ahead and assumed we are ok with the idea that there are no shu level teams and organizations where the teacher gives them the one rule, way or practice to follow. So let's back up and look at what is implied by a team or organization being shu level at their primary tasks.

If the shu fits we are in big trouble

Maybe a shu level team is one that all members are at the shu level. Can they be at the shu level for their primary tasks of delivering software? Maybe, but this would be for such a short stage that by the time someone is invited in to help they have already left the shu state. If they stay at this state for any time at all they will no longer exist because the organization, product or team would fail in a way to bring a drastic change to the team or it would cease to exist. This seems like such a bad state to be in that it would be rare and could not last long. We really should not assume all teams are at this level and dictating the one way is not likely to fix this team. The team has to be changed in a more drastic way.

This state does not match my experiences. I have seen a team that really could not deliver but the organization caught this mistake relatively quickly and fixed the problem. I say team but it was an organizational problem where people were hiding the real state to protect themselves and it failed relatively quickly. In this state, they also did not ask for help. It was not until they had failed and realized the problem that they asked for help. They also realized most of their issues and it was clear they were not a shu team. When they admitted the failure the true level of people who were being silenced by the system came out and they new how to fix their issues with very minimal encouragement and guidance.

Maybe a shu level team is a team where all team members are at the shu level for a specific new practice. Would that make them a shu level team? Meaning, a team which we treat as beginners because they do not know a practice we believe would make them more effective. I am thinking of practices like TDD and Uncle Bob's idea of a foreman. My experience matches more with Jason Gorman's. It just will not work to impose these practices. In my experience teams will meet any metric you impose to verify it and will actually make themselves even less effective. If we want to call them a shu level team we will have very little success. I am proposing they are not a shu level team. They are likely far from a Ri level team but they are not shu. They have some experience and success at delivering software and we do damage by treating them as beginners. They are likely shu at TDD and they likely need to be challenged to improve their capability to deliver. In my opinion, this is different than being a shu level team.

Maybe a shu level team is a team with so few ri/ha team members that they cannot successfully guide the shu level members and keep them from doing more harm than good. This seems more likely than the first example of all shu level members. This team actually has an advantage and solves the problem faster than the mythical all shu members team above. The few ri/ha team members make this visible quickly out of fear of their own failure if nothing else. I have seen this team get the problem fixed relatively quickly.

For me the real issue is having a shu level team or organization is never what we need to solve. That shu level team or organization gets eaten alive by the market, internal or external, or they fix the beginner problem so quickly that we would never be asked to come in and help. If you think your organization is at the shu level ask a few questions about it. Do people know where they, the team or organization, is not very effective, at least in some areas? So far I have not seen any organization where people could not answer this question to some degree. Enough people to know that change was necessary at a minimum. All of these organizations are currently delivering software. I would put them at the compotent state in the Dreyfus model at least. They need and benefit from someone looking at what they are doing and reminding them of the goals. The need and benefit from someone pointing them to solutions they have not tried and influencing them to think about them. The need and benefit from someone guiding them in practices they do not have experience implementing. They usually need to choose those practices based on the goal discussion first. 

At this point I may not have convinced you that shu level organizations and teams are not who we are asked to work with. If I have not convinced you; then please keep testing to see if the one way is causing more good than bad and is change truly sticking. 


If I have at least convinced you that it is possible there are no important shu level teams and organizations, or at least you are not working with or for one, let's continue. Ri level organizations and teams are probably very rare and frankly unimportant. If you are competing against one you will not likely be in business long, unless of course you have the cash to buy them in which case you probably should. So let's not even worry about that.

Most of teams and organizations are at the ha level or Competent level. These are the ones that see the need for improvement. They likely have asked you to help them by using Scrum, Kanban, Lean, XP or some other change to make the more effective. Likely, they have even asked you to teach the one true way. There are ha level organizations it seems to me. Interestingly, they often even state in contradiction to their request to you, to teach
the one way and be consistent across all teams in the organization, that they do not want be prescriptive. What would lead them to say this? Maybe it is the fact that they see multiple activities and in many cases teams and groups with a poor vision of the goals behaving in a way that they want to put structure on. They often see that being prescriptive is not likely to work and yet they ask for it anyway. They have not seen how to achieve similar goals in different ways while dealing with conflicts between groups that deliver together. These are ha level teams and organizations that need to be aligned to a goal before any of these ways will make sense.  Once they have that, then they can be guided to practices and may even be willing to try a practice they are at a shu level to see if it helps.

We, as coaches and change agents, need to help them understand the goal and make that clear from top to bottom. Once we do that we can help them see with some minimal guidelines where they could improve to meet the goal. They will also see when they have a goal that is different and start pushing back on the system that is giving conflicting goals. Interestingly, until they see this conflict teams and organizations do not push back openly in a way that can get the conflict resolved. It is usually not politically safe to do so. They push back in a politically safe way that continues towards their conflicting goal while meeting a metric, in number but not value, that is meant to show direction towards a goal they are not trying to achieve.

When we start treating people like they are successful and knowledgeable, by asking their input on how to achieve the goal, we will find a better way to achieve these goals. We will often be asked how can that be done and give us the opportunity to introduce a new practice that helps them. They are more likely to be open to the new idea sooner if they have asked for help achieving the goal. They are more likely to spend the effort it takes to learn the practice than simply fake the metric. They are even likely to help choose a metric that helps them determine if they are getting better. The first XP team I worked on was this way. We had the opportunity to try something and we started seeking ways to do it even better. We learned metrics that helped guide us. We started to understand weaknesses and strengths of our own metrics. Teams that were forced to do the XP practices did not get the same benefits. Their builds were often broken, their test coverage went up in unimportant areas but met the targets. 

Most organizations will not allow Uncle Bob's foreman to control the code, it would have appeared significantly slower. They are still a ha level organization hiring more and more developers to fix a problem more developers will make worse. However, it probably would require a foreman to check everything in this forced 'treat the team as shu level' environment. Treating the team and organization as though they are a ha level team and they will start to see the trusts and reciprocate by helping the organization see the problems and find practices that help improve them.

Summing it up

When a team or organization has experience at their primary tasks it is wrong and dangerous to treat them as beginners. It is wrong because they are not. They need some time to choose the practice that moves them closer to a goal and learn that practice they are beginner at. They also need to see the goal in the bigger context. 

I really doubt you are working with or for a shu level organization or team. Is it possible, that we as change agents and organizations, due to our own level of HAness, are treating teams and organizations as if they are shu when they are not? Should we make sure we
are not teaching the one way because it is easier than dealing with people and helping them understand the goal? I know I need to think about this more often based on my past mistakes.

As always, I am seeking your feedback more than agreement. Please leave your comments and help me improve.