The Dark Side of Lean
The Dark Side of Lean
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Let's start with a definition of Lean software development:
Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community. -- Wikipedia
Since translations are often prone to micunderstandings and lose information in the process, I've gone to the roots, and read The Toyota Way, a book written before the recession (in 2003) which explains how the Toyota Production System has lead the company to the first vehicle manufacturer in the world. Maybe also to recalling some millions of cars?
Kanban is a well-known buzzword in software development methodology. It describes a board or another visual signal that limits the work in progress (WIP) for each stage of production. In vehicle production, this minimize physical inventory that takes up space in the factory and may become obsolete.
In software development, these limits apply to features or tasks. So you can't have for example an unlimited number of stories which have been analyzed with the domain expert, or even developed in a branch, but not integrated or deployed. The logic is that the shorter the lead time, the earlier the customer start to feel the value of a user story; whereas, if you have 10 stories under development at the same time, you're slowing down each of them.
I've implemented a Kanban board with my team, before discovering it is actually something we should try to avoid and not aim for (or at least we should try to keep the WIP limits close to 1.)
The challenge is to develop a earning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer. Remember: the kanban is an organized system of inventory buffers and, according to Ohno, inventory is waste, whether it is in a push system or a pull system. So kanban is something you strive to get rid of, not to be proud of.
The real lean system is a one-piece flow, where each of the Kanban limits is set to exactly 1. Flow is better than kanban, which in turn is better than no inventory control. In software development, I think this corresponds to a cross-functional team tackling one story at the time.
Sustainable paceSustainable pace is one of eXtreme Programming principles.
Working overtime sucks the spirit and motivation out of your team. When your team becomes tired and demoralized they will get less work done, not more, no matter how many hours are worked. Becoming over worked today steals development progress from the future. You can't make realistic plans when your team does more work this month and less next month. Instead of pushing people to do more than humanly possible use a release planning meeting to change the project scope or timing. -- XP
Working overtime can happen, but it should not become an habit. The Toyota philosophy seems to prescribe respect for your workers and suppliers by challenging them. As a result it ignores pretty much this principle.
Here's an example from the Lean training of a supplier company, Matsushita:
There were also some concerns about Matsushita’s quality control discipline and if the level of quality required for this new, complex battery was too high for what Matsushita as used to. Fujii was reassured when he found a young Matsushita engineer one day looking pale. He learned he had been working until four in the morning to finish some battery tests. Yet he had come back in the next day to “make sure of just one thing” (Itazaki, 1999, p. 282).
If I had a team member working until 4 AM one day, the next one I would send him home before he could get a chance of touching any line of code. The chance he would screw up due to lack of sleep and focus is too high.
Here's instead an example from the Prius launch:
Toyota president Okuda was not an engineer, but he was an exceptional manager and leader who understood how to motivate people. As December was approaching, he anted to give the team a little push. The launch date for the Prius had been kept confidential and was known only inside the company. Conferring with Wada, they decided to make a public announcement in March. They knew that a public nnouncement would make it a matter of pride and social responsibility for Toyota’s ngineers to deliver on time. Okuda, in his speech to the press, stated:So much for the scope, time and budget triangle: this model of development does not fit very much into the Agile manifesto.
Toyota has developed a hybrid system that is an answer to the environmental problems of the 21st century. It achieves a fuel economy that is twice that of conventional cars of the ame class, emitting half as much CO2. We would like to launch this car within this year.
Uchiyamada described to me his reaction:
In August 1995 I asked for more than three years for development. Mr. Okuda said we hould launch at the end of 1997 and do your best. If it is impossible you can delay the aunching time. So I said OK. But in the beginning of 1997 it was already publicly announced by Mr. Okuda that Toyota would come up with a hybrid. We had climbed the ladder and the ladder was taken out from under us. We actually worked 24 hours a day (two shifts), changing the people.
Individuals and interactions over...
Processes and tools?
The Right Process Will Produce the Right Results. Toyota is a process-oriented company. They have learned through experience what processes work, beginning ith the ideal of one-piece flow, (see Chapter 8 for details). Flow is the key to chieving best quality at the lowest cost with high safety and morale. At Toyota this process focus is built into the company’s DNA, and managers believe in their earts that using the right process will lead to the results they desire.
This may work well in an assembly line where each worker inserts a pin in a vehicle part for 8 hours, but Toyota applied it also to product development.
Thus, before addressing the Toyota-inspired Lean practices with the keyword Agile, as intended in the Agile manifesto, we may want to stop a bit to reflect if the world of Toyota factories is the one we want in our team.
Opinions expressed by DZone contributors are their own.