Currently I am attending a BestBrains course with Mary and Tom Poppendieck on Lean Software Development (see more here).

On the course there are people from companies in UK, Germany and Denmark, it is an interesting combination of different views and experience.
Even though I read the two books from Poppendeick many years ago, it has been an inspiring day with many stories and cases from companies around the world.

We did two Value Stream Maps based on some real life cases from the participants, and the people presenting the results had a hard time when Mary started to ask a lot of “why”-questions. I am sure they got a lot of valuable things to work with at home.

Some of the take-away I got from the first day:

• Focus on bad news first: That makes the organization focus on constant improvements (Toyota does it).
• Copying Toyota is also copying someone else solutions to their problems and that is not solutions to your own problems. Lean from Toyota and improve it.
• To make real user value, you have to see and understand it from eyes of the customer/users.

Especially the last bullet is so important, and if you want to learn more in this area, I can recommend a BestBrains workshop at Øresund Agile on May 14th: “Capturing Requirements and Agile Planning“ http://oresundagile.org/workshop-7. It might change how you define your systems to be built in the future...

By Mads Troels Hansen

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

Have you ever thought about a good metaphor for software?

Up until today on some occasions I have explored the metaphor that software is a building, where architects build from standard components and when a new requirement to “the building” comes, we can alter parts of the building. This metaphor has never been compelling to me, so luckily, on a trip from “Toyota Commemorative Museum of Industry and Technology” to the Toyota Motomachi plant in Japan I found another: Software is a factory.

I needed to know more clearly, what software development is really trying to build, so what does it require to build a successful factory? Well Toyota certainly can provide a good deal of inspiration with their factories where the Toyota Production System takes place.

Generally speaking a factory supports processes which consists of input, an operation and output. One overall process of a car factory is input (parts for a car) and the operation of assembling the car which gives an output of a car. This process of course can be divided in subprocesses, also with input, an operation and output.
If software is a factory, it takes information as input, performs an operation producing information as output.

An important attribute of a Toyota factory is that it can support Jidoka: to detect an abnormality instantly, stop, fix and correct the immediate condition and install a countermeasure. This is how quality is built into what ever the factory is producing. Detecting an abnormality instantly in a software factory, is not the same as logging an exception, and waiting for someone to look at the log...

In this view we as software developers, in a broad sense, are factory builders. We supply our customer with an information factory that can process information. So what implications does this have?
What for example is software architecture? It is an act of planning factories - not a trivial task I believe.

I want to explore this metaphor and find out more about which methods are used to build factories, because I believe we can use this experience in software development.

By Jesper Thaning

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

At a retrospective meeting with a client not to long ago, a really interesting point came up. The client had deliberately attempted to push a lot of feature work onto the development team, while keeping a fixed deadline - presumably to have the team work harder, and thereby producing more features before a particular deadline. Interestingly quite the opposite happened.

A total of 7 features were requested by the customer, while neither deadline nor scope change could be tolerated. The result? 7 features were reported done on the deadline. Unfortuately it turned out - in production - that only 2 was working as supposed, meaning that 5 was more or less defective.

When these numbers were clear to everybody an obvious question came up. Could the team instead have aimed for a total of 4 features (instead of 7), and actually completed 4 features upon the deadline (instead of 2)? Significant amounts of time had been invested in 5 features that were not completed anyway.

Who were to blame for this? The development team were only doing their best, trying to accomplish a goal not set by themselves. How could the client know any better? They did not know the kind of problems that are induced by using a push approach.

What the client and the development team had experienced was simple physics.

Little's Law:
Work in process = Flow time * Throughput

Little's Law describes the relationship between multiple key variables in any value stream (including software development projects)

What Little's Law says, is that - The more work you start, the longer it will take you to finish (given that your capacity/throughput is stable). Now imagine what happens if the customer asks for a fixed deadline - The amount of work that can be done before that deadline is indicated by the current capacity.

How about if we attempt to get higher throughput/capacity by increasing the amount of work, and asking people to work harder. Which variable do you think will be affected? ..you guessed right, Flow time will increase, as throughput (or capacity) does not increase magically over night.

I wonder how many people in the software industry are trying to outrun Little's Law, by putting pressure on the "floor" workers (e.g. developers and testers) ?

Lesson learned?
1) Don't try to run above the speed limit indicated by your current capacity. You will pay more and get less.
2) Favor pull systems over push - for instance as advocated in Scrum.
3) Never attempt to fix scope if you have a fixed deadline.

By Sune Gynthersen

Back when I was studying at the Technical University of Denmark, I took a course named something like "Probability and Statistics for Engineers". Just the other day I came across the book which was used in the course - in my own bookshelf. I never paid much attention to the chapter of statistical quality control when I was reading it back in university. In fact, I'm not even sure I made it to that chapter.

For some reason I can't explain, I felt an urge to take a look in that particular book the other day, and in there I stumbled across quality guru Dr. Deming's 14 points for management. I wonder why this part of the book was totally overlooked in the course - considering how important I have later found them to be.

I've never had such experience with a book I've had for years on my bookshelf Have you?

By Sune Gynthersen