How do you make Lean Practical ?

I was Oslo recently teaching a course on Lean Software Development. When we were organizing this course on of our goals was: Make it practical. As I was preparing the course material this was at the front of my mind. But, there is a but.

Step back a minute and have another look at my Agile Pyramid:



(By the way I’ve decided to start calling this the Agile Pyramid, I’ve sometimes called it this and sometimes called it the Agile Triangle. Well in the interests of consistency I’ve decided to stick with one, since Agile Triangle tends to be used to refer to project management type stuff Agile Pyramid wins. Besides, Google for Agile Pyramid and I’m on the first page.)

For practical things you look to the top: Scrum and XP are very practical, and prescriptive, Organisational Learning is more of an academic concept than a practical recipe. Lean sits between the two.

Also consider than many writers on Lean (take Like and Morgan for example) caution against seeing Lean as a toolkit you can dip into and select bits to use. They tend towards an “all or nothing” approach which needs change from the top down.

Most of the people I expected to have on the course were software engineers and architects looking to improve their processes and practices, not CEOs looking to reinvent their companies.

Nor do I think I’m unusual in having this problem. One of the reasons the course mandate was “Make it practical” was because some other Lean courses have a reputation for being less than practical.

So what do I do? How do you make something which is largely a philosophy practical?

One of my first decisions was to include Kanban software development. Kanban is a ready made, practical, Lean based approach to software development.

Next: you can’t have a Lean course without talking about Toyota, some of the things they do and some of the thinking behind the Lean approach. However, the objective here needs to be change the way people think about product development; or at least show that other approaches are possible.

The thing about Lean is that its not so much a toolkit of solutions (like Agile) but a systems thinking model to help you devise your own solutions and tools to tackle your own problems. So, having outlined the thinking behind Lean, and one example of how it is done in software I turned my attention to tools to help thinking. Things like: Value Streams and Value Stream Mapping, 5 Whys, Fishbone diagrams, A3 reports and reflection.

Two days was not enough, I might increase it to three next time, but then, you can never give too much time to Lean because to really understand it means doing it. Summarising it in a short course tends to remove the practicality.

One decision I made which might surprise some people was not to start from the Poppendieck’s books for the course. Yes I referenced them, yes I advised my students to read them but I used Morgan and Liker’s Toyota Product Development as a guide.

And since building a Lean organization really means building a Learning Organization my own Changing Software Development was the course book.

If your interested, it looks likely that the course will run again in Oslo in November.