Oh what a feeling — Principles from the Toyota production system
The Toyota production system has been used as a source of inspiration to collect methods and techniques for agile and lean workflows long before agile and lean even were a thing. What is often overlooked though is the principles behind the methods and the techniques. Maybe those principles can tell us more on how to replicate the success from Toyota 60 years ago than what the methods and techniques can?
Started from the bottom now we’re here
In the Toyota factory, they had to constantly manage the fluctuations from producing too many parts, to not enough parts. In order to handle this problem, they came up with the method of “production leveling”. Production leveling attempts to flatten the production curve so a steady flow of parts is being produced all the time[1]. For example, why should you spend 20 minutes producing 20 bolts and only use 10 now, when you can spend 10 minutes producing the 10 bolts that you actually need. Freeing up 10 minutes to produce value elsewhere.
We can translate this to software development. The upper part of the production curve would represent overdelivery, building unnecessary features, and adding processes. The lower part of the curve would then be underdelivery, low quality, and a defective product.
Often times we end up in the upper area of the curve. This is, in a sense, a good problem to have. We have the means and the abilities to create high quality work, so we do. But starting at the top can lead to wasted work in terms of overengineering, long delivery times, and unnecessary overhead.
What’s dangerous though, is that there is an alluring sense of completion and closure that comes with the top of the curve, which can be as soothing as a warm sauna when it’s -22 degrees outside. However, overdelivering will lead to you and your team spending valuable time working on solutions for problems that does not exist. You are producing 20 bolts when you only need 10.
Luckily, in software it is cheap and easy to incrementally improve, so it is usually better to start at the bottom of the curve instead. But it is uncomfortable and difficult to start at the bottom. If you want to start at the bottom you will have to release software to customers with a little bit of shame and unease in your stomach. However, doing so will ultimately make it easier to gather feedback, building only what needs to be built, and learning more about the problems that the product or the feature is designed to solve.
Toyota wanted to flatten the curve (image 1) as much as possible[1] to reduce waste but for software products we can instead incrementally improve so let’s try to make the curve grow from left to right instead (image 2). Increasing value, removing bugs, and adjusting according to feedback as we go along.
In the Toyota factories they trained their workers to be able to operate more than one machine at a time, which makes it possible for the factory to easily allocate their production towards where it is most needed[1]. Releasing software incrementally enables us to do the same thing as Toyota did 60 years ago. If something more important comes up than what is being worked on right now it is uncomplicated to shift focus, and when focus shifts, some software and therefore value (hopefully) has already been delivered.
You aren’t gonna need it (YAGNI)
One of the easier ways of starting at the bottom is through problem pruning. The first iteration does not have to solve many different problems, it will only have to give some form of initial relief for one single problem. Just like the epa-dunk[2] duo Hooja and Mårdis sings “there was no camera on the iPhone 2”*.
Not adding a camera on the first iPhone made it possible for Apple to focus on what they thought were more important things to focus on. The learning from Steve Jobs and co is then that solving just one problem will reduce the inventory in terms of tasks in the backlog, reduce the risk of overproduction, and reduce processes. All good things according to the Toyota production system[1].
*there was a camera at the back of the iPhone 2, but there was no selfie cam.
Teamwork makes the dream work
In the Toyota factory they needed to come up with a system that could support production leveling, zero waste, and just in time and through that Kanban was born. Kanban was used as a sort of work order as it moved together with the needed goods from one process or team to another[1].
One of the problems that Kanban was designed to solve was to minimize overproduction, the team to the right could ask the team to their left exactly the number of nuts, bolts, and parts that they needed from them. Then when the parts were finished, they arrived together with the attached work order, just in time and in the correct quantity[1].
That’s a pretty neat and simple system to keep track of things and to minimize overproduction in a factory. Similar Kanban-like systems have been adopted for software teams in order to solve similar problems[3].
But writing software is different from the work that is happening at the plant. Writing good software is a messy and creative process where we stumble around trying to figure out what’s going on and we try to learn to the best of our abilities what we are actually doing. In contrast to the process that Toyota uses when producing cars, the rules have been decided before the race begins in a sense, there are less unknowns.
Luckily for software teams, work doesn’t have to flow from left to right, we can instead embrace the messy, creative process and work more closely together between different disciplines and domain areas. Simply put the business, engineering, and design should and can work on the same problem at the same time. When we are collaborating like this (image 6), the need for looking ahead, planning, and predicting diminishes. Instead, the need for learning, collaborating, and adjusting from feedback increases.
Which is a good thing! Since just like Taiichi Ohno from Toyota writes:
As long as we cannot accurately predict the future, our actions should change to suit changing situations[1].
In conclusion
I like principles, fundamentals, and defaults because they let organizations, teams, and individuals to be creative within their constraints. There is room for innovation, improvements, and reflections inside of a box that is built by principles in contrast to a pre defined system. Maybe that is one of the reasons why Toyota was or rather is so successful: because they are driven by principles over techniques[1]. In this post however, we have primarily looked at the techniques and methods that Toyota has implemented to support their principles. Here’s what we can learn from those techniques:
- Production leveling maps to learning, adjusting from feedback, and incrementally adding value.
- One worker many machines maps to the ability to direct our energy towards the most important problem right now.
- Kanban maps to embracing the messy and creative software development process and collaborating between different disciplines.
References
[1] The Toyota production system http://dspace.vnbrims.org:13000/jspui/bitstream/123456789/4694/1/Toyota%20Production%20System%20Beyond%20Large-Scale%20Production.pdf
[2] Epadunk Wikipedia page https://sv.wikipedia.org/wiki/Epadunk
[3] Kanban (development) Wikipedia page https://en.wikipedia.org/wiki/Kanban_(development)
