What is Shu Ha Ri?

There are times when we try to communicate an idea to someone and we struggle to do so. My dad is a mechanic, so when he tries to explain the inner workings of a combustion engine to me, I'm lost. When I try to explain to him how software is built, he's lost. We have to recognize that as an expert on a certain domain, you can't talk to others as if they are too. This is where the concept of Shu Ha Ri comes into play. (For a more formal description of Shu Ha Ri, check out Martin Fowler's description.)

Shu Ha Ri is borrowed from martial arts. It defines 3 levels of learning-

Shu - Imitation. You do something by copying someone else. You don't question it. The teacher gives you a prescriptive solution to a problem that covers most of your needs. It may not be the most efficient or best solution, but it is simple to learn and covers most of the situations you encounter.

Ha - Understanding. You start to see the reason behind what the teacher taught you. You modify it to still fit the core philosophy, but streamline it for you. You also start to see that the solution doesn't solve every problem and therefore seek your teacher for new ideas and solutions, or you might even seek other teachers for solutions.

Ri - Mastery. You take everything you learn and apply it at will. You solve problems by blending solutions without even thinking. When someone asks what you just did is called, there is no name because you adapted a new solution on the fly. It just worked in that situation. Your own experiences outweigh your formal teachings.

(Literally translated: Shu-> Following | Ha-> Breaking Away | Ri-> Fluency -Cockburn 2007)

Important notes-

• a Shu level person can not teach. They are not prepared to guide a peer in the journey of making mistakes and adapting.
• a Ha level person benefits from multiple sources of teaching.
• a Ri level person thinks in a language that the Shu level person can't understand since it is not prescriptive.

Why is this important? When you are having trouble explaining a concept, it's worth taking a moment to understand the gap of knowledge and experience between the two of you. You might realize that you are speaking at a Ri level when the listener is seeking a Shu level answer. They don't want philosophy or meaning, they want an answer for their immediate solution. There is also the reverse of this... don't talk down to someone who already knows the concepts and needs help blending them together.

Finally, don't teach above your level. Masters learn from their students, but students posing as masters can be dangerous.

The problem with having a Ri understanding of any topic is that you don't realize it. You don't know why they aren't getting it because it is so obvious to you. Stop and remember how you got to this point and strive to help them down that journey also.

Don't mulch your backlog...

Jeff Patton tells a great story about his work with Gary at Mimi. It's a discussion about the typical approach to flattening product backlogs and how this is destructive to understanding the larger picture. Favorite section:

"We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details - the pieces of functionality we'd like to build. In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations."

"After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree."

"That's what a flat backlog is to me. A bag of context-free mulch."

I need that context in order for me to really tell a story about the system.

He goes on to discuss the problem further and also the approaches to solving the problem. Very good post. I'm adding it here for my own reference and in hope it helps you too.

How do I know if I'm Agile?

There are a lot of discussions around Agile and the minimal requirements. I agree that there are many in the industry slapping the agile name on their process because of the positive association. Of course, this only leads to the dilution of the term's value.

There are also many who are pushing back on this and taking too strict of a tone and painting a black and white line. To them, you are either in or out. Of course, these are the same people who will acknowledge it takes months for a team or organization to grow into agile... it's not an overnight transition.

Taking that into account, I typically look at it through one of these lenses:

• The organization is not agile, and does not care to be
• The organization is interested in agile, but does not know enough to pursue it yet
• The organization is going agile without knowing it due to internal coaches who dare not utter the word "agile" for fear of ruining the current momentum
  
• The organization is striving towards agile intentionally, but can not call itself agile yet because it has too many areas to still work on.
  
• The organization thinks it is agile, but this is limited to what it knows
• The organization is a leading example of agile, but now the burden is on them to keep pushing the envelope
• The organization states they are agile, but are lying.

Note how the last bullet accounts for the groups who jump right in without taking the journey down the path.

I've seen tests for agile before, like this nokia test for agility. But personally, if you are just trying to get a simple start to it, I prefer using Cockburn's Crystal test. My group has shifted points 1-6 to a positive position, and now needs to work heavily on #7 before saying we are almost agile.

The Platinum Rule...

If you know me personally, you know that there are a few specific agile leaders that have made a stronger impression on me than others. One of those is Alistair Cockburn. I believe he is slightly under-promoted in the community. People who know his work understand its value, but many people don't know about him or his Crystal concepts. He's a great presenter and he covers great ideas.

Just the other day I was going through my old agile notes to revive any dormant concepts I'd forgotten. One of those gems was Alistair's platinum or Adamantine Rule:

The Golden Rule is self-centric – it instructs us to impose our value system on other people and expect them to be happy that we are treating them well in our value system!

Instead, using ... the Adamantine Rule, the subtext instructs us to
learn the other person’s value system, and treat them well in their value system!

He expands on this slightly on his bliki.

Sprint Zero...

Many of us eventually learn about the sprint zero concept in Scrum. It arrives when a team is experienced in agile, but is starting something new and realizes that the end of the first sprint probably doesn't warrant a demonstrable / releasable product. There are a lot of ideas on this and it's not really that mind-bending of an idea, it's just one of those topics that you don't learn when sitting in the Agile 101 classroom.

I simply view sprint zero as an adjustment of who the customer really is. Instead of thinking of your end users, it might be managers in the company that haven't approved the project charter or budget yet.

If you are thinking about how to approach sprint zero when you need seed money or sponsorship of some form, then your first sprint should focus on how to spend the initial funding (or getting it).

If you are earlier in the process and working through a formal relationship with a customer that requires an RFP, this can be a different set of challenges. Peter Stevens talks through his personal experience on the topic of writing agile into an RFP.

Update: Peter Stevens continued on this RFP series and has links to all the pieces here.

The train game...

To follow up on a previous post about agile coaching games... today, Infoq posted an article about the session run by these guys at Agile 2008.

I'm happy to announce that a game I recently created and tried successfully in my own company was submitted and accepted by Don McGreal and Michael McCullough into the Tasty Cupcakes wiki.

If you would like to try the Train Game and have questions, feel free to contact me. I'd like to polish it up a bit and improve it based on other people's experiences since I have only run it once.

Update (10/27/2008) - another good post on agile coaching games.

How do testers fit into agile?

I'm a strong believer they must be part of the team.

If you have a testing organization within your company, then before agile was implemented you were probably used to pitching "completed" work over the wall and crossing your fingers. Then there was a period of quiet before the wave of bugs came flowing back over the wall.

Going agile is about decreasing the distance between these two points drastically. Actually, TDD (test driven development) is about removing that distance completely. With this philosophy, it is important for a team going through an agile transition to deal with this issue. Instead of the test team relationship being "us and them", you have to find a way to fold the test resources directly into your team. Resources should be slightly more dedicated and must participate in planning and sprint review. Even if they don't aid in prioritization, planning, and design, their presense in the room insures that testing is built into the DONE criteria for sprint work and the timelines are realistic. Their insight can catch issues early, especially those surrounding performance or mis-use of the system. They get a view of what is coming down the pipe so that they can get ahead of the curve and stop being behind the eight ball.

My best experiences with testers on a scrum team occurred when they attended the daily scrum. Also, if they sat with the team throughout the day, they could mentor the team on their unit and acceptance tests to insure the basic logic and validation was covered. They spent more of their time catching the "really hard to find" bugs. They could modify performance and load testing scripts before the work was complete so that system tests could be run almost immediately instead of always being a sprint behind.

The sooner you embrace non-developers into your agile team, the sooner you see these types of benefits. These same points would hold true for usability, user interface, or business analysts.

If you want to know more about testing in agile, I just read a great post by rfleming on whether testing is about uncovering defects or changes. It triggered me to write this because I like his points and they are insightful, but I believe the issue he discusses can be reduced if you strive towards the points I raise here.