The agile community is full of drive and new ideas. This is what I’ve liked for the last 10 years ever since I joined it. However, it may happen that the community enthusiasm makes me uncomfortable. In all fairness, I no longer share its hunger for new concepts to keep the community buzzing with novelties and shining new toys.
One of the target domains of new concept mass-production for the Agile community during the last few years has been Lean. Lean Start-up, Lean UX, Lean Analytics, Lean BtoB, Lean Kanban (probably the most confusing of all), Lean YouNameIt – not to mention SAFe framework that proudly displays the Lean flashy sticker on its top left corner.
This enthusiasm has had interesting consequences. First, it has allowed to put Lean in the spotlight as people were seeking alternative modes of management allowing to navigate the complexity of the 21st century business world. Second, it has also proved instrumental in introducing Lean to a new generation of professionals – including this blog main contributor.
Self-proclaimed senseis
Another consequence, more questionable, has been the advent of a new breed of self-proclaimed “lean experts” or, even worst, – Taiichi forbid – self-proclaimed “senseis“. I know alleged senseis who actively support the agile psychoanalytic trend, who are keen on the blame game, who rather jump to solution (“hey why don’t you do TDD?”) rather than try to understand the root cause, or who have never been to the shop floor to fully understand what has happened: they are just an embarrassment for the whole community.
I remember the endless music discussions I had with my friends, as a teenager, deciding whether this band was playing jazz or not. This was just some passionate but fruitless taxonomy semantic. There is something else at stake here: we want to challenge this Agile Leanwashing to make sure some opportunists joining the bandwagon do not tarnish Lean hard won virtuous reputation, the same way 6 Sigma may have done at some point. It is also very easy to turn a lean initiative into some control-freak productivist approach, a risk you don’t want to ignore.
A sixty years old system of Management
Lean is a discipline that has existed for the last sixty years or so. It has slowly but surely unfolded into a system of management and leadership with astonishing results. This is a system obsessional with the confrontation to the most brutal reality; a system whose virtue is embodied by a relentless challenge of mental models; a system that is much more focused on facts, practices, humility, and respect for people than to shiny new concepts.
In Lean culture, a professional becomes an expert after ten or fifteen years of daily practice.Strangely enough, making a talk in an Agile conference or writing a blog post on the topic does not make you (or me) a sensei. The aim of this blog post is to sort the wheat of the chaff in order to shed a clear light on what Lean is and what it is not. The idea is to help people buying these types of services so they know what to expect.
Ask the expert
In order to achieve this, I have asked a genuine sensei : double Shingo prize winner Michael Ballé, co-author of one of the most important business book of 2014 : Lead With Respect a book about Lean deployment at a software vendor house.
Michael – why is it so important to understand as to whether our initiative is Lean or not ?
Good question. Why do we do lean? We aim to align customer satisfaction, employee engagement and commercial success. So far so good. But lean is not just any which way of doing so. It’s a definite method born out of decades of experience. Unfortunately, many people will do anything they can think of to apply tools but avoid aligning with the principles of lean.
Lean is about sustaining sales by satisfying customers in delivering on time good quality products at a reasonable price. Quality and productivity are achieved by moving testing closer to value added work and stopping at every defect and solving problems rather than live with the unnecessary costs of dealing with defective work.
Overall costs are reduced by seeing that “capacity = work + waste” and eliminating waste through pulling work: more frequent deliveries and always smaller batches, in order to achieve better quality and higher productivity with greater variety. Built-in quality and Just-in-time create the overall framework of lean. All the activities that drive the lean system on a daily basis are about involving every one every day everywhere in problem-based learning of standards and in encouraging initiatives through continuous improvement or kaizen, which requires a specific form of management and leading with respect.
How would you benchmark an initiative to find out if it is aligned within the Lean principles?
As you mentioned, lean is not a free-for-all. It’s a definite discipline with well-established principles and specific tools. It is also a system – one can’t ignore the left-hand site legs of a table and expect it to stand. The various aspects are interconnected and work together to one single purpose: encouraging every one to think deeply about their customers, their work and learn-by-doing. If any of the 10 following statement is not true, chances are your “lean” is not, well, lean:
- Team aims to improve the customer experience by solving all claims
- Leaders, Managers and team go on the shop floor to understand the facts where and when they happen
- Teams visualize the projects objectives
- Managers listen to the obstacles faced by each and everyone in the team
- Team has a Kanban practice to visualize immediate priorities for everyone
- People are trained, on the work place, everyday
- PDCA is taught, to make everyone more autonomous in the daily work – problems are tackled and solved every day
- Cross-team/departments activities are carried out to develop team work throughout the organization
- Frontline workers initiatives are supported by managers who observe directly what happen and by teams learning from the improvements
- Mutual trust is developed while helping teams succeed and while recognizing their efforts.
Now about the coach: how can you check as to whether your alleged Lean coaches actually are real ones ?
Top of my head, here are ten additional questions you can ask yourself. Again if any of the following is not true, chances are this is not a Lean coach.
- Do they have someone to coach them, a proper sensei ?
- Are they interested in the product performance for the customers ?
- Do they understand ROCE ?
- Do they make the link between Jidoka and productivity ?
- Do they make the link between just-in-time and resources shifting? Are they obsessional about leveling?
- Can they show the potential in every day’s work? Can they compute the takt time on day one?
- Do they master different forms of visual management, the tools and their goal?
- Are they able to assess strength and weaknesses of teams, products and processes?
- Are they searching for the right balance between pushing and supporting people?
- Are they able to give practical exercises to develop people rather than doing, for the people?
Thank you Michael – It’s now up to everyone to make sure they actually are on a lean journey with a proper coach and not on something different, that still may be helpful and working, but that is not aligned with the principles of lean.
#hypertextual 
Cute typo here, Cecil .. especially if you are a Lean consultant.
“”As you mentioned, lean is not a fee-for-all.””
Hi Jon thanks for spotting it ! Fixed.
Hi Michael and Cecil,
I can respond regarding “Lean Kanban”. Lean Kanban supports a management method (the Kanban Method) specific to knowledge work — IT, legal, education, military, HR, marketing, and others that don’t “build widgets”. The core difference between “Lean Kanban” and methods such as LEI’s “Lean IT” is that we recognize that in knowledge work, focusing on waste elimination and reduction of variability breaks down. The Gemba Walk also breaks down. We have a different approach because a different approach is needed for knowledge work. We don’t abandon those concepts but we go a different direction than the Lean Manufacturing field of knowledge.
So why do we associate Lean Kanban with Lean at all? Everything we do is based on Lean principles. This is especially important when we are dealing with the Agile community, who claims Agile was based on Lean all along, (speaking of Leanwashing) and yet they don’t seem to attend to the Lean values such as you describe, “focus on facts, practices, humility, and respect for people”. We completely support those values, most often referring to the work of W Edwards Deming.
Concepts such as limiting work in progress and continuous improvement with evolutionary change are core to what we do. We teach a pull system, flow, and data-driven decisions. Our community also is widely informed about Lean concepts and anyone not familiar with Lean will quickly become confused by our more in-depth conversations.
We do not study with Lean senseis and I don’t know anyone in our community who calls themselves a sensei. However, the reason we formalized the Kanban Method as a set of principles and practices was because the approach to kanban for knowledge work was being thrown around by people who did NOT have Lean values and did not have any real understanding of Lean concepts. They would slap a visual management system on a wall and call it Kanban. We do encourage people to learn kanban for knowledge work from our accredited kanban trainers who have been deeply vetted. I think that is a similar intent to “learning from a sensei”.
By the way, I totally understand the confusion coming from the Lean community because even “kanban” has an established meaning in manufacturing and that has evolved into something very different that is in the Kanban Method. Kanban is a model to facilitate the pulling of new work when capacity is available, within a WIP limited system. This is still our core concept but we have extended this to cover handling multiple commitment points, risk analysis, probabilistic forecasting, and many other dimensions enterprise wide.
You can learn more about what we do at our global events and workshops, and at local Limited WIP Society meetup groups.
Janice Linden-Reed, CEO, Lean Kanban, Inc.
Hi Janice,
Many thanks for your long reply. I am still not very comfortable with it though.
You “recognize that in knowledge work, focusing on waste elimination and reduction of variability breaks down” how do you know ? I have tons of example where it does not. Not to mention Gemba walks which has proved
critical in projects I have managed.
A second point I’m not comfortable with is the claim that LEI “Lean IT” is not related to knowledge work. In all fairness, I tend to hear this as if you were saying that there is the old dusty LEI lean IT on one hand and then yours which is young, sexy and agile. I think there is one definition of lean which is Toyota’s system. This does not only work for manufacturing and production but also for enginering work – would you rate this as Knowledge Work ? Prius was developed from scratch in 18 months if I may remind you. The major problem I’ve seen with Kanban projects is that it makes many problems visible (which is good) but does not provide the right tools to tackle them in a, errm, lean way, while developing people.
But the thing that makes me the more uncomfortable is that reducing waste and variability are one of the core ideas behind the creation of Pull Flow and Kanban by Taiichi Ohno. How can you do everything “based on Lean principles” if you just remove these two from the pictures. As if you were pretending being a vegetarian except for beef and veals.
I am sorrry but I’m a bit confused with your position.
Hi Cecil,
Yours being confused may be the result of yours not aware of what Kanban Method is?
As Janice mentioned you could attend one of our conferences or better off read a book such as “Kanban from the Inside” http://www.amazon.com/Kanban-Inside-Understand-connect-introduce/dp/0985305193
Why reducing the variability in new product development is not always economically beneficial I would refer you to Don Reinertsen’s work especially “The Principles of Product Development Flow” http://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009/
Your claim “The major problem I’ve seen with Kanban projects is that it makes many problems visible (which is good) but does not provide the right tools to tackle them in a, errm, lean way, while developing people.” implies you could list “the right tools” that are rejected by the Kanban Method. Can you please elaborate on that?
Hi Dimitar,
I know what Kanban Method is and I’ve been using it a few times. Read Kniberg’s and Anderson books there no room for a third one sorry.
I see Don Reinertsen as a math teacher much more than a lean expert. I hardly ever hear about developing people in his talks. Again that might be interesting and providing good result but this is not lean. My turn to suggest you Toyota Product Development by Jeffrey Liker.
The Kanban projects I did or I saw never used PDCA for problem solving. What I saw is they harvest the low hanging fruits of reducing WIP and pull flow. Continuous improvement was not structured. Again : this is not lean either.
Besides : where are managers in Kanban Method ? And Lean without Gemba walks is just something in the vincinity of teams self-organizing : they fully miss the point which is enterprise alignment on clear vision and objective.
The difference between a method and an global enterprise management system.
Hi Cecil,
Since you read Anderson’s book then you can easily find on p. 193 that “Kanban supports at least three continuous improvement methods:….Waste Reduction, Variability management (as well as SPC and the system of profound knowledge”. Also check the famous Microsoft XIT case study on reducing waste with Kanban on p. 29 in the section “Estimation was a waste”.
Your remark of Don Reinertsen being a math teacher is something most of us will not agree with…
But I would like to focus on your remark “The Kanban projects I did or I saw never used PDCA for problem solving.” (Disclaimer – I published “Out of the crisis” and “The new economy” in Bulgarian language. )
Can you please elaborate why you did not use PDCA on your own Kanban projects?
Dimitar
Sorry but I haven’t learnt Anderson book by heart. Anyway are we tackle waste reduction and variability in Kanban or not ? I’m confused again.
My hypothesis : we don’t use PDCA while doing Kanban because it’s on the periphery of the approach if ever mentionned. Regardless if you translated Deming books in Bulgarian or not – which, seriously, is a great achievement.
Now on Reinertsen. I am sorry but these are maths demonstration : http://fr.slideshare.net/AGILEMinds/don-reinertsen-is-it-time-to-rethink-deming
http://www.lean-kanban.eu/program/slides/ Aren’t these maths ?
But it’s OK. Note that while saying this I’m not showing disrepect to M. Reinersten work : I’m just saying that his topic is math, queuing theory etc … It is not respect for people, continuous improvement, customer satisfaction and strategic alignement. This is different from Lean.
One last thing about Gemba Walks : the core belief of Mr Ohno, was that our misconceptions are the source of waste : he designed Kanban for 1. operators to be able to manage and streamline their work and 2. make waste visible. Together with Kanban Gemba Walks (observing facts – the famous Ohno circle) and PDCA are the parts of the whole system tackling these misconceptions. Data points (what Mr Reinertsen focusses on) are good but it’s not all there is in Lean.
You forgot to answer my question: Can you please elaborate on why you did not use PDCA on your own Kanban projects?
Dimitar, I’m sure that ‘s not what you are aiming at but I’m afraid your insisting tone makes the whole thing feel like an interrogation, or worst, an exam, rather than a conversation.
My understanding of a conversation is that it is a 2 way exchange : each person asks question and provides answer.
I am sorry English is not my native language and some subtle semantic differences in the way sometimes I write may sound rude.
Let me ask it in a different way – can you please share what prescription made in the Kanban method did not allow you to use PDCA on your own projects?
Do you think traditional Lean principles and exact practices are 100% applicable in software development? Changes from mass production to lean worked like a chart for tangible products, but can we be so certain that it will work for software dev.?
I see this situation as attempts to apply Lean from manufacturing to soft. dev. and this leads to experiments, new methods and new names. Is it bad? I don’t think so. Terminology chaos is inevitable at this stage.
Hi Cecil,
I’m not sure how you got from my comment, “We don’t abandon those concepts but we go a different direction than the Lean Manufacturing field of knowledge.” that we DO abandon variability and waste elimination. You also say that we “just remove these two from the picture”. Untrue. Again we do NOT abandon those ideas but we handle them in a different way. For example, we focus more heavily on reducing delay (delay as waste) and how to do demand shaping in knowledge work, rather than trying to force a traditional definition of waste where it does not make sense.
I’m not interested in getting in a big debate about what is Lean and what isn’t. My intent was only to clarify why we associate ourselves with Lean at all and also how we consider our community to be different from the Lean Manufacturing community. I would never tell someone to embrace Lean Kanban if they want traditional Lean. We integrate a variety of influences and management methods. Certainly we focus on being data driven but we are also very attentive to the needs and satisfaction of people in organizations. Our commitment is to delivering value.
Hi Michael, thanks for your comment.
I find it a bit surprising that you guys, Lean Kanban experts, reduce Lean to a sole manufacturing approach. Manufacturing is important in the Lean curriculum but again, the Toyota Product Development and Lean Engineering are massive areas of Lean.
I think you guys are making what Ohno would call a misconception : “Old fashion Lean does not work as is in 21st century software development”. Well, I’m afraid it does, and I would strongly recommend you to serioulsy investigate the topic before making such claims. You can ask our customers.
“Badly naming things is adding to the world misery” (Brice Parain but attributed to Albert Camus). You don’t want to add to the world misery do you ? I don’t. So I won’t resignate myself to terminology chaos, as long as this chaos bring Lean along. We are talking here about Agile Leanwashing indeed, which was the aim of this post.
Please note that I am not saying that these approaches are bad or that they do not work or that they don’t bring value. Actually I’m pretty sure they do. But please show respect to the decades long of acquired wisdom for this management system and don’t put the Lean sticker on it.
Can you enlighten me with few success cases of Lean (in your terms) in “software product development” (since I still think that traditional product development and software PD are different things)? I’d be grateful to learn them!
Hi Cecil, It’s a great post. Makes me think about what are the points I need to improve to get better as Coach. I used to have a sensei, but he retired (looking for an other)… And I agree with the key need for a Sensei. it’s critical to have a True Sensei that can open mind and show the gaps by making you think about an issue.
Thanks for sharing it!
Thanks Andrea for this insightful feedback.