Tag Archives: toyota

Nytt matigt kapitel till Riv pyramiderna igen

Posted on by

På ett bräde blev boken Riv pyramiderna igen dubbelt så tjock (222 sidor) med det nya kapitlet “En organisation utan huvud – en agil odyssé“. I den gör vi en historisk, praktiskt och teoretisk resa från apache-indianerna, över Ford, Toyota, Lean, Scrum, Agile, flödeseffektivitet, Hegel, Kant, hur det påverkade oss och mycket mer. Slutstation:en massiv förfyttning av makt till den agila organismen – teamen. Här är underrubrikerna:

  • När Sloan slängde ut Drucker och barnen med badvattnet
  • Kunden i centrum – från Österike till Japan
  • En agil kunskapsteori
  • Scrum – Toyota för programmerare
  • Kontinuerlig förbättring – kunskapen finns på golvet
  • Kult av kvalitet – människan i maskinen
  • Stoppa bandet – och bygg in kvaliteten
  • Vid behov – skapa drag
  • Ibland är det bättre att gå hem – eller vad är flödeseffektivitet?
  • Jobba i lag – ta bort alla köer
  • Motivation – Purpose, Autonomy, Mastery och så lite umgänge
  • Scrum och flödeseffektivitet
  • Kanban i mjukvaruutveckling – utveckla din egen process
  • Rätt sak, på rätt, sätt regelbundet – en agil formel
  • Gro en smidig kultur – med fraser
  • Lägg till lite kaos för innovation
  • Hypertextorganisationen – centralt skelett, distribuerad hjärna

Köp den nu, den blir aldrig billigare

Stop the line as eBook

Posted on by

Here’s the eBook collecting my articles on building the quality in by stoping the line: Stop The Line – Why it’s crucial to include a human touch to your automated processes

Where is that Red ‘Stop’ Button in Your Development Process?

Posted on by

If you don’t dare to stop the line, continuous integration might be waste. Here is the second part of my three-part series on building the quality in on the SmartBear blog.

In the first post of this series, I wrote about Toyoda Sakichi, the founder of the Toyota industries, who invented a loom that would automatically stop when a thread broke in the 1920. He thereby also invented the concept of “stop-the-line” to build quality in.

Incremental compile with visual feedback is a small step toward the automaticity of the Sakichi loom. Beyond that, we still have these longish feedback cycles, be it manually running unit tests or waiting on the automatic build or system tests run by our continuous integration (CI) system.

Read the rest of the blog at SmartBear.

Stop the Line – Build Quality In with Incremental Compilation

Posted on by

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

It may seem old school, but every now and then I’ll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don’t do this as often as I used to.

Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.

Read the rest of the blog at SmartBear.

Establishing the continuous improvement culture the incorrect way

Posted on by

Continuous improvement is a central part of both agile and lean; it’s the way to increase the productivity and ensure that the organization delivers an ever increasing level of value to the customers and the organization. Lean is derived from Toyota and the Toyota Way, which has inspired a lot of companies in the western world in their quest to increase their productivity as well. But we often focuse on the techniques and practices and do not see the more fundamental parts of the Toyota system that enable their very high level of improvement each year.

I worked at a company that tried to implement the Toyota Way and reach the same level of continuous improvment with what I believe to be the wrong focus. My company estblished a goal to reach seven improvements per employee in average per year. A goal that was inspired from a report that stated that Toyota implemented 1,000,000 improvements per year, which of course, is very high. This is one of many aspects that show why Toyota has managed to grow they way they have done during the last 50 years.

read more »

Toyota’s journey from Waterfall to Lean software development

Posted on by

Toyota’s journey from Waterfall to Lean software development

Guess what. Toyota uses the waterfall method for software development – and now they’re trying to figure out how to go Lean.

Surprised? So was I!

My lean study tour to Japan in April 2009

One of the core tenets of Lean Thinking is Genchi Genbutsu – go and see for yourself. After years of experimenting with how to apply Lean principles in software development I decided to apply Genchi Genbutsu and go the source – visit Toyota and find out how they do it.

Despite all the books and articles written on Toyota Production System and Lean Thinking, very little has been published about their product development process and just about nothing about how they do software development.

So In april 2009 I was part of a small group that went on a “lean study tour” to Japan to visit Toyota and other companies in the Lean & Agile space. The group included several colleagues from Crisp, Tom and Mary Poppendieck, consultants from Best Brains in Denmark, and other mostly Scandinavian lean enthusiasts. I grew up in Japan so it was extra fun to visit the country again, this time wearing “lean glasses”.

We learned many interesting things, for example we met Katayama-san (chief engineer of several luxury and sports car models) and learned about Toyota’s product development process. But in this article I’m going to focus on the biggest surprise – how Toyota develops software.

Meet Satoshi Ishii, manager of automative sofware engineering dept.

We had the great honour of meeting Satoshi Ishii, manager of the embedded software division – i.e. the software that goes into the cars. His English was rather halting and I didn’t take detailed notes, so some of the quotes and conversations below are paraphrased.

First surprise was when he opened up by saying “I think you know more about Lean software development than we do”, and after that it just got more and more interesting.

All in all it I was impressed by Ishii-san and his presentation. He started with Toyota’s goal and vision (“we aim at the realization of sustainable mobility society”), then went into how software development plays into this, then described the problems they are having today and their strategy for solving them. We realized afterward that his presentation (and in fact all presentations we saw at Toyota) pretty followed the A3 problem solving format, confirming that this approach is deeply engrained in the Toyota culture.

Why Toyota needs to become an IT company

Toyota builds cars (duh). In the past that didn’t involve much software, and the little software that was needed was mostly developed by suppliers and embedded in isolated components. Toyota assembled them and didn’t much care about the software inside. But “The importance of automatic electronic control system has been increasing dramatically year by year” said Ishii-san.

 A modern car is pretty much a computer on wheels! In a hybrid car about half of the development cost is software, it contains millions of lines of code as all the different subsystems have to integrate with each other.  He mentioned that a Lexus contains 14 million lines of code, comparable to banking and airplane software systems.

Ishi-san concluded that “Therefore Toyota needs to become an IT company”.

Toyota’s current development process: Waterfall

Imagine our surprise when he pulled up this picture:



It was all there. The big V. Architects that don’t code. Distinct phases – all requirements to be complete and signed off before before coding, all code complete before testing, etc. He even called it a waterfall method.

We asked if he was happy with this way of developing. The answer was No. He told us about all kinds of problems they are having, most of them familiar to anyone that has experienced waterfall-style software development. There are countless case studies illustrating why the waterfall process just isn’t appropriate for software development. Even the original paper on the waterfall model in 1970 (”Managing the development of large software projects” by Dr Winston Royce) says “the implementation described above is risky and invites failure”.

Toyota is moving towards lean and agile software development

We asked Ishii-san if he had considered Agile software development. He was aware of Agile and liked the ideas, and said they will probably move in that direction. But they will do it in the Toyota Way – patiently and methodically, as Agile is not a goal in itself. I couldn’t agree stronger.

He said that “we are trying to learn how to apply TPS (= what we call Lean in the west) to software development”. Imagine the look on our faces. We came there to learn from what we thought would be the holy grail of lean software development, most of us were expecting to be dazzled and impressed.

He showed us this version of the Toyota house:

He said that they are currently at the bottom of the “house” (see the text highlighted in red, with numbers). Management, Process, and Making People. Without that, you can forget the other more technical aspects of lean such as Flow and Waste elimination.

He talked a lot about transparency – “How can you manage something that is invisible? How can we visualize software development? The key to success is mutual understanding between managers and engineers.”

 He also talked a lot about engineer motivation and skills – that software is a creative process and motivation is key. “If engineers feel their own skills are improving by ‘visualization’, they can get high motivation for their work. The most important thing in the project is not only to develop software but also to cultivate engineers.”

One of the big impediments is their current software architecture. He didn’t get into details, but mentioned that they need to make significant changes in their architecture to enable Lean and Agile software development. My belief is that it is the other way around – that Lean and Agile software development provides a way to implement the architectural change in an iterative & incremental way.

He emphasized the importance of testing & fixing defects early. A defect found in the production phase is about 50 times more expensive than if it is found during prototyping. If the defect is found after production it will be about 1,000 – 10,000 times more expensive! I’ve seen other studies showing similar numbers. He showed some data on this, visualized in the bar chart below:

Reality turned out to be worse, a lot worse! As Toyota’s current problems with the Prius braking systems is costing them over $2 000 000 000 (2 billion!) to fix because of all the recalls and lost sales. “Toyota announced that a glitch with the software program that controls the vehicle’s anti-lock braking system was to blame".

Standardization and metrics – is Toyota going too far?

Most of Toyota’s ideas about how to do Lean software development resonated well with me. My feeling was that they are on the right track.

One thing bothered me though – the extreme focus on detailed metrics. I agree with the value of visualization, standardization, and data-driven process improvement – but only if used at a high level. My feeling was that Toyota was going to far. They say engineer motivation is critical, but how motivating is it to work in an organization that plans and measures everything you do – every line of code, every hour, every defect, how many minutes it takes to do an estimate, etc? I saw very thick and detailed process manuals about this – not only at Toyota, but at other Japanese companies that claimed to be implementing Lean software development.

The thought “ugh… micromanagement” popped into my head several times during the tour. Maybe it’s a cultural thing.

I’ve spent years helping IT companies implement this stuff in practice. I’ve found that in many cases both motivation and predictability improves when my clients decrease the level of detail in their estimate and plans. Software development seems inherently unpredictable, so spending too much time and effort trying to make detailed estimates and plans is wasteful and in some cases even counterproductive. Having detailed manuals for everything you do stifles innovation and creativity. Many of my peers and colleagues in the Agile software development community share this experience.

So my feeling is that either the Agile community has something to learn from Toyota, or Toyota has something to learn from the Agile community. Probably both.

Closing thoughts

It is deeply engrained in Toyota’s culture to be dissatisifed with the status quo. So my feeling is that even if they had a really good software development process, Ishii-san would have said that they were dissatisfied with it and wanted to improve it.

Despite all the problems Ishii-san mentioned, my first thought was that their process can’t be all bad since they are a successful company with millions of cars all around the world using their software. The Prius model was developed in record-short time despite the extreme level of innovation in that project.

 I hadn’t (at that time) heard anything about quality problems with Toyota’s software. So waterfall or not, they still seemed to know what they were doing.

In fact, my conclusion after the trip was “well, now I know that there’s at least one company in the world that can succeed with the waterfall model” and I decided to stop bashing the waterfall model as hard as I usually do.

Now, however, with all the problems Toyota are having, I’m starting to reconsider. Are these problems software related? Could they have been avoided if Toyota used Lean & Agile software development instead of the waterfall model? I can’t sure, but I suspect yes.


Many people helped make this trip (and article) possible. I’m grateful to you all, and I’d especially like to thank:

  • Satoshi Ishii-san and Toyota for finally telling the world how they do software development
  • Mary and Tom Poppendieck for facilitating a Hansei (reflection) after each day on the tour. This helped us sort out our thoughts.
  • Kenji Hiranabe for enabling the visit to Toyota.
  • Bent Jensen and Best Brains for organizing the first Roots of Lean Study tour. They are doing it again, click here if you want to join!

The lean study tour was extremely inspiring and well-organized! I’ve lived in Japan for 16 years so I wasn’t sure I’d learn anything new – but going back there with ‘Lean glasses’ on I met so many interesting people and saw so many interesting things that I’ve realized my Lean journey has only just begun.

A perfect orchestra

Posted on by

The week in Japan has been very intensive and thoughtful.  We have visited about 5-6 Japanese companies, everything from a small software company with 10 employees to Toyota and their software development.

So what is the lesson learned of this trip.

From my impressions there are a lot of differences and similarities between the Japanese and the Swedish culture but what struck me most was the way of thinking towards Kaizen. Every company we visited had Kaizen as their number one priority, from the CEO down to ordinary workers.

Our meeting started with a visit at Fujitsu with their CEO and one of their chief engineering. They were really proud of showing us how they have with help of Kaizen made their productivity increase between 5-6 times from 2001 to 2008.

After that we visited Toyota museum and plant. As soon as you stepped into the museum and the factory you could feel the kaizen all over the place. The factory was so well synchronized that I understood that this has evolved during a long time where Toyota had improved their process to become “the” perfect orchestra.

We also visited some minor software development companies where I again was amazed of the way the companies breathed kaizen. This experience was confirmed in one simple sentence from the former Lexus IS chief engineering Mr. Nobuaki Katayama, with “KAIZEN = DNA”.

Every time I was reminded about Kaizen my thoughts went back to how we work in our companies in Sweden and what if we had kaizen as our most important priority through the whole organization at all time, the question is what we need to do to insert Kaizen in our DNA.

Roots of Lean, quick summary

Posted on by

Back from Japan! It was a very learning week. Among other we met

  • Manager for Toyota automotive  software
  • CEO of Fujitsu Siemens Software
  • Representatives from the Agile community in Japan
  • Agile pioneers such as Eiwa and Azzuri
  • Cheif engineer of Lexus and Supra program, Katyama-san
  • Former IT manager of Toyota Kuriowa-san

And of course visited a Toyota plant 🙂

It was really interesting to see:

  • Toyota’s response to the current crises, totally different from what I’d expect western companies to do
  • How continuous improvement, Kaizen, is on top of the agenda. Especially CEO’s. "It is in our DNA"
  • How Kanban is the center of the modern Japanese software shop
  • How the Agile community of Japan is spearheading changes
  • How new cars got developed and how people leading these efforts where picked (comparison: Product Owner in Scrum)

I am going to talk more about this in my session at Future of Agile.
Big thanks to Bent and Kenji who made this possible.

Lean Study Tour 2009

Posted on by

As I mentioned in a previous post, I am right now in Japan with 4 colleagues from Crisp, a few consultants from BestBrains in Denmark, Mary & Tom Poppendieck, Gabrielle Benefield, and some other Lean & Agile enthusiasts. We are visiting Toyota and other interesting companies. It is especially interesting to look behind the scenes of less well-known areas such as how Toyota does software & product development.

Here is our running logbook with our agenda, notes from our daily Hansei (reflection) + links to related blog entries.

We will be adding raw info to this page as we go along.

UPDATE (2009-04-22): sorry, the above document is no longer public. The info there was too raw and subject to misinterpretation. I’ll add more info about the trip later.

UPDATE (2009-06-27): Here are some mindmaps summarizing key observations and learning points from the trip.

Roots of Lean – day one

Posted on by

I am currently on a visit to Japan to meet Toyota and representatives from Japan’s industry to learn about their challenges. Already on day one, things got really interesting.

We met today with the CEO of a Fujitsu subsidiary, specialized in software. The company is applying TPS to improve their practices. It was interesting to see that:

  • The CEO was puts improving engineering and kaizen practices on top of his agenda. He is committed and actively involved, driving improvements. In his world improvements comes first, operations second.
  • A sign of the ambition is the fact that the company employs a mathematical expert to help out with analysis. When would that happen in a western company 🙂
  • They are experimenting a lot with estimation techniques! The technique currently favored is "Function Scale" –  a simplified version of Function Points. The technique is based on user interface design and is fast, only takes 1-2 minute compared to what a skilled function point analysis would take 30 min or more to do.

Some reflections:

  • Culture and local experiences affects solutions looked at. Turning to TPS, Kaizen and statistical process techniques for improving software products is therefore logical
  • But – using best practices based on other’s success, without thinking (what problem it was intended to solve, how this would help our situation) – is dangerous. Not only can this stop you from solving the right problem (you might be in another situation!) it can also dilute your competitiveness no longer staying ahead. Something to think about when we apply Scrum, Lean or any practice.

Anyway, a really interesting week up ahead! Tomorrow, first visit at Toyota plant, later in week , meeting the former Lexus cheif engineer Kataymy-san and the former IT manager of Toyota.

Future of Agile – update!

Posted on by

The schedule is taking shape for May 27:th,  we now announce two more sessions:

  • Kanban vs. Scrum – Henrik Kniberg
  • Roots of Lean and Agile  – direct report from Toyota visit

Also, meet the experts face2face in the afternoon open space session. Here is your chance to discuss in person with the father of Kanban, David Anderson and with Henrik Kniberg.

More is to come. Seats are limited. Don’t miss out.


Planning ahead in Scrum

Posted on by

In Toyota Production System (TPS) action takes place through the Plan-Do-Check-Act-Cycle


If we relate this to Scrum we see a lot of emphasis on the Do, Check, Act part. But not as much on the plan part. Planning is usually explained as a an activity that takes place on sprint planning day where both team and product owner are participating.

However, how do we deal with situations like:

  • stories that require a multi team effort
  • interfaces to third party systems

..and given a definition of  done "running in production" are we answering questions like:

  • are we implementing the right solution to our problem?
  • is our delivery useful to our recipients?
  • have we got access to necessary resources?
  • can we test? can we deploy?

Basically we need continuously run a thought process in the sprint before we do the implementation. Typically a development team spend around 20% of their time planning for their implementation (Mary Poppendieck).

Thinking ahead
The deliverable for the thought process is "story has business value and is estimatable"
So how do we go about?

Option 1: Use scrum master as an analyst
Appoint the Scrum master as the responsible person for dealing with forward thinking.


  • SM is already a contact point
  • He does not suffer as much from interupt control as other team members


  • Not always the correct technical person for solutions
  • Team can feel overrun

Option 2: Use an external analyst
Get a dedicated analyst in the team that always looks forward.


  • Releaves team from communication stress


  • Adds an extra handover step (waste)
  • Needs to be a superb communicator with team.
  • Analysts tend to lean over to business focus
  • Communication issues remain hidden

Option 3: Assign a "look ahead" story for each sprint
Insert a story which makes next sprint stories estimatable.
Team can pick tasks from this story in same way as on normal stories.


  • Team can choose among the stories in normal scrum way
  • Communication issues are surfaced
  • Bonding to outside parties is preserved in team


  • Product owner needs to have a forward vision
  • Team members might need training in communication skills
  • Implementation might suffer if extensive travel is required

My personal preference is with the option #3. But I have also seen option #1working in Scrum teams. The bottom line is that you need to think this through or you might end up building software that does not deliver intended business value.