Why it’s taken me years to explain simple things simply

Originally Published: 7/18/2007

Shu Ha Ri explains how we learn

I’ve often found the terms Shu, Ha, and Ri useful to refer to the three stages of learning Alistair Cockburn described in Agile Software Development. I’ll usually explain that to learn something we start at the Shu, or “following” level. Here we are focusing on learning a simple set of instructions for a technique and consider a particular learning experience successful if we can follow that set of instructions and realize success.

Later we’ll learn that simple techniques have limits, and we’ll learn to vary the technique or combine it with other techniques to achieve success – that is in the Ha or breaking away stage.

Finally I explain that many experts find themselves in the Ri stage – or fluency. There they freely improvise, mixing and matching techniques and inventing new techniques – tricks I’ve heard them called – because these invented techniques are tricks until we can explain them and teach them to others as somewhat repeatable techniques.

So, that’s where the complication comes in.

Shu Ha Ri doesn’t help us find those simple steps – it only lets us know we need them

I’m lucky enough to have learned quite a few things from a number of experts. I’m serious about that lucky part. Not everyone gets those opportunities to learn first hand as I have, so I consider myself very lucky. As a result of learning techniques from user-centered design experts, specialists in more traditional requirements work, and Agile experts, I’ve acquired an odd fusion of techniques swimming around in my head. Those, combined with my own unique perspective and experience, have resulted in the tricks that I feel pretty proud of.

Sadly, I have to call many of them tricks, and my tricks in particular, because I struggle to explain them. That is to say, I struggle to arrive at a step-by-step Shu process that I can explain simply, and that people can learn and repeat.

I’ve heard Alistair explain that once you reach fluency level – or Ri level, you sometimes forget how the simple Shu steps worked. But, for these tricks I’m talking about, there never were any Shu steps – at least I never learned any. Because they’re an odd blend of a number of techniques, and a few happy accidents in the context I was working in at the time. I never learned useful language to explain them. And, for the group I was collaborating with at the time, the improvisations seemed obvious. They didn’t need explanation either.

But, I’m happy to report some success.

Finding Shu steps that work takes years of trial and error, but eventually it pays off

I write this at 12:45am from the way-too-crowded waiting area in the Bangalore airport. I’ve just taught a 4-day class to a group of folks here in India – and happily it’s felt more successful than any I’ve taught prior. Nothing feels better than finally getting the language right, coupling that with some simple exercises, and seeing the people in that class really get it. I can see in their words, body language, and movements as they perform the techniques that they’ve gained more fluency more quickly than others that I’ve taught.

Actually, as I write this, I wonder if we should all remember that those in India doing IT work are pretty darn smart. If we want to stay competitive in the US, or wherever we live, we’ll have to do more than simply “be collocated” with the business.

But, back to my story.

For participants, learning a new technique is a deceptively small thing. An instructor explains something. You listen and it makes sense. You try out a technique in an exercise, and it works. What’s the big deal?

But, it’s taken me years – really four years now – to figure this out. I’ll need to write a public apology later to the people who endured some of my earliest classes starting in 2002. Very rough Shu at that time. I almost obfuscated techniques rather than clarifying them.

This time though, I saw my small class of nine pick up the necessity of understanding and modeling business goals. During exercises they poked each other with the “why stick” – to find the real business goal behind the simplistic “build some software” goal usually expressed in software development. Then, they used the goal-question-metric technique to identify meaningful measurements to detect business success.

Those business goals come in handy. Much of what I do is informed by user-centered design thinking and techniques. But, I’ve found that if you don’t balance user-centricity with business-centricity – or person-who-uses-it with person-who-pays-for-it – you don’t succeed in delivering the value you intend to. Well articulated business goals provide goal-alignment for stakeholders and spell out pretty simply to those on a software design and development project where the business value should come from. It seems to help the business people when you can remind them where they believe business value comes from. Software development is tough for everyone involved.

Many in the Agile software development world labor under the false assumption that working delivered software = business value. Actually business value generally comes from using software. Building and delivering it is simply cost until then.

If we know that the best way to get value from software is from using it, then it’s a good idea if we start focusing on users and use as soon as possible. I find my head a little thick at times. I finally really grok Larry Constantine and Lucy Lockwood’s reason for calling their design approach Usage-Centered Design – because it’s the usage (stupid) that earns us the value.

But I digress.

The group I worked with built user models – my neutral way of saying I don’t care if it is an actor, user role, profile, or persona – just figure out who’s using your software and why. Write it down and leverage it.

We moved through modeling use using user tasks and workflow models. They wrote clever user scenarios, and used them as a foundation to create software user interface using paper prototypes. They leveraged the task workflow model and experience from designing Ui to create an incremental release plan. One that delivers something at each release that users of the application can actually use to meet their goals – which of course is mandatory for business stakeholders to reach their business goals.

Honestly – if I hear “prioritize your user backlog by business value” one more time, I’ll scream. It just doesn’t work. It’s not that simple. Usage needs to be more explicitly taken into account. Although simple prioritization sounds like a set of Shu instructions, it isn’t – because the person practicing that approach needs to realize some success. I won’t rule out that this approach has been successful for some – but it just doesn’t work for me. That Shu just doesn’t fit.

I’ve gotten off topic again. I’ll get back to my original rant.

Arriving at Shu instructions for a new technique requires testing

My real point with all this is that identifying, describing, and teaching new techniques is tough. The toughest part, at least for me, has been finding language to explain them. To find that simple language I’ve had to start with a best effort, then try it out. I continue to adjust it until it seems to work. That’s been my process for getting back to Shu.

Shu-Ha-Ri is a useful metaphor for explaining how people learn. But I’ve started to realize that there’s a bit of a process to follow to get to Shu instructions – getting oneself into Shu business so to speak.

If English is your first language, or one you’re pretty strong at, you’ll get the “Shu business” pun. If you’re old enough to know who Ed Sullivan is, you’ll get it twice.

And, here’s the self-serving bits – as if blogs were’t self serving enough.

I’m happy to be teaching a first two-day public course for the Software Productivity Center on Agile Product Management on July 30th and 31st 2007. My goal with the course is to introduce the simple modeling, planning, and tactical Agile software development management approaches that I believe are best practice. It’s not called an Agile requirements class, or an Agile customer class, although you could think of it as both or either.

As I said above, value comes from using software, not just delivering it. Agile development approaches are great delivery mechanisms, the very best as far as I’m concerned. But, it’s the product – the thing we’re delivering that’s the most important. The SPC class focuses on figuring out what to build, and how to work with those who know how to build it. Assuming developers and others in Agile development know how to build software right, this class is about how to build the right software.

I’ve got upcoming half day-classes at Dr. Dobb’s Architecture and Design World, Agile 2007, SD Best Practices, and OOPSLA. If you’re attending any of these conferences, please come say Hi. If you’re willing to start an argument, I’ll pay for coffee while we talk. 😉

(If you want to start an argument and your name is Ron Jeffries, I give up. 😉 )

Upcoming teaching events: