Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 26, 2014
arrowPress Releases
October 26, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The Elimination of Waste: Lean Six Sigma applied toward Game Development
by Harvard Bonin on 05/22/14 09:38:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


These days one must only search online to find many project management techniques that are prevalent within general software development but are not utilized often in game creation.  While Scrum has made a strong push into game production, many other techniques remain on the sidelines.  This is unfortunate since other methods from Traditional and Agile methodologies can be applied to our industry and could help yield positive results.

In this article I will not explain Lean Six Sigma in detail.  There are plenty of materials available if you’re interested in pursuing further.  Instead, I will focus on the core principles of Lean Six Sigma and show how it can apply to everyday game development.


Lean Six Sigma is a combination of two project management techniques called “Lean” and “Six Sigma”.

Lean: Focuses on delivering customer value efficiently above all other activities.  Any activity that does not add value for the customer is removed from the process.

            Six Sigma: Focuses on removing all defects and variation from the process.

In other words, both are seeking to eliminate “waste”.  In Lean Six Sigma terms this waste is defined as “muda”.  This is a Japanese term popularized by Toyota and means specifically “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness”.  Waste can appear in many ways.  Idle time, rework, mismatched feature requirements, under and over communication, etc. Lean Six Sigma identifies eight (sometimes seven) types of waste.

There are many concepts underlying Lean Six Sigma.  Entire development projects have been built around the techniques, equations and tools available within this framework but they are much too involved to explore in this short article.  If you explore further you may notice that many of the concepts apply most directly to manufacturing.  While this is true the core principles can still have a direct, positive impact on game production.


In my experience, wasted opportunities are the single largest source of angst on teams.  Wasted time, most of all.  Continually striving to remove waste in all areas is a mindset that producers and project managers must develop and embrace.  Many producers think that their main role is to lead projects through guidance, task-forcing and sheparding.  They believe that they are like a general on a horse in front of an army, pointing their sword towards the enemy and yelling “charge!” While the role can have these elements, it’s shortsighted and limited.  An experienced team probably already knows how to work well and the producer’s best use of time might be to focus on waste rather than march them toward a goal.  Sometimes producers must let the team do what it does best and spend their own time bulldogging the blockers out of the process. 


Throughout my career I’ve experienced many problem ridden projects. In fact, all my projects have been difficult.  When they are completed the team usually turns to the post mortem to help shine a light on the many issues the production experienced.  The the most frequent and impactful concerns often revolve around “communication problems” and “misaligned expectations”.  

Communication Problems:  Teams often complain that they weren’t aware of the project goals, dates, inter-departmental tasks or management expectations. This issue seems to arise on every project. Fortunately, it’s one that is the most easily fixed through discipline, techniques and a commitment to transparency from all involved.  Most of all, producers and project managers must be acutely aware of this issue since it’s a main source of wasted time.

Misaligned Expectations:  Often management and content creators are not in sync regarding the definition of “done” when creating features, art, code, etc.  This misalignment leads to more rework on titles than most any other issue. The product owner, stakeholder, owner, etc. (whoever is the single source of creative control) must be clear in this communication to all content creators.

The commonality between these two issues is “waste.”   Both issues are instrumental in creating wasted time.  Time is the single most valuable resource available to product development.  Since Lean Six Sigma focuses on waste removal (time creation) it’s particularly useful when applied to game development.


There are eight kinds of waste defined in Lean Six Sigma.  An easy mnemonic to recall these is “TIM WOODS”.

Here is the academic definition.

T          Transport: Moving people, products & information
I           Inventory: Storing parts, pieces, documentation ahead of requirements
M         Motion: Bending, turning, reaching, lifting

W         Waiting:  For parts, information, instructions, equipment
O          Overproduction:  Making more than is immediately required
O          Over processing: Tighter tolerances or higher grade materials than are necessary
D          Defects: Rework, scrap, incorrect documentation
S          Skills: Underutilizing capabilities, delegating tasks with inadequate training


Consider your own daily game development experience.  How may these types of waste definitions can be applied to help uncover your project’s inefficiencies?  Here are some examples:

Transport: Does the transfer of assets take too long?  Are build times lengthy and defect ridden?

Inventory: Is too much time invested on lengthy design documents that change the next day?  Are there too many unpruned ideas out of scope that distract the team?

Motion: Is the environment set up to hamper communication?  Are people working on highly iterative features physically sitting together? Are the tools accessible and effective?  Is their workspace conducive to doing effective work?

Waiting:  Is the team continually waiting for other departments to complete their work?  Are they often idle?

Overproduction:  Are the artists creating assets without confirmation of the end requirements? Will the assets be used? Are departments running ahead of others before requirements are specified?

Over processing: Are people making assets that are too highly detailed than what is required?  Are they “gold plating” and polishing features that are the least impactful or important to the customer?

Defects: Is the code ridden with bugs?  Is it extendable? Does the resulting work align with the expected work? Do the assets created align with the engine capabilities?  Does the work match the expected grade?

Skills: Are tasks mismatched with the skillset of the team member?  Are PHDs working on tasks a GED could accomplish?  Or vice versa?


Theory and concepts are fine but they have little benefit unless they are applied toward tangible activities during development.  Below you’ll find my game specific (incomplete) list of actions teams can perform to embrace Lean Six Sigma thinking and try to eliminate waste.  None solve all project issues alone but taken collectively they may help teams significantly.  No doubt you can add many more.

Conduct daily stand-ups:  Short, ten to fifteen minute, well run Scrum stand-ups are useful. They promote face to face communication on a frequent basis and don’t require a large time investment. Infrequent and inaccurate communication is wasteful.

Replace weekly producer status meetings with risk meetings:  Conducting a weekly status meeting where everyone goes around the room to provide updates are generally useless. The information should have already been known through regular communication and reports.  Focused weekly meetings where each producer brings up their top three project risks and asks for guidance from the group can be very useful.  Useless meetings are wasteful.

Prominently post goals/dates/values within the physical project space: Osmotic communication envelopes the team to ensure that no team member is confused about the macro goals.  Put up posters, monitors, etc. to help keep the goals on the forefront of the team’s mind.  Face to face, personal communication is best and the most iterative.  Producers must take all opportunities to communicate the goal expectations to the team and stakeholders. Uniformed team members create waste.

Seat people working on highly iterative and collaborative features near each other:  Team members working on the same feature, especially if it’s unknown and exploratory is critical to their success.  Eliminate as much walking as possible and ease collaboration.  The more unknown the feature, the closer they should be.  Infrequent communication toward a focused goal creates waste.

Frequently communicate sprint, milestone and project goals face to face:  While posting goals and values on the surrounding team walls is supportive, personal communication is best. It is the most iterative. An email may take a day or more for a response but face to face discussion iterates in real time. Producers and Product Owners must take all opportunities to communicate the goal expectations to the team and stakeholders.  Communication delays via email or chat is waste.

Frequently communicate creative goals:  As with due dates, the creative expectations must be shared continually.  Generally, the “definition of done” lies with the Creative Director or Product Owner.  They must be vigilant in sharing their requirements…often. Misunderstood creative goals create waste.

Make sure the definition of “Done” is clear to all content creators:  One of the main roles of the Product Owner is to communicate their expectations surrounding a feature’s creative requirement and quality.  Fast, measured decision making is vital.  My continued belief (which is supported by Lean Six Sigma) is to follow the United States Marine’s “70% Rule”.  If you think your plan has a 70% chance of working you must execute as quickly as possible.  You can always adjust if it’s wrong.  I’ve worked with too many creative directors that wait for the “perfect” plan.  Navel-gazing creates waste.

Promote the value of transparent communication on all project related matters:  I’ve worked in many companies that held core data about the project closely.  They often felt the team couldn’t handle bad news or they might lose people to attrition.  Being open and honest is not only ethical, it’s also good business sense.  Teams must be fed the best information to help them work toward their goals.  Keeping secrets, in most cases, is a mistake and can fester into discontented teams.  Poor, infrequent communication creates waste.

Optimize the value stream:  The project pipeline can be one of the biggest waste creators on project.  Content creators must be able to review and iterate on their work as fast as possible.  Broken builds, long asset transfers, etc. can significantly limit the ability of the team to do their best work.  Long, broken value streams create waste.

Encourage content creators to show interim work:  No one likes to show work that is undone.  They may think that the reviewer doesn’t understand what it will evolve into or that they’ll get critiques about irrelevant issues the creator already intends to resolve.  The creator and the reviewer must develop this trust.  Frequent reviews on iterative work will help eliminate rework (waste) overall.  Showing interim work reduces wasted time.  Waiting to show work till it’s finished creates rework…and waste.

Attempt to eliminate rework resulting from creative review meetings:  This point is similar to the previous one, however the ideal situation is that NO rework comes from “official” creative review meetings.  This work should have already been reviewed and altered prior to the review meeting.  The review meeting should be a bureaucratic “stamp of approval”, not a meeting to explore the creative director’s lofty new ideas. On nearly every project I’ve worked on content creators have complained that they must wait far too long for their work to be reviewed.  Not only does this create waste in the form of idle time and possible rework, it’s a significant frustration for all involved.  The Product Owner must delegate reviews to trusted team members.  To do so, their requirements must be communicated clearly and their expectations must be established. Rework from infrequent creative reviews creates waste.

Streamline or eliminate meetings: If your team finds meetings useless you are probably not conducting them properly.  There are many, many sources that outline the best way to run them.  Proper agendas, specific questions to be answered, etc.  People generally dislike meetings and find they are a waste of their time.  Producers must study the many ways to hold effective meetings. Meetings should be about collaboration on solutions, not reiterating what everyone already knows.  Inefficient meetings create waste.

Hack, in the right circumstances:  Not every piece of code must be beautifully architected.  Sometimes the team gets more benefit from experiencing a feature hands-on, even if the underlying code is messy.  An agile adage states that teams should “fail frequently”.  This means the team must prototype quickly so that they may iterate toward quality as fast as possible.  Hacking code can get to an example feature faster.  Over designing and massive system creation before the feature(s) is well known can lead to waste.

Stalk and assassinate open questions: The team must continually stack rank the open questions surrounding the project.  The questions with the most impact and expected frequency should take the highest priority.  The features with the highest value for the customer (gamer) should be placed at the front of the line.  Killing open questions with religious fervor steadily removes uncertainty and risk from projects. Open questions are sources of risk on a project.

Focus work on customer needs:  Teams must be vigilante in making sure they are creating features for their customers, not themselves.  Activities that don’t directly correlate with customer needs should be removed.   Sometimes people like to work on their own pet projects despite the value for the end user.  Working on personal features that don’t align with the project end goals creates waste.


At the end of the day the producer’s foremost responsibility is to continually search for ways to make the project run more smoothly. “Kaizen” is a Japanese term from Toyota that evangelizes continuous improvement.  Producers, Product Managers, Stakeholders and Content Creators must always be on the hunt for ways to improve their work process.  It’s a mindset that must be practiced on all projects so that results can improve over iterations.


Lean Six Sigma, as noted earlier, is a very involved framework that includes graphs, equations, methods and techniques that are very involved.  Teams may only need to understand the principles to gain benefit.  More than a framework, it is a mindset.  Waste is a project killer.  The practice of finding and eliminating it is a mindset that all teams should embrace.   






Related Jobs

Red 5 Studios
Red 5 Studios — Orange County, California, United States

Graphics Programmer
Red 5 Studios
Red 5 Studios — Orange County, California, United States

Gameplay Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States

Server Programmer
Forio — San Francisco, California, United States

Web Application Developer Team Lead


Nancy Berman
profile image
Thank you for writing this article. If more people in our industry took the time to understand this process, they would see the value in its implementation. Too often, people think it's "too much work" when in fact it streamlines work, while others see it as a way to get "power" over other groups. A good scrum master is a facilitator, not an evil overlord.

In addition, the process supports the efforts of two frequently-disregarded aspects of game production: content creation and QA, both of which are crucial to the creation of a solid, successful product.

Implementing these techniques properly reduces crunch time and saves money, and who wouldn't want to do that?

Clinton Keith
profile image
Hi Harvard,

Another great article! While there isn't as much written about Lean game production as there has been for Scrum, teams have been applying these principles and practices since the middle of last decade. There have been several GDC presentations on Lean over the past few years as well. I think your article is a great addition in creating an overview of LSS.

From observation, I've found that Lean by itself is pretty vague about practices, while Lean Six Sigma can go a bit far. Kanban is usually a preferred approach for content production as it is not very prescriptive. Mixed with some of the Scrum roles and practices, Kanban is used pretty frequently.


Harvard Bonin
profile image
Thanks Clint. As always your comments add depth and solid elaboration to my articles. They are appreciated.

Bart Stewart
profile image
I've worked in a large (non-game development) organization that has undertaken LSS principles. My perception is that the core concept is good, but it can be very difficult to implement effectively. Like any action management system, it tends to crystallize over time into hard-and-fast rules enforced for no other reason than "because" by people who naturally like enforcing rules. The purpose -- delivering intended value -- gets lost as success comes to be measured by "did you check all the boxes on these forms."

In my own project management I've distilled the basic idea (before I ever heard of Lean or Six Sigma) into what I called the minimization of "unhappy surprises." Communication is key to that, and in two specific areas:

1. Direction: These are the goals you are expected to be working toward and their priority.
2. Status: These are the things I am doing to achieve those goals and the resources I need to finish them.

A continuous focus on those two things, with the relevant information exposed to team members and flowing up and down through appropriate tools (of which kanban is one formalization), doesn't eliminate every form of waste. But it has helped me meet project goals efficiently. And I think that's because it's effective at minimizing unhappy surprises while remaining simple enough to avoid creeping bureaucratization.

The downside is that this is so simple that it can seem invisible to people who like forms with lots of checkboxes. Results-oriented people won't care about it, either (how you get things done is unimportant to them), but at least they'll appreciate that you deliver expected results on time without a lot of fuss.

Then they'll expect you to do more of it, but that's any organization. :)

Alan Barton
profile image
@Bart Stewart

I entirely agree. I was trained in team leadership (in a military electronics industry environment, working to military standards, back in the 1980s), before concepts of Lean, Six Sigma & Agile etc.. became fashionable. But regardless of the methodology, keeping a good clear focus on direction and status of progress has always been key to navigating an optimal route to completing a project as efficiency as possible.

@"Then they'll expect you to do more of it, but that's any organization"

The irony of that is it wastes more time, so leanness gets undermined. I've found this enforced form filling in behaviour etc.. is often enforced by more insecure team leaders, who seek to use the higher visibility of forms (and big boards with nice coloured post-it notes ;) (rather than software tools), because big colourful boards on the wall and lots of paper stacked forms on a desk (in a big "Out Tray" implying they have already been processed (by an implied hard working team leader)) acts as a higher visible way to show upper management the (insecure) team leader is doing their job, when really its detrimental to true team lean efficiency.

A good warning sign is the form filling in behaviour is always termed as "to help the team leader" when really the team leader's primary role is to exist to help the staff, so they can get the work done as fast as possible. The team leader can get the best out of a team by getting problems out of the way of the team and minimising the admin burden on them helps greatly, so the team can focus on the work done as efficiently as possible. The team isn't there to help the leader with admin, the leader is there to help the team work as as efficiently as possible to get the product created ASAP.

This kind of insecure behaviour can be very detrimental to a company in many ways and even harmful to anyone on a team who tries to help illustrate ways to help the company because insecure team leaders will often shut staff down and even seek to punish them (often quietly out of sight of others) and even harass and so bully staff into their line and their rule. Its all done out of insecurity and fear, (they are afraid for their job in the eyes of upper management) but the key for upper management is spotting this insecurity and trying to alleviate insecurity in the company structure in every way possible including encouraging openness to speak about ways to improve things in the company in a way that allows all members of staff to speak freely. But then the insecure secretly hate this openness, because they fear it undermines their authority to rule over staff as their leader. Its a tough problem to deal with in some companies and harmful to staff.

It is these often hidden personality issues like insecurity of some team leaders that can detrimentally interfere with true team efficiency. A good team leader can be a joy to work with, whereas an insecure team leader can and often is hell to work for, but the insecure team leader rarely sees it in themselves. The irony is happy staff are less distracted than stressed harassed staff, who's health is even often harmed by dealing with an insecure team leader and so happy staff can focus more on the work more efficiently.

Its a very important hidden aspect in achieving true team efficiency.

sean lindskog
profile image
Alan, quote: "A good warning sign is the form filling in behaviour is always termed as "to help the team leader" when really the team leader's primary role is to exist to help the staff, so they can get the work done as fast as possible."


Harvard Bonin
profile image
Excellent post Bart. My intent was to relate the spirit underlying Lean Six Sigma. Removing waste is the focus but the detailed tools, metrics, etc. can be a bit much for my taste. Those with no understanding of it would be surprised at the depth.

I'm a believer that managers should use the tools that get the results, within reason. Waste removal, at least as a focus, seems worthwhile to me.

Anders Larsson
profile image
Great article! Call it what you wish, but waste minimization is i believe the most important thing in a project once the overarching goal and organization is put in place. This article made me think... I always enjoy that!!

Samuel Verner
profile image
"Lean: Focuses on delivering customer value efficiently above all other activities. Any activity that does not add value for the customer is removed from the process."

so does this mean you have to remove the development of monetization mechanics in a Free 2 Play game from the process?

scnr :-)

sean lindskog
profile image
Good article Harvard. I appreciate the melding of the high level ideas with concrete applied examples. The US Marine "70% rule" is one I hadn't heard before, and like a lot.

Harvard Bonin
profile image
The principles apply very well, I think. The plethora of tools and equations less so in the early project phases. In the concept stage an over focus on wasted time can be tricky since great ideas come from seemingly meaningless activities. Also, it might be perceived that unfocused work is a waste but the value of the team getting to know each other is critical.

PS. Check out my other article titled "Bigfoot." It contains a more exhaustive list of phases. In my view the term "pre-production" is overly used and applied. It can be broken down in much more detail.

Judy Tyrer
profile image
I agree with you that there are more valuable methodologies for game development than just SCRUM. And if you take LEAN and apply it to the pipeline then I'm okay with it, but defining the only work to be done as that which benefits the customer is not a definition I would use given how much work we need to put into tools to make our pipeline efficient. The customer never sees the pipeline.

You still aren't addressing the development cycle which, though. That is one missing piece of most processes and one we need to pay attention to.

Harvard Bonin
profile image
Thanks for your comment. Based on your definition of "customer" I agree with you. However, customers are not just the end user. They are the stakeholders and team mates as well. The team member using the tools created for them is a customer and should be treated as such. Total Quality Management subscribes to this belief.

Sandeep Kharkar
profile image
Very good article.
The correlation between the manufacturing terms in Six Sigma waste and GameDev are really well done.

My only confusion is that I can't think of a single game studio that requires people to wear uniforms.
"Uniformed team members create waste."