1947. Japan, still reeling from the Second World War, lies in economic ruin. And a little company called Toyota finds itself in a highly undesirable strategic position. It’s headquartered in a nation in tatters, and competing with companies in the world’s newest economic super-power: ‘Merca. How could it possible compete against companies with such amazing access to capital, resources and cash-rich customers?
Well, necessity, as they say, is the mother of invention.
And the necessities of Toyota’s strategic realities gave birth to one of the most remarkable feats of management ever achieved: the Toyota Production System. Or, more generically, “lean” development.
Previously on “Game Planning With Science!”: Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7 Part 8
By Reading This Post, You Will Learn
- What “Lean Development” is
- The origins and underlying focus of Lean
- The trade-offs that come with Lean
- The difference between value-adding and non-value-adding activities
- The Toyota Production System’s 7 categories of waste
Lean Development: The 10,000 Foot View
Now it’s important understand the end result of the Toyota Production System when considering its merits. Simply put, Toyota became the world’s largest car company in terms of market capitalization*. Simultaneously, it established a reputation for high quality in an industry that popularized the term “lemon”.
In short, lean development isn’t some neat, squishy academic concept. It’s battle-tested framework that allowed Toyota to cut costs while improving quality and maintaining throughput.
Now, lean is as much a philosophy as it is a system of best practices. A philosophy that can be laconically summed as “waste is the enemy”. Toyota didn’t have the resources or income of its competitors, but it still had to compete in terms of quality and output. So it was economically incentivized to cut costs without reducing value for end-users.
Scylla and Charybdis
Previously, I mentioned the story of Scylla & Charybdis in Part 6 of “Game Planning With Science!”. In Book XII of The Odyssey, Odysseus and his crew must sail through the Strait of Messina (between modern day Sicily and Italy). On one side of the strait lives Scylla, a giant six-headed serpent that would pluck six sailors out of any boat that passed. Opposite Scylla lives Charybdis, who would create whirlpools in the strait. Maybe you can sneak past her, but if she catches you, everyone aboard will die. Consequently, Odysseus’ choice was simple: definitely lose six sailors or possible lose all of them.
Personally, I like to think of this choice in investment terms. If you go with Scylla, you are accepting a known cost to eliminate risk. Counter-intuitive as it may seem, there is 0 risk with Scylla from the perspective of the crew as a whole (although the individual sailors may beg to differ). You know exactly what’s going to happen: 6 sailors will die. No more, no less. If you go with Charybdis, you are accepting risk in order to maximize upside. You might get everyone through, but you also might lose everyone.
Lean development is a modern day version of this parable. It is a Scylla approach to management. You are definitely spending time and money now (sacrificing the six sailors) in order to avoid much larger potential costs down the road (the whole crew).
So, when you think about lean development, it’s vital that you not only consider the costs. You need to also consider what it saves.
Understanding the Term “Activities”
From a production standpoint, an “activity” is any individual action performed by an employee. This can range from mounting car doors to rebooting computers to attending meetings. There are a couple of dynamics you should recognize about activities. First, all activities fall along a spectrum.
At one extreme end you find processes: activities which are known and predictable. And at the other extreme you have discovery – the unknown and the unpredictable. I wrote about the spectrum in greater detail in the intro to “Game Planning With Science!”. Now, there is only so much you can do to limit the unpredictability of discovery. Therefor, a lean development approach seeks to minimize the variance in your processes.
And the second critical concept to understand is that there are two broad categories of activities: value-adding and non-value-adding.
Value-Adding Versus Non-Value-Adding
Value-adding activities improve the value of the product in question for the end user. This can be mounting chairs in a car, creating a high-poly character model, coding a feature, or running a QA pass. Meanwhile, non-value activities do not add value for the end user. They may add value for someone else, but not the person to whom you’re actually trying to sell a product. Non-value-adding activities would be things like meetings, documentation, drafting of legal documents, etc.
Then, Toyota further sub-divides non-value-adding activities into two groups: Type-I and Type-II. Type-I activities don’t add value but are necessary. Type-II are neither value-adding nor necessary.
In general, for any activities that you routinely perform, you should:
Value-Adding or Non-Value-Adding, Type-I
Streamline, automate, or outsource
When I say “outsource”, I’m using a very broad definition. I don’t just mean bringing on contractors. I mean paying another company who’s better at the activity to do it for you. That may mean contractors or other companies. But, it could also mean just signing up for a software account. For instance, Quickbooks is a form of outsourcing, as is Jira.
Yes, outsourcing costs money. But so does your time. If someone can get the job done faster and more reliably, and the cost of the service is less than the value of the time it would take you to do it yourself, it’s a net-positive investment.
Resources That Informed And Influenced This Post
If you have ad blockers turned on, you may not see the above links.
The 7 Deadly Muda (無駄)
If waste is the enemy, then that enemy has a name: muda (literally…well…”waste”). Toyota classifies it in 7 different categories:
- Defects (obvious enough)
- Overproduction (making more vehicles than the market wants to buy)
- Inventory (keeping too much on-hand inventory in the plants)
- Extra Processing (making products to a higher degree of precision than the end user requires)
- Motion (making workers physically move more than what is necessary complete any single activity)
- Transportation (subjecting in-progress units to longer transfer times between activities than is necessary)
- Waiting (making in-progree inventory wait for any activity to start)
And to put these forms of waste into game development terms, we would have:
- Defects and missed feature specifications
- Feature creep
- Excess work-in-progress
- Over-designing or over-engineering
- Slow development computers/tools
- Bloated build times
- Work queues
Over the course of the subsequent posts on lean, I’ll cover why each of those forms of waste are so…wasteful (some of them are more obvious than others) and how to use lean processes to combat them.
Further Reading If You Enjoyed This Post
Where Do We Go From Here?
These posts on lean represent a subsection of “Game Planning With Science!”. If parts 1-8 where about effective forecasting, then the posts on lean are about how to reduce the variance of that forecasting. So, over the course of the lean posts, I will walk you through the various processes and concepts of lean, how they reduce one or more forms of waste in a production process, and how you can apply them to game development. First up, poka-yoke, the fine art of mistake proofing!
- The advent of lean was driven by the dire economic circumstances Toyota found itself in after the World War II
- At the simplest level, lean is about reducing waste
- The basic trade-off of lean is that you are making known investments in the near term to avoid unknown, and potential far larger costs over the long term
- There are two basic categories of activities: value-adding and non-value-adding
- Value-adding activities improve the value of the product in question for the end-user
- Non-value-adding activities do not
- Toyota further subdivides non-value-adding activities into Type-I (necessary) and Type-II (unnecessary)
- In a lean development scenario, Type-I activities should be eliminated
- For any recurring activity, you should seek to eliminate, automate, outsource, or streamline (in that order of priority)
- Toyota classifies waste into 7 categories: defects, overproduction, inventory, extra processing, motion, transportation, and waiting
- In game development terms, these would be defects, feature creep, excess work-in-progress, over-design/-engineering, bureaucracy, inefficient build processes, and queues