Roots of Lean 2010 is taking place next week. This week we are in Tokyo to prepare the trip, get over the jetlag and inhale a little japanese culture. Yesterday we went to a Sumo Stable to see the wrestlers train in the morning. My respect for Sumo Wrestling is now in a completely different place than it was before. To see the combination of strength, speed, tactics and flexibility in these big guys was impressive.





The serious stuff:

Every year we spend plenty of time to create a tour where we will se many different companies and get new angles to what lean really is about. The two last years, it was part of the program to meet with managers from Toyota, besides seeing the plant,  in order to  ask questions and dive deeper into what we had seen. Last year we were  lucky to meet Mr. Ishii - General Project Manager for Toyotas Software Division.  We had two very intense hours with him, where he openly shared how Toyota develops software, and what challenges they have. Recently Henrik Kniberg, from Crisp wrote this interesting account of that meeting.

This year we are not going to talk to managers from Toyota. They are too busy with other stuff - Instead we are going to meet a truckload of other fascinating companies and people. Starting Monday wíth a visit to the Leading manufacturer of Industrial Robots - Fanuc at the foot of Mount Fujii.

Stay tuned on this channel next week to read more.

By Bent Jensen

Kanban is the japanese word for signalling card, but a signal for what? In the 1950s a Japanese delegation including Sakichi Toyoda (founder of Toyota) and Taiichi Ohno (on of the masterminds behind the Toyota Production System) went to
the United States to observe how Ford was mass producing cars. They were not impressed. During a stop at an american supermarket they witnessed how items were automatically resupplied once sold. The beauty of this concept was its ability to ensure a sufficient number of items was available to customers, without having to bind too much cash in unneeded inventory.

Reading the InfoQ newsletter the other day, I found that "Kanban is the hottest buzz since the dawn of XP" (eXtreme Programming). It is really so? Kanban is great for limiting queues of items with a certain level of uniformity - but does software requirements fit that? We certainly have queues of work that needs to be controlled - and requirements certainly can be described in a somewhat uniform way. The question really is - before implementing a kanban system to limit work-in-process, do you know for a fact that this is your biggest issue? I look forward to see kanban systems implemented in software development organizations where highly varying task size, complexity and context is addressed effectively.

By Sune Gynthersen

After visiting DaiNippon we went to Azzuri to see how they were doing agile development. They were using the term Work Cell (from Lean Manufactoring) for organizing developers in small teams. I think it would require further investigation before I would make any conclusions on the Work Cell idea. The desks that were used had been handpicked to facilitate pair programming - How? The table legs were positioned so workers could move easily to the nearby workstations!


Later we went to Kenji Hiranabe's company Eiwa System Management, Inc. and talked with the employees on how they were developing software. I encountered the term Iki-Iki (translated to Alive), which I concluded was an initiative for fostering employee satisfaction.

After the visit to Eiwa we were all invited to a meeting with the Agile Japan group - where we participated in a panel discussion focusing on how we viewed agile software development, and how widespread the agile approach was in Europe and the United States. One of the things I noticed was how fixed scope software contracts seemed alarmingly common - not only in Japan.

As with last years meeting with XPJUG we ended the evening with a nice dinner and informal talk with the members of Agile Japan. I got to pratice both my japanese and my ability to sit in a cross-legged position (auch!)

I feel certain that we have started building a long-term friendship with the Japanese agile community - and I very much hope to get a chance to see some of these guys again later this year at the Agile 2009 conference.
By Sune Gynthersen

On day 3 we had not scheduled any visits, so I took of the day off buying some presents in Akihabara part of Tokyo (a.k.a. Electric City). In the afternoon I met with some of the participants at a Big Echo Karaoke-hotel. Who would have thought "We are the world" sung in a Tokyo basement could sound so beautiful?

Day 4 we visited DaiNippon Printing Ltd. At the factory tour of DaiNippon we saw how millions of japanese anime cartoons were printed, but most remarkably we saw how widespread the culture of using visual management in factories are. We had barely entered the factory, when I counted 13 * 3 meters of visuals on a wall. What to look for during maintenance with big pictures of how well-maintained equipment should look, defect statistics, and a lot of stuff I japanese (whích I can't read) that looked important. All of which helped employees do a better job.

By Sune Gynthersen

Yesterday was a really long day, and I have to admit I was to tired to write a blog entry. So here is the field report from day 2 of our Lean study tour. To be completely honest with you - I felt incredibly privileged about what I experienced in Nagoya yesterday. First we visted Toyota Commemorative Museum of Industry and Technology and the Motomachi plant like Jesper mentioned in his earlier blog entry - I would definitely recommend both to anyone visiting Japan.

After the plant tour we met Mr. Satoshi Ishii who is a project general manager at the BR Automotive Software Engineering Dept. within Toyota. In short, these guys are doing all sorts of software that is embedded in modern Toyota/Lexus cars. Satoshi Ishii explained to us that a modern Lexus (Toyota's luxury brand) contains 70 or more ECUs (electronic control units) which all needs software (brakes, engine, fuel injection, navigation, adaptive cruise control, etc.) along with the ability to communicate with each other.

Before the meeting I was a little skeptical - Were the Toyota culture so strong that it had found its way into the relatively new field of software development? What might surprise some, was that they were using a waterfall model (in Ishii-san's own words - in reality I think it was more like the spiral model). In spite of that, I had a feeling afterwards that I had just talked to perhaps the most skilled software development managers I have ever met! Does that sound like a paradox? I do not think so.

Let me explain it this way. I once said to myself that I did not want to waste my time as a developer on non-agile projects. In the Toyota case, I would certainly make an exception. Why? Because I believe that the principles that this company is built upon is of far greater importance than any of the agile pratices that we spent so much time on in the Western world.

After meeting Mr. Ishii, I had a talk with Mary Poppendieck (who is also with us on this study tour) and she believed that this was actually the first time a Toyota manager in software development has ever spoken publicly about how they apply their (Lean) philosophy in this field - I almost had the goose bumps

Trust me... I will write more about the all the learnings of this meeting - but now it is time for preparing a presentation for the Agile Japan group tomorrow.

By Sune Gynthersen

Today was the first official day of our Lean study tour "Roots of Lean 2009" in Japan. We started out this day by visiting Fujitsu Applications Ltd. in Tokyo. President and CEO Jun Watanabe gave us an introduction to how Fujitsu Applications had implemented Toyota Production System/Lean in their software development business.

Two things stuck me in particular.
1) Their use of standardized work (well-defined processes for how, when, and what to do). In the Fujitsu case I believe this was one of the major contributors to the productivity improvement they had experienced. Throughput had gone up by a factor of 7 - over a period of 6 years - without hiring more people!!
    
2) Changing the method of software developmet to a very manufacturing-like way had certainly improved productivity, compared to what they did before their TPS transformation. However I asked myself: They are paying salary to 300 employees - are they really utilizing the talent that they are paying for? I got the impression that maybe they were focusing a bit too much on Point Kaizen rather than System Kaizen.

Also we met Tomoya Saito who gave a talk on how Fujitsu Applications were crunching data from employee timesheets and measurements of progress in a way I have never seen before. What they were trying, was to do really fast estimation on a large scale. They were doing this using statistical theory and a high volume of historical data. I did initially feel slightly skeptical about it, but it has surely given me something to think about!

By Sune Gynthersen

Last week I attended an Agile conference in Copenhagen. Among the speakers were David J. Anderson, who did a session on kanban systems. He told the audience the story of the kanban system used in the Imperial Palace in Tokyo, Japan. The Imperial Palace, is really like a big park with various buildings inside. I was in the park with my colleagues during our Japan 2008 Lean study tour last spring, and I remember being impressed with the kanban system used in the park, as a simple and truly elegant solution.

When you enter the park, which can be done at several different locations, you receive a little plastic brick. When you leave the park, you hand it back to the lady in uniform at the exit. My first thought was, that it was used to ensure that everyone got out before night. Interestingly that same answer came up at the conference when David Anderson asked the audience what they thought it was used for.

However, imagine a single plastic brick is missing when the park closes. Did someone loose their brick, or are they still inside the park? Should resources be spent on going through the park looking for them? With thousands of daily visitors, bricks will be lost probably on a daily basis, so it's not a way to ensure everyone gets out.

Instead it is a way to limit the number of concurrent visitors in the park. The number of bricks is limited to the highest number of concurrent visitors accepted. That means that the entrance booth may run out of bricks, and then stop letting more people into the park. They can start letting more people in when they get some of the bricks left at the exit. If a brick is lost? No big deal - that just lower the maximum number of concurrent visitors by one.

The concept is exactly what is also used in Lean manufacturing to control the amount of work-in-process. And of course it can also be used in software development environments to limit work to current capacity.

If you should ever go to Tokyo, I would highly recommend going to the park. It is quite beautiful.

By Sune Gynthersen