Scentific Thinking

The Plan for this issue is to:

• Introduce The Toyota Way and its four categories

• Explain what the Improvement Kata and scientific thinking is

• Explain why I think the software industry copied the wrong elements from the Toyota Production System

• Suggest what we could do differently

Let’s Do it:

The Toyota Way

The book The Toyota Way was published in 2001 by Jeff Liker and describes 14 management principles divided into four categories briefly summarised:

1. Philosophy

   1. Long-term systems thinking

2. Process

   1. Customer focus

   2. The continuous flow of value

   3. Pull-based Kanban

3. People

   1. Coach and grow your staff

   2. Set ambitious challenges

4. Problem-Solving

   1. Working scientifically toward a challenge

   2. Continuous improvement

We will explore each category in future issues of this newsletter. But for now, we will focus on the central idea of The Toyota Way—scientific thinking. Toyota takes a scientific approach to everything: strategy, process, coaching, challenges or improvements.

Scientific thinking

The scientific method describes steps to acquire knowledge through experimentation and empirical evidence. In the 1920s, Walter Shewhart adapted the method to continuously improve manufacturing processes. He called it the PDCA cycle (Plan, Do, Check, Act), often called the Shewhart or Deming cycle today. It’s essentially an iterative cycle through which you plan experiments with hypotheses, carry them out, check their results, and act on the knowledge you acquired.

Walter Shewhart worked as a physician at Bell Labs, and they used the method to improve the telephoning systems they were building. This part of Bell Labs later became the American Telephone & Telegraph Company (AT&T).

Then, in the 1940s, W. Edwards Deming popularised scientific thinking beyond just manufacturing and applied it to management, the service industry and knowledge work at large. He also evolved the PDCA cycle into Plan, Do, Study, Act (PDSA) while still referring to it as the Shewhart cycle. Deming wanted to emphasise that the results of experiments had to be carefully reflected upon, studied and analysed, not merely “checked.” He noticed that when most organisations conducted experiments, they forgot to analyse their results and act on the acquired knowledge. Still today, I find that this is often the case with many software teams who believe they practice experimentation and continuous improvement.

An incredible example of deliberate and systematic use of the PDSA cycle is how Japan recovered from losing the Second World War to building the world’s most productive manufacturing industry in just a few decades. Toyota led the way in Japan, and through relentless continuous improvement, the company went from nowhere to out-competing every American car manufacturer that dominated the market after the war. In the book Toyota Kata, Mike Rother describes how Toyota practices scientific thinking and the PDSA cycle through the Improvement Kata.

Improvement Kata

The Improvement Kata method recognises that striving for change or improvement is not natural for the human brain; it requires frequent and deliberate practice. The human brain prefers known habits over new challenges because that’s how we survive in nature. Therefore, the Improvement Kata describes a set of daily routines for coaches (team leaders) and learners (team members) to strive towards improvements by using scientific thinking. There are four essential steps of the Improvement Kata which bring focus to the process:

1. Understand the direction or challenge. What is it we are trying to improve?

2. Grasp the current condition. How is the process behaving right now?

3. Establish the next target condition. What should the process look like to get us closer to the challenge?

4. Experiment towards the target condition.

Then, during a short 15-minute session each day, coaches ask learners five sets of questions:

1. What’s the target condition you strive towards?

2. What’s the current condition?

3. What obstacles are preventing you from reaching the target condition? Which one are you working on now?

4. What’s your next experiment? What do you expect to happen?

5. How soon can we study what we learned from that experiment?

As learners and coaches practice the habit of improvement, each experiment to tackle an obstacle is recorded with a series of PDSA cycle records:

• Plan: What’s the experiment and its hypothesis

• Do: Record of when the experiment was done

• Study: Analysis of what happened

• Act: Steps the learner took with the new knowledge

The Improvement Kata captures the essence of scientific thinking and creates a learning organisation through a community of coaches and learners, or as Steven Spear calls it in his popular Harvard Business Review article: “a community of scientists continually experimenting “.

We tried to copy the wrong things

Now, let’s get to the core idea of this newsletter and what we will study in even more depth in future issues: We tried to copy the wrong things from Toyota. Here is what Mike Rother is saying in Toyota Kata:

“What we have been doing is observing Toyota’s current visible practices, classifying them into lists of elements and principles and then trying to adopt them. This is reverse engineering—taking an object apart to see how it works in order to replace it—and it is not working so well.”

In the early 2000s, when the Toyota Production System (TPS) inspired the lean movement in the software industry, we focused only on applying TPS elements such as visual Jira board (Kanban), continuous delivery (Hedjunka) and automated testing (Jidoka), which put us into implementation mode, as Mike Rother calls it. While those elements are essential to software delivery, all we did was configure tools and forgot the most important part of Toyota: developing people, scientific thinking, and the capability to continuously improve outcomes.

What about sprint reviews and agile retrospectives?

The common agile ceremonies should help teams identify process problems and implement improvements. But it’s an exception rather than a rule to find teams and organisations where these ceremonies add value and serve their purpose.

One issue is that the teams don’t practice the habit of improvement frequently enough since, for example, the retrospective meeting only occurs once or twice monthly. Another side-effect of the delayed response to improvement is that details tend to be forgotten, and therefore, the implementations are not as effective. But perhaps most importantly, agile retrospectives lack focus and direction. When teams act before having a clear target condition, they tend to produce ideas of what can be improved rather than what needs improvement. In the Toyota Kata book, Mike Rother describes this as “the action-item list approach”. He writes (with some paraphrasing for clarity):

“The action items on the list originate from recording process problems, brainstorming, problem-solving activities, [agile retrospectives], value-stream mapping, and so on. Although we may believe that those uptake activities—like [agile retrospectives] or problem-solving activities—constitute our improvement approach, all of them merge into the same thing: a list of action items. And it is with those lists that we actually try to manage the improvement process.”

Rother continues:

“1. It doesn’t work very well. The underlying thinking with the list approach appears to be that the more action items we have, the more the process will be improved. The longer the list of action items and the more improvement projects under way, the more we feel like something positive is happening. In many cases, however, the opposite is true. [You will see] that the list approach is an unscientific and ineffective method for process improvement. […] The negligible results it produces can be observed in the lack of progress—in the wasteful and unstable processes that persist.”

“2. We are in the dark. Defining and introducing several action items simultaneously, and sometimes even voting to prioritise them, indicates that we don’t know what we need to improve. It would be better to simply stop and say ‘We don’t yet know what exactly to do’ […] but this seems like one of the hardest things to say.”

“3. We are asking ourselves the wrong question. When we hunt for wastes or opportunities to improve and make list of action items, we are focusing on the question, ‘What can we do to improve?’ That question is actually too easy, and it automatically leads us to lists and a scattershot approach. The more focused question is, ‘What do we need to improve?’ Admittedly, this is a more difficult question.”

“4. We are jumping to countermeasures too soon. A weakness in the list approach is a tendency to jump to countermeasures before we understand a situation. Generating a list of action items and implementing several counter measures, often simultaneously, reflects an unspoken goal of, essentially, ‘Just shut off the problem!’ People are rewarded for fixing a problem, for fire-fighting, not for analysing, even though the problem may occur later because it was not yet sufficiently understood.”

The hypothesis

I hypothesise that if software teams stopped approaching improvement through the action-item list approach and instead practised scientific thinking and the Improvement Kata, the following would happen:

• We would learn and grow more as professionals

• Work would be less frictional and more fulfilling

• Organisational outcomes would be less costly and more successful

I will share more detailed thoughts on what this could look like for software teams in future newsletter issues. I will finish off with another quote from Mike Rother:

“There are perhaps only three things we can and need to know with certainty: where we are, where we want to be, and by what means we should maneuver the unclear territory between here and there. And the rest is supposed to be somewhat unclear, because we cannot see into the future!”

Feedback

I would love to Study and Act on your feedback. Please leave a comment!

All views and opinions expressed here and in future issues of this newsletter are my own and don’t necessarily represent my employer or anyone I reference.