Reading The Toyota Way

I’m reading The Toyota Way by Jeffrey K. Liker. It’s changing my mind.

When I started this book, I thought, well, this book is a compilation of interviews and stories, so there is no real meat, it’s not really teaching the methods they are using in Toyota. I thought it was a pretty fluffy book. Was I wrong!

It’s true that the meat of the book are stories that the author experienced himself, or were related to him. It’s not true that there are no practical hints on how to apply Lean Production; there are many examples of how to do that. But that’s not the point. I mean, Toyota makes cars, I make software. The actual practices are meant to solve their particular problem. What this book shows is how getting good at management comes from a shift in the way you think. The wealth of examples in the book pushes the reader to a different way of thinking.

The Toyota Way is also a depressing book. Perhaps half the stories in the book are about how American companies tried to apply The Toyota Way and failed miserably. This speaks about the importance of being serious in what you do. The Toyota people are dead serious. Which is not to say they don’t have fun… If your idea of fun is to stretch your capabilities to the limit, keep learning and getting better.

There is another feeling that comes to me while reading. The Toyota company is what in Italy is called “primo della classe”. This expression means “the boy or girl with the best grades in their class”, and carries a negative connotation. This says a lot about the way people thinks in Italy; the idea that someone can be better than me, or maybe *a lot* better than me is met with hostility. Our thinking is, “they are first because they spend countless hours on the books; if I did that I would get the same grades, but I won’t bother”. Ha! Do I have what it takes to really spend this effort? I probably don’t.

So these Toyota people come across as “primi della classe” because they are really good. And there are companies out there that are way better than the norm, and still are not as good as Toyota; which shows that there is a long path of improvement. This realization can be either exciting or depressing; it’s our choice :-)

As I keep reading the book, it takes me a lot of time as I’m taking notes, and all the while I think how the principles of the Toyota Way would apply in my situation. For instance, the book says that Taiichi Ohno insisted that when you walk to a plant, you should see immediately if everything is OK, or there are problems.

Translate that to software development. How would you do that? Good question! Agile developers do many things to make the development process visible; the cardwall, the burndown chart, the velocity chart are good visual indicators. But can we do better? Translate “plant” to “a workstation with a pair of programmers at work”. Can you see that their work is processing smoothly? One valuable insight is recognizing that the pair might block on a problem, just like an assembly line can jam. How do you see when a pair is blocked? (Hint.) What do you do when a pair is blocked? Do you treat this block as seriously as you would for a defect in the product? Do you try to understand the root cause of the block, so that it doesn’t happen again? Do you measure how many such “incidents” happen in a week? Do you measure how much time is spent working smoothly, and how much time is spent blocked on a problem?

4 Responses to “Reading The Toyota Way”

  1. Peter Saddington Says:

    Sounds like there may need to be a more apparent information radiator or visual representation of when a programming pair is blocked? Or do you just know (if you know your team very well).

    Interesting thoughts on how to visualize issues in a week.

    Best,
    Peter Saddington
    http://www.whitebarrel.com/blog

  2. matteo Says:

    Hi Peter,

    thanks for your feedback. You can see if the pair is blocked from afar by their voices and postures; but this is apparent only if you are experienced enough to tell the difference (for instance) between being busy and achieving little, and programming productively; or between aimless discussion, and focused problem-solving.

    There are some objective indicators you could use; you could check, for instance, how long since last commit, or how long since last “green” in JUnit. These indicators are highly dependent on your team’s practices. What do you think?

  3. Dean Says:

    Nice post. I really enjoyed the book, and your comment shows that you understood that the author is trying to convey a philosophy rather than a set of steps. More importantly, readers need to learn the philosophy then apply it themselves – infact that is the very heart of TPS – i.e. to continuously improve everything, even improving the improvement!

    As i consider TPS and its philosophies, it seems easy to apply them to software development. Perhaps not completely and literally in every case – but it ways that make major improvements.

    For example, continuous build and test systems (continuous integration is what they are sometimes called) fits wonderfully in to TPS. Coders can flick their code in to the system and get results back quickly, also the code base can be built and tested automatically and the results placed in emails, on a screen etc etc.

    As a perl coder, we have a strong suite of testing software. Even tests to test that our test cases test everything in our code! Tests that check for best practises, documentation coverage (pod) and code tidiness, both of which can be easily customized. These can be easily built in to a system which falls in to the TPS philosophy.

    Platforms like ‘github’ also have lowered the entry level for trivial updates, making forking, updating and then pushing the changes really trivial. Such a system allows programmers to easily make small files and improvements in a controllable manner. I think this is again, another concept that is true to TPS

    I would love to hear how other people have applied TPS to IT systems and software development. I dont think there is a right or wrong answer, TPS is all about what works for you!

  4. Plamen's Blog: Weekly agile links 6th - 10th September 2010 Says:

    […] Pannone. Perhaps worth reading if I could place it higher than all of my other tasks (unlikely).Reading The Toyota Way Matteo Vaccari with some thoughts on how this book changes his view.BUT /MY/ TEAM NEEDS A LEADER […]

Leave a Reply