Blog

I have been skimming the web lately to get a sense of how the agile community is approaching lean. From what I can see, and judging from my own lean journey, a typical agilist exploring lean will sooner or later arrive at the following conclusions:

This is the first danger zone. At this stage, it is all too easy to think that lean is just another flavor of agile, or that XP, Scrum or Crystal are perfect adaptations of lean to the world of software development.

Agreed, the differences are difficult to see because they both share a similar "look and feel" - a focus on the customer, on quality, speed, adaptability, continuous improvement and teamwork. What is so easy to overlook is that lean takes these general principles to a much more rigorous level. Kind of the same difference between a team that sometimes uses a few pseudo-automated tests where developers have to manually check the results, versus an agile team using a full test-driven development approach to build its application from the ground up.

For those that somehow feel that there's "something more" in lean, a second mistake is lurking in the dark. This one is about considering lean as a series of tools or mechanical properties: kanban, just-in-time, one-piece flow, work-in-process, levelling, VSM, andon, red bins, 5S, SMED... you name it. These tools and principles are indeed an important part of lean, but they are only manifestations of a few fundamental principles that you need to understand to make the whole system work.

I have come a long way in the past year, thanks to the teachings of my lean mentors, Marie-Pia Ignace and Michael Ballé. I have also learned a lot applying lean principles to a few IT projects outside of the software development world. The more I learn about lean, the more I realize that there's still an even longer way to go. However, I think that my understanding is clear enough now to start sharing a few ideas.

It looks like today the prevailing vision of lean in the software community is based on kanban, using work-in-process to reduce lead time, and the notion of "iterationless" development. The lean that I have been taught is rather focused on kaizen - helping people continuously solve problems, focusing on meeting customer expectations and using jidoka or just-in-time concepts as strategies for judging what constitutes a problem, and how to solve it. It is not necessarily opposed to the "kanban" vision - just a different way to look at lean, from a people perspective.

Here's how it looks.

The Lean Team

As a starting point, you can consider that a lean team looks pretty much like an agile team - frequent interactions with its customer, frequent deliveries, automated tests, use of "information radiators" in a war room, intensive teamwork... However, its exact set of practices is not necessarily aligned on a given agile methodology - it's rather the result of many trials and errors on the path of continuous improvement.

It thus looks like an agile team at first, but if you look a little closer you'll start noticing the following differences:

The lean team is focused on (really) satisfying its customer, but not only by providing the expected features or shipping early. The lean team acknowledges its customer's expectations in terms of development speed, quality, and cost, and it will work hard to meet these expectations through kaizen - the continuous improvement philosophy that is highlighted in the following points.

The lean team measures this performance. It constantly tracks delivery, quality, cost, and compares them to expected levels. This rigourous monitoring forms the basis of the team's continuous improvement efforts.

The lean team uses these measures to find the main problem areas, in very much the same way that you use a profiling tool to spot performance issues in a program. It then investigates the causes of these problems to come up with a clear understanding of the situation which will be a solid basis for developing a counter-measure. It also considers many alternative explanations, leaving no stone unturned in its quest to remove waste from its practices.

The lean team also uses every incident, every defect as an opportunity for improvement. Every incident is scrutinized, analyzed, and countermeasures are devised to make sure that the incident will never occur again. In other words, the lean team uses every incident to raise its performance level a bit.

The lean team makes all problems visible. The kanban board has been quickly adopted by the agile community as a way to highlight work-in-progress problems. The lean team uses visual management strategies wherever it can to highlight other kinds of problems.

The lean team uses the PDCA cycle for every improvement. Using the scientific method, it sees every improvement effort as an experiment. It makes sure the problem is well understood instead of rushing to a solution. It considers and explores various solutions before committing to one. It checks that this "solution", once implemented, actually yields the expected results in terms of performance. It reflects upon the outcome of every single experiment to learn something new about its domain.

The lean team follows up on these problems with the same rigor as it does for its operational tasks.

The lean team makes sure that organizational learning occurs by putting up a whole system of work standards. In a sense, these standards are the "program" that the team follows to do its job. Problems are fixed by improving this program.

The lean team trains newcomers to use the team's standards, so that the level of performance is preserved.

The lean team actively manages the development of its members, making sure that people always keep growing and that there are enough people able to perform a given task.

The lean team understands that you're never really lean. Lean is an unreachable goal, a state of perfection that you only work hard at attaining through a lifetime of kaizen. The journey is the destination, as they say.

Going further

As you may have noticed, this goes further than just using a kanban board. From what I understand, this is what you will need to actually get bottom line results instead of just implementing random solutions that lead to no bottom line result. And most important, this is what you will need to create an environment where team members always keep growing, following the path of continuous improvement.