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
|
Non-Value-Adding, Type-II
|
Eliminate
|
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. Breaking The Wheel is part of Amazon’s Affiliate Program. If you purchase products using the above links, the blog will get a portion of the sale (at no cost to you).
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
The Time Value of Fixes, Or: A Fix in the Hand is Worth Two in the Bush
Discovery Versus Process – A Preface to Game Planning With Science
Video Game Art Pipelines – Game Planning With Science! Part 1
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!
Key Takeaways
- 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
If You Enjoyed This Post, Please Share It!
*Market Capitalization = (Number of Outstanding Shares of a Publicly Traded Company)*(The Value Per Share). Basically, the measure of value of publicly traded companies.
†From an operational/management/investment perspective, the terms risk, uncertainty, and variance are interchangeable. They all refer to the range of possible outcomes. In other words, risk, uncertainty, and variance all speak to how far the actual outcome could fall from the expected outcome. For instance, paradoxical as it might seem, jumping off of a 2-story building is riskier than jumping from a 50-story building. The outcome of the latter is far more certain (you will die) than the former (you might be fine, you might break some bones, or worse). Jumping from the 50-story building is obviously more dangerous, but its spread of potential outcomes is far less variant.
Return to the “Game Planning With Science” Table of Contents
“Lean Development for Games – Game Planning With Science! Part 9” by Justin Fischer is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
4 comments
Pingback: Kanban: The Counter-Intuitive Value Of Pull-Based Production - Game Planning With Science! Part 11
Pingback: Heijunka: Why Batching Is Not Your Friend - Game Planning With Science, Part 14
Pingback: The Higher Order Consequences of Sprints: The Fancy Mess of Scrum, Part 2
Pingback: Conflict of Interest: The Fancy Mess of Scrum, Part 3