Is the Toyota Production System Responsible for Toyota's Success?

In April of this year it was announced that Toyota had overtaken General Motors as the largest manufacturer of automobiles in the world in terms of vehicles sold. It seems that they will maintain this lead for some time to come. Interesting, a Toyota representative played down the achievement stating that they were focussed on meeting customer needs rather than winning a race.

The Toyota Production System and the Toyota Development System, initially developed in the 1940s and 1950s and publicized in the west in the 70s and 80s, were primary inspirations for the Lean and Agile movements. So is "The Toyota Way" responsible for Toyota's success? According to a report that I overheard on BBC World Service Radio, yes, at least partially. They mentioned the Toyota Production System and stated that it is now used by most automobile manufacturers. Maybe the superficial details of the production system itself are even used by GM, but the Toyota Production System is based on much more which, according to anecdotes that I have heard, has not been adopted by GM.

The Toyota way is based on respect for their workers and embodies important principles such as self-organisation and adaptive processes that are so important when managing complex systems. It also applies the principle of eliminating waste, so if, for example, a machine needs to be moved to enable a team to do its job better, it will happen without jumping through hoops.

All of this does not sit comfortably with a prescriptive command and control approach, yet many Western organisations remain tied to such practices. In many cases, particularly when there is a crisis, the instinct of Western organisations (including governments) is to add additional controls to their processes (in the form of rules, laws etc.). This is often the opposite of what is required - give people the resources that they need, make them feel that they are truly valued and respected and they will deliver the results.

TDD Workshop

I recently led a test-driven development (TDD) workshop for the team that I am currently coaching. We've been working together for several Sprints (every Sprint bar none has resulted in valuable functionality that has been put into production). We've previously looked at unit tests in detail and I had made a strong recommendation to try to write the tests before the code under test. Over the last couple of Sprints, the quantity and quality of unit tests in the product has increased dramatically.

One of the outcomes of our last retrospective was that the team requested that we revisit the area, this time focusing on TDD. So I scheduled a couple of hours for a workshop.

I kicked the workshop off with a few slides to explain the philosophy behind TDD, explaining that TDD is not just about testing (or even mainly about testing) but has a great deal to do with design and documenting what services the code provides. I found a quote from Bob Martin that I really like:

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”.

The introduction led to an extensive discussion about the pros and cons of TDD. In this type of situation, I'm not looking to convince people that a particular technique is valuable (you can't make people believe in something) but to get them to try it out and then reflect on whether it works for them and the team.

I fired up Eclipse and went through some examples (based on material from Frank Westphal's excellent book Testgetriebene Entwicklung mit JUnit und FIT).

By the end of the workshop, everyone had agreed to give TDD a try in the current Sprint. As normal, we'll reflect on our experiences at our end of Sprint retrospective.

Second Talk on Agile at CDTM

I was recently invited to do another talk on agile methods at the Center for Digital Technology and Management in Munich, Germany.

This time, the talk covered the following areas:

• user stories
• agile estimating and planning

After examining some of the characteristics of good user stories, the students practiced writing some (with "As a ..., I want ..., so that ..." clauses and acceptance tests on the back).

We then used the planning poker technique to estimate some user stories for the team's first Sprint.

Once gain, thanks very much to Ana Balevic for organising and hosting the talk and to the students for some interesting questions and discussion.