DanNorth.net

A discussion unfolded recently on an internal mailing list that tied together two of my favourite topics, namely learning theory and Lean.

Someone was asking how they might apply Lean to setting up and running a new project. A number of people made suggestions, all of which were the kind of good common sense I would expect from my ThoughtWorks peers, but what particularly struck me was the way the answers exemplified the different stages of the Dreyfus Model of Skills Acquisition. (The link is to an interview with pragmatic programmer Andy Hunt, whose forthcoming book Pragmatic Thinking and Learning contains an excellent chapter on it).

The Dreyfus Model of Skills Acquisition

As well as providing a useful description of each stage of learning, the Dreyfus model describes how best to help the learner progress to the next stage in their learning.

According to the Dreyfus model there are five distinct stages, as the learner gains experience and develops insight and intuition. Very briefly:

The Novice wants recipes, best practices, quick wins
The Advanced Beginner wants guidelines, a safe environment to make mistakes
At the Competent stage you want goals, freedom to execute
The Proficient learner wants maxims, war stories, metaphors
The Expert wants philosophies, discussions and arguments with other experts(!)

So back to the mailing list discussion, here’s what I saw in amongst a number of responses. (I’m paraphrasing and summarising for effect.)

Novice: I like the sound of Lean and I want to apply it to my next project. Where should I start?
...
Competent: Here’s my cheat sheet of Lean practices and behaviours.
...
Expert: Lean isn’t a process, it’s a philosophy.

Perfect!

So why such a wide spread of different answers? The problem is that when it is applied to software delivery, Lean is a metaphor, which means it’s too abstract for a novice to “just use” without making it situationally specific, and too concrete for an expert to articulate easily. For example, the Lean concept of inventory applies in a number of subtle ways to software delivery.

It is worth mentioning that the Dreyfus model is about describing the acquisition of a specific skill – in this case applying Lean theory to software delivery – and not a general categorisation of an individual. For instance the author of the reply from which I took the “competent” fragment above is an accomplished agile coach and developer, so be careful not to take the Dreyfus descriptions out of context. (But you wouldn’t do that, would you? I meant the others.)

Getting started with Lean

So then I thought, what would be the most useful advice to an experienced Agile team lead to get started? To kick a project off in a Lean way, I would suggest the following:

1. Get everyone immersed in some Lean theory. Use workshops with lots of interactive exercises. Be aware they are at the novice stage so they will find rules and recipes – and quick wins – more useful than context at this stage, even if the specifics aren’t strictly correct. “It depends” is never helpful here. Ship in your local Lean expert – Richard Durnall or David Anderson in my case – and steal some collateral from the intertubes. Share with the team that you’re new to this too – it will make them less afraid.

2. Think about how Lean applies to software delivery. For instance, there are three “flavours” of Lean, namely Manufacturing, Supply and Product Design. Although they all focus on minimising waste, they also have specific targets in mind.

• Lean Manufacturing is about minimising variance (you want all the cars to come out the same). This is analogous to build, deployment and running automated test suites. The same code should always produce the same deployable artefacts. Test runs should be idempotent (rerunnable with the same results).
• Lean Supply is about minimising inventory. This is analogous to deferring decisions, doing enough up-front analysis and design but no more (and certainly not none, otherwise you starve your supply). Have a nominal backlog of features but don’t bother planning out 3 months of detailed Master Story List (that term should never have made it out of the gate). Carry out exploratory testing soon after the feature is code complete, when it’s still fresh in the developers’ heads.
• Lean Product Design is about maximising discovery. Everything is an experiment, and if you don’t learn anything it wasn’t useful. This is analogous to writing software, understanding and articulating requirements, user experience workshops, designing effective tests, identifying corner cases. Foster an environment where it’s ok – in fact encouraged – to try new stuff “just in case”, or run two or three ideas in parallel to see which one fits best. That isn’t waste, it’s a good discovery habit that you can position as due diligence. Read up on innovation techniques and creating an innovative working environment. Your programmers aren’t building cars – they’re designing cars. Let them. Make it fun.

  As a example of mis-applying the metaphor, methodologies like six sigma mistake innovation (discovery) for waste (variance) so they squeeze the innovation right out of the process. (They call innovation, sorry variance, “defects” – cute.)

  3. Break down your process into swimlane steps. It doesn’t matter whether it’s right (it won’t be) or whether it fully describes your process (it won’t). What matters is that people are thinking in terms of moving something from an idea to signed off, deployed code (“from concept to cash” as Mary Poppendieck describes it). Use simple index cards to represent work on a big visible wallchart. Moving a card across swimlanes is a small win. People like frequent small wins.

  4. Keep track of where the cards back up. This is a clue to bottlenecks. It may not be that the backlog itself is the problem – it’s just a starting point for your investigation. Apply a systems thinking approach – what could be causing that? What else?

  5. (once you’re getting the hang of it) Apply Lean thinking to your process itself. That’s one of the cool things about Lean. It’s not just about getting work done – it’s about getting better at getting work done. This is when you start looking at your process and identifying the actual value stream as opposed to “the stuff you do”. Are there activities that are just there because “we always do that”? Are there things you spend time on that are so “obvious” you didn’t bother capturing them as their own swimlane?

  There’s a ton of literature out there about Lean – and some of it is quite good – and a small-but-growing body of Lean practitioners within the software industry. We can’t actually clone Richard Durnall, but we can learn from him. As long as we choose to believe we’re always learning, we should be in pretty good shape.

  ps. Another quote from the Lean expert on that email thread – Richard again – was that there aren’t Agile projects or Lean projects, “there are just projects”. This reminded me of a famous Bruce Lee quote. “Before I studied the art, a punch to me was just like a punch, a kick just like a kick. After I learned the art, a punch was no longer a punch, a kick no longer a kick. Now that I’ve understood the art, a punch is just like a punch, a kick just like a kick.”

So it’s that time of year again. I’ve got a number of conferences and workshops coming up, ranging over all sorts of topics. I just popped over to Martin Fowler’s site (I’m doing a talk with him this week) and noticed that he has a much more organised setup than me. All his events are in a sidebar and there is a handy link if you want more details. Another idea to go on my to-do pile.

ThoughtWorks Quarterly Technology Briefing

• Manchester – 12 September 2007

• London – 20 September 2007

  This is the second instalment in ThoughtWorks series of informal sessions aimed at technologists across the spectrum. Although calling it a technology briefing is a bit inaccurate because the title for this one is “How to Sell Agile to your Organisation”, which has far more to do with the themes of people, risk and change than with anything technological.

  This is the talk I’ll be presenting with Martin so I can guarantee a lively session. In his own words: “As I detest selling anything to anyone it will be interesting to see how this talk works out.”

  Details and registration info are on the ThoughtWorks website.

  RailsConf Europe

• Berlin – 17-19 September 2007

  A lot of Ruby folk seem to have taken to behaviour-driven development. This is almost entirely due to the success of the rspec project, which is in turn due to the enthusiasm and dedication of its developers and the community they have established.

  A while back I wrote a story-level BDD framework for Ruby called rbehave which has since been integrated into the rspec project.

  I’ll be helping rspec project leads David Chelimsky and Aslak Hellesoy present a workshop entitled A half-day of behaviour-driven development on Rails, where we’ll be demonstrating how rspec helps you write software that is focused on achieving an outcome. It’s at 8:30am on the Monday morning, so make sure you’re there first thing.

  Expo-C Roadshow

• Växjö – 15-16 October 2007

• Karlskrona – 17-18 October 2007

  Expo-C is one of my favourite events. It’s a small conference in south-east Sweden and it seems to attract an audience that really cares about what they are doing. I’ve done two of them now, on very different topics, and on both occasions I was very impressed with the quality of the attendees and the calibre of the other speakers. (I’m usually the only one there who hasn’t written a book.)

  This time they are doing two mini-conferences back to back, in Växjö and then Karlskrona, with a tutorial day and a seminar day (six sessions) in each location. I’ll be running full-day tutorials on BDD in Växjö, and Coaching, Communication and Change in Karlskrona. For the seminar I’ll be talking about bridging the communication gap, based on a keynote I gave with Martin Fowler at QCon earlier this year.

  I will also be learning how to pronounce “Växjö”.

  OOPSLA

• Montreal – 21-25 October 2007

  This will be my first OOPSLA. I’ve heard a lot about it and I’m a bit intimidated. By reputation it seems a bit more “cerebral” than most conferences. It will also be the first time I’ve ever presented JBehave at a conference. No mean feat considering I started writing it at the end of 2003! There’s perpetual beta for you.

  My co-presenter is my ThoughtWorks colleague, friend and cybergoth Liz Keogh, the person responsible for getting JBehave to 1.0. I have huge respect for Liz; she manages to combine software with poetry. This isn’t a pretentious metaphor – she actually does combine software with poetry. She ran a haiku workshop at a previous ThoughtWorks away day that many of the attendees nominated as the highlight of their day. She also writes inspiring and inspired blog articles.

  I’m only going because I want to see what Liz does when she’s let loose on a roomful of developers. I reckon we’ll end up writing haiku acceptance criteria.

  And some others…

  There are another couple of events in the pipeline that I will blog about nearer the time (January and February next year). After that I’m going to have a bit of a lie down.

  Correction: I got the dates wrong for OOPSLA. Thanks Joshua Graham for putting me straight.
  Another correction: My Swedish geography is appalling. Thanks Morgan Persson.

I was going to write about the various ways that people learn, and then my colleague Jeremy Stell-Smith wrote an excellent article describing one of my favourite learning models, so go and read that and I’ll see you back here shortly. Jeremy also alludes to Shu-Ha-Ri, another learning model based on repeating “cycles” of learning, found in Japanese martial arts (I haven’t linked to a single definition because there are a few subtly different ones around).

Ok, so why are learning models useful? To quote Edward de Bono, we should teach our children to learn. In other words, Learning should be on the school syllabus alongside all the regular subjects. I would go further and make it a core subject of every school year. There’s plenty of material about learning, memory and concentration to fill the lessons. But here’s the good bit: it would be an exponentially useful subject.

To start with, teachers would have to learn the syllabus material. As they were learning they would apply what they were learning to become better learners. At the same time as they were learning about learning, they would become intrinsically better teachers, because they would understand more about their role as facilitators to learning. Then they get into the classroom (or outside in a park, because they have learned the importance of physical environment to learning) and provide an exciting, engaging, varied and responsive introduction to learning.

But now it really gets exciting, because as the kids learn the techniques and principles of learning, they become more accomplished and voracious learners, and they understand the dynamics of how they are being taught. And not just in their Learning class, but in History, Geography and all the other subjects where we have traditionally learned and regurgitated reams of dull information by rote. They will have a vocabulary and an awareness about learning so they can communicate how they want to be taught. And their education becomes exciting and useful.

I spend quite a lot of my time teaching, whether in the form of coaching, workshops, conference tutorials (some poor Swedes had an entire day of me recently), internal training within ThoughtWorks, or on-site with a client, and I really enjoy it! I love creating an environment that encourages people to learn, and I love seeing the lightbulbs go on.

I’m lucky – I’ve had some amazing teachers and mentors, whether in school, my brief martial arts career or work – which has led me to invest in understanding the dynamics of teaching and learning, communication and rapport, feedback and change (particularly cultural or organisational change). Systems Thinking is another useful avenue to explore.

Studying how learning and communication works has definitely made me a better teacher. I’m still an enthusiastic amateur – I would never describe myself as an “expert” teacher, simply because there is still so much out there that I don’t know, and because I keep encountering people with different and inspiring teaching styles. I don’t believe it is an area you can ever fully “know”.

The best advice I can offer to anyone who finds themselves in a teaching role is this: learn to learn before you learn to teach. If your last experience of learning was History-by-numbers at school, then unfortunately that’s probably how you will end up teaching, and that would be a shame.