Danilo Sato

My last session report on the series will be about the second half of the double session I attended on Friday afternoon, which was much more informative and funny. Kenji showed (with live translation) a 30 minutes japanese video about how a former Toyota leader conducted a plant transformation at a Sanyo cellphone factory in Japan.

It started with the successor of Taichi Ohno walking around the production line, followed by a bunch of people, and pointing out a lot of visible waste: unfinished products, piles of partially finished packages, and part-empty boxes. It really demonstrates the Toyota’s practice of Genchi Genbutsu, or “go and see for yourself”. By showing to the plant workers the visible wastes, he even claimed not having seen so much waste in a while :-)

His first approach to transform the plant was to physically reduce the production line size. He arrived on the next day and started to rip out the conveyor belt. The plant manager ran scared to the scene to see what was going on and was asked to get a stair and remove one of the signs hanging from the ceiling that read “Packaging Area”. The idea was to make the size of the production line smaller, so that people would have less space between then. That would require less people: the ones still working would have to do the job of more than one person, and the others could be moved to another department (such as product development).

As you would expect, the changes introduced some temporary chaos into the work place. Not everyone was happy with doing more than one job and the plant manager was worried they wouldn’t make their deadlines. After a heated discussion, he decided to go back to the old layout. However, he allowed that one of the workers participated in another improvement experiment: she would have to work alone in a work cell (yatai), doing the job who was previously performed by 6 or 7 people in the old production line.

At first, the time she took to assemble the cell phone was 2 minutes slower than the production line takt time. However, as she became more proficient, she started to suggest kaizen improvements, such as: raising the table and moving the pieces around to be closer to the place where they would be needed. Within 5 days, she managed to beat the productivity of the production line. The improvement was celebrated by the company’s leaders in an internal event, and she claimed that she felt that she could still improve and become faster.

My mains lessons from watching the video and seeing a lean transformation in practice were:

• Any change introduces a temporary period of chaos, which may cause the process to be reverted before the benefits are realized. Read more about the subject searching for Virginia Satir‘s work.
• Respect for People is clearly shown in the video, as the transformation leader stands besides the worker to support her while she is learning the new skills.
• The differences between Western and Eastern cultures: even though she was unhappy at first with the fact that she would have to do the job of 6 people, she respectfully acknowledged the new job and gave her best. It’s also clear that the Japanese have a more holistic view: companies collaborate with each other to improve the country’s industry as a whole. One of the “incentives” raised by the transformation leader was that if the quality of their products didn’t improve, their jobs would move to China.

This is the end of my Agile 2008 session reports. I hope it proves to be helpful for those who couldn’t attend the conference. Feel free to contact me or leave comments if you want to take these discussions further.

I attended this session on Friday morning. This time the subject was another Lean tool: kanban. Corey Ladas showed 3 different project scenarios and presented different approaches to implement a kanban system.

He started by talking about some important Lean concepts like one-piece flow, work-in-process (WIP), cycle time, and their relationship using a Cumulative Flow Diagram (or finger chart). He showed how a constraint in the system can cause disruptions to flow and cause more harm than benefit to downstream processes by building more and more inventory (WIP). He then went on to explain the benefits of using a kanban system to limit the amount of WIP in the different scenarios.

The first scenario was a traditional waterfall-style process. He used a value stream map to identify the amount of value-producing time in each phase of the process, and used that to calculate an initial buffer size for each kanban lane. Instead of trying to explain the whole idea here, I suggest you to read Corey’s series of 4 posts on the subject.

The second scenario was a transition from a Scrum process into using a structured kanban instead of a traditional story/task board. Again, the approach is explained in more detail in a post about what he called Scrum-ban.

The third scenario would be an improvement over an existing kanban process, but due the number of questions throughout the presentation (which generated some quite interesting discussions) he didn’t have enough time to go into more detail.

My overall impression of the session was that he did a good job explaining kanban as a tool, and the reasoning behind it to limit WIP and control the flow of your process. The discussions and questions were also very interesting, which demonstrated the audience was interested in the subject. The thing that I didn’t like so much was his argument in favor of having specialists in the team, and how to move into using kanban without too much change along the way. I think one of the fundamental Lean principles is kaizen, or continuous improvement, and it encourages the team to constantly search for better alternatives. Change is part of the process and should be seen as a Good Thing. And I have already shared some of my impressions about Generalist vs. Specialists, so I’m a bit biased :-)

An important thing to keep in mind is that kanban is just one of the tools in our Lean toolkit. I particularly like Kenji Hiranabe’s InfoQ article on the subject, where he explains kanban in a more broad context, acting as a balancing tool between reducing WIP and one-piece flow, as well as a way to visualize kaizen. Lean is full of contradictions, and you must understand the underlying principles to be able to apply (and change) the practices to a particular situation. Using kanban per-se shouldn’t be a goal for any agile team, but it is very important to understand how it works and the reasoning behind it. If you haven’t looked into kanban yet, you should definitely check out the references in this post.