The Toyota Production System and Scrum (2)

In 2006 I wrote a short article “Scrum Delivers” [1] in which I showed that the principles of the Toyota Production System as described by Jeffrey K. Liker [2] can be mapped to Scrum. In the following weeks I will show how Scrum maps these principles. The idea is to understand Scrum as a mindset not as a methodology. About principle 1 I wrote here: Principle 1
Principle 2: Create a continuous process flow that brings problems to the surface.

Scrum requires a clear production workflow that is based on goals. This workflow includes timeboxed activities, clearly defined review and feedback points, and clearly defined roles: ScrumMaster, Product Owner and Team members.

“Create a continuous process flow that brings problems to the surface.” When we work with teams the first start – a first Sprint – is most of the times easy to do. To establish a continuous flow is the real challenge. We did a Sprint with a very good team. We built the functionality and everybody in the organization was happy. And what happened – the next Sprint Planning 1 – something that should have been a piece of cake, was really hard to do. Why? Because the Product Owner was not prepared. 

The ScrumMaster was so bussy in the first two weeks that he could not work with the Product Owner to prepare the backlog properly. 

So although everybody started to like this way of working, the old habits started to impede the next step. But what did we learn? We learned that at this moment on time the Product Management is not able to feed a Scrum Team properly. That is not a problem for the next two Sprints, but it will be a huge issue in Sprint 4 or 5. 

Continuos Flow – that is the basic idea. A Scrum Team works together from Sprint Planning 1 to Sprint Review to Sprint Planning 1 to Sprint Review supporting the flow by having 1 or two estimation meetings during this time. A continuous flow also means that you can put out functionality that works, and then you go to the next piece of functionality that you want to build. A continuous flow will only be established when you can integrate the testing activities within your Sprint. If you fall back again and again because of bug fixing or other issues than you do not have a continuous flow. So to thrive for the continuous flow will already show what you need to do.

What I like with the statement we get from “The Toyota Way” is that the purpose is clearly stated: bringing problems to the surface. In Scrum we always say that we want to help ScrumMasters to see clear the problems. And seeing the problems is the first thing we need to do before we can act on it.


[1] Scrum Delivers, Boris Gloger, Scrum Alliance Website

[2] The Toyota Way, Jeffrey K. Liker


2 responses to “The Toyota Production System and Scrum (2)

  1. I am not sure how to interprete your words. Do you mean that the sprint backlog is no longer fixed?

    Because that is how we implemented continous flow with some more experienced scrum teams, or with teams using scrum for non-software development.

    We used 3 week sprints but dropped the planningmeeting. Instead of one planningmeeting, the PO was coninously planning and asking the team for etimates. He was driven by how fast the team finished ongoing work.

    We kept the sprints for having a heartbeat, and to have demo’s of the finished stuff and a retrospective on regular times. Worked well!

  2. Pingback: Skipping Sprint Planning 1 - an idea I need to think about! « Scrum 4 You

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s