Learning to Lean

6 mins
, , , ,

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 Karl Scotland 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 (re-runnable 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 misapplying 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.”