與其他知名媒體的同行一起，我有幸參觀了位於斯德哥爾摩的King工作室。這家休閒遊戲巨頭的代表作是《Candy Crush Saga》和《Farm Heroes Saga》。
下午5點下班。與遊戲行業的許多公司一樣，組成King團隊的成員具有各種各樣的背景。成員名單有很多是做過某AAA遊戲的人的名字。比如，《Pet Rescue Saga》的首席製作人Henrik Sebring在進入King的Malmo工作室以前是在育碧參與制作即將推出的遊戲《The Division》。如果你曾經做過AAA遊戲，你一定經歷過那種令人崩潰的時期——每一款遊戲在發佈前都要經歷的“關鍵時刻”。
怎麼做？雖然King旗下有多個工作室且每個工作室都有自己的項目，但King努力把所有工作室都聚集在歐洲。這麼做有兩非常明智的理由：一是工作室都處於相同的時區，二是工作室之間可以通過快速航班往返。假設你在倫敦的工作室做《Farm Heroes Saga》，你可能有一個創意想添加到遊戲中，但你不知道如何執行。因爲這是一款三連消遊戲，你打電話給身在斯德哥爾摩的首席製作人，看看他們有沒有試過。接着你接到通知這款遊戲的幾位開發者來倫敦跟你一起工作幾天，和你的團隊一起完善想法，看看是否可行。
篇目1，5 reasons you want to work at King
By Jim Squires
Along with a handful of other notable press outlets, Gamezebo was recently given the opportunity to tour the Stockholm studios of King, the casual games giant behind titles like Candy Crush Saga and Farm Heroes Saga.
We learned a lot about the business of being a leading cross-platform developer, yet despite all of the facts and figures thrown our way, one learning stood out above everything else: King’s employees are happy. Not just “there’s press here, plaster on a fake smile” happy, but really, genuinely happy. After seeing how the day-to-day operates, it’s not hard to see why.
You’ll be home by 5pm. Like many employees in the games industry, the teams that make up King have a diverse background. It’s not uncommon to come across names and faces that had previously worked on AAA games production. Henrik Sebring, the lead producer on Pet Rescue Saga, was working on Ubisoft’s upcoming The Division before heading up King’s Malmo studio. And if you’ve ever worked in AAA games, there’s a dreaded period that every title seems to go through right before release – “crunch time.”
When you work in the AAA/retail space, there are hard deadlines that need to be met. This can result in 120-hour weeks with people living at the office, only stopping to collapse from exhaustion.
It’s a terrible reality, and it’s one that King doesn’t have to worry about. By working in the social/mobile space, King can set their own deadlines. Products are never final at launch, and if something isn’t quite polished enough, they can always move dates around. Because of this, you’ll always be home in time to enjoy quality time with your family.
Teams don’t compete, they collaborate. When a company has multiple teams working on multiple projects, all too often they see it as a competitive environment. Team A wants their game to sell better than Team B, and vice versa. It’s not an environment that’s conducive to making your game the best it can be. And while the different teams at King admittedly want to see their product become the next Candy Crush for the company, King’s entire structure is designed around collaboration and sharing.
How so? While King operates a number of studios, each focused on their own games, they’ve made an effort to keep all of those studios in Europe. There are two very smart reasons for this: everyone will be working in the same time zone, and no studio is more than a quick flight away. Let’s say you’re working on Farm Heroes Saga in King’s London office. You might have an idea that you’d like to add into the game, but you’re not sure how it will perform. Since it’s a match-3 game, you pick up the phone and call the lead producer on Candy Crush Saga in Stockholm to see if they’ve ever tried it. The next thing you know some Candy Crush folks have just landed at Heathrow to spend a few days with you, fine-tuning the idea with your team to see if it can work.
The corporate culture isn’t about your game doing well – it’s about King doing well. That means everyone is on the same team, regardless of the studio and game you’re tied to.
Failure is totally an option. Making games is a hit or miss proposition in the most literal sense possible. Some games will be hits, more games will be misses. King both gets and embraces this fact. They have a team in Stockholm whose entire job is to dream up ideas for new games. Let that sink in for a minute – King has professional daydreamers. When they hit on a formula that they want to try, they make a web-based game for King.com – their “tournament” site that doubles as a testing ground for new ideas.
If a game performs well on King.com, they’ll know its future in a matter of days thanks to the magic of analytics. I won’t bore you with the details, but there’s a formula that will tell King whether or not a game should graduate to “Saga” status and get a deep-and-detailed remake for Facebook and mobile. Very few games get to this point – and that’s ok. Trying and failing is how we learn; this is a fact that’s as applicable to a games company like King as it is in our own lives.
Studios don’t have more than 80 people. Remember being in elementary school, how you knew all of the names of the kids in your grade, and the grades above and below you? Welcome to King. While the company is growing at a breakneck pace, they’re committed to keeping individual studios small enough that everybody knows everybody else. We were told that no studio should have more than 70 or 80 people. Why? I suppose this loops right back to the earlier mentioned positive: the culture of collaboration. If you know who everyone is and what everyone does, there are fewer roadblocks to saying “hey Lars, come take a look at this new level I’m designing.”
This muffin. I didn’t ask them about what their day-to-day catering is like, but if this muffin is any indication, it’s insanely good. The white part was kind of a white chocolate/cheesecake thing, and the inside was like a chocolate soup. It was so gooey that I eventually had to use the paper sleeve to squish it into a taco.
Walking through the studio at 9am, I saw more than a few folks gathered around a pretty great breakfast spread, taking a quick meeting as they enjoyed some communal food time together. And really, it’s this vibe that sums up what King is all about. This doesn’t seem to be the sort of studio where you rush in and tie yourself to your desk. It’s about good working relationships with the people around you. You collaborate; you listen. You enjoy a good breakfast. And maybe, just maybe, you make some amazing casual games in the process.
篇目2，The keys to a company culture that works
by Christian Nutt
In a heartfelt talk at GDC Europe, Harald Riegler, co-founder of Sproing, frankly discussed the challenges and advantages of shaping a company culture that leads to respect and success.
“The right company culture will bring really good things out of people where you didn’t expect they existed,” says Riegler, who manages a company of 65 that works on free-to-play and console games in Austria.
Unfortunately, he says, forging the right company culture is a challenge — but it’s crucial to shape it, and that every team member understand it.
“That culture will largely decide the success of the studio or team,” says Riegler. “A bad company culture can even destroy teams completely.”
While “the latest million-selling management style” books offer advice, Riegler was dismissive of trends and tricks. “The really important thing is… that it’s entirely about human interaction, the characters of the humans, and their behavior,” he says.
“A good company culture is built on some lasting principles — principles, to me, means more than a set of rules, it’s a foundation on how you live and how you act,” he says.
“Working at it day by day, week by week, year by year is required to improve your company culture,” he says, however, so be prepared to commit fully to change.
Here are his principles:
“To lead any group of people, you need an innate respect for people,” says Riegler. If you don’t respect everyone you work with, he says, “I feel you’re doomed to fail from the outset.”
“If you feel superior to people,” he says, that comes across. “Body language is most of our communication.”
“Such respect leads to an environment of trust, and trust is really important because only in an environment of trust can you address tricky things. You can bring stuff out into the open that nobody wants to talk about,” says Riegler.
Lead by Example
“Every [parenting] book says that if you want your children to do something, you do it yourself,” says Riegler. This applies to companies, too, he says.
And the reverse is true, too: “If you don’t want somebody to do something, don’t do it yourself,” Riegler says. “Never ask anybody to do something you’re not prepared to do yourself.”
“This is where it gets really tricky,” says Riegler.
“It’s often confused for just holding your subordinates accountable,” he says. But as a manger, Riegler says, “the only way, in my opinion — and that’s something I absolutely believe in — you an introduce accountability into organizations by making yourself accountable first.”
How do you do it? “You have to tell people what you’re setting out to do,” he says. “You have to be willing to benchmark yourself.” And then finally, “you have to be prepared to stand there and say just how successful you have been, which isn’t easy, because rarely do you achieve everything you set out to do.”
“Maturity does not mean that you’re super-experienced, that you’re an elder statesman,” Riegler says. “Maturity to me is the ability to self-reflect and have a clear understanding of what your strengths and weaknesses are, and what you should be working on, and where you should grow.”
Unfortunately, he says, “a lot of people don’t really do well here, because it requires an honest reflection on your personality, and that can be uncomfortable.”
However, he says, bear in mind that “the best contributors can understand the challenges your team is up against,” and having that self-honesty and self-reflection is key for that — it’s not just about improving oneself and having a better outlook; it has a meaningful effect on the team and the business.
Then again, he says, there are divas, backstabbers, and power players. “Beware of all these kinds of characters; they’re very damaging,” Riegler says.
“I think fun is really important,” he says. People could probably work in other, less interesting industries for more money, he says, so in the game industry, fun is key.
It isn’t, however, an environment that isn’t professional, or one that’s lax, he maintains. “Sometimes it’s perceived as laxness — young people confuse fun with a lack of seriousness or ambition,” Riegler says. So have your foosball tournament, but make sure the goals of the company are clear, too.
On the other hand, “maturity does not contradict with being crazy” — being weird is part and parcel with the culture of the game industry, he argues, so be open to it.
“Freedom to decide how to solve a task,” Riegler says, is key — “not being micromanaged.”
“To come and go at flexible hours, to take some time off to deal with family issues and what have you,” is very important. “Freedom leads to a lot of autonomy of every person, and an environment of trust supports such an autonomy, and autonomy leads to motivated people,” Rigeler points out.
This is one of the most important elements, but also one of the most challenging. “If something went wrong, admit it. Don’t be afraid,” Riegler says. “You have to a culture where admitting failure is accepted.”
What won’t work, he says, is “a blame culture.” When you have one of those, “a lot of stuff that is important will not come out in the open,” Riegler says.
Why don’t people want to be honest? “It’s all because people are so afraid to deal with failure,” he says. But you have to recognize that “we all screw up every once in a while.”
If there’s a culture of open and honest communication, “people on the team who are smart will spot you are screwing up, and they will point it out and they will stop you from costly mistakes.”
But he did have one warning: if people are always brutally honest about what’s not working, “you may fall into the trap of becoming hypercritical,” which leads to pessimism. “But you can’t lose faith.”
“The common awareness in every person that the culture is important and the way we interact sets the culture for success is really important,” says Riegler. In other words, “Everybody has to understand these principles and live by them.”
What you have to recognize is that “everybody has the ability to improve.” However, he says, “You can’t just go out there and tell people to improve… that’s not how it works. It’s a really slow process.”
“These principles are not worth much if they are not enforced by everyone,” says Riegler. This is from the bottom to the top of the organization.
“If you tolerate someone ignoring the principles in the organization, what does that mean, that you can get away with that? Then people will understand they are not really principles, and that will be very harmful,” he says.
At companies without an open culture, he says, “a lot of times people are impressed by people who speak out in a meeting and say ‘This is going wrong,’ and you wonder how they do it, and that’s because the culture makes this stuff hard to bring out into the open,” he says. But if you shape a culture built on mutual respect, accountability, and communication, “more people can do that, and everything improves.”
“Your ability to self-reflect on what your strengths and weaknesses are will make you really valuable,” he says. “You need to find like-minded people and you can build teams that can survive in our day and age.”
篇目3，Managing risk: The creative gamble
by Florian Schwarzer
Here’s a nightmare: Build the best team you can, work hard for two straight years, release a well-crafted game – and watch it fail in the market.
Here’s the crazy thing: We work in an industry where that nightmare comes true somewhere every day.
Surprisingly, we don’t talk about this very often. Even those of us who carry ‘business responsibility’ over our games seem to avoid the topic. There’s valuable discussion of development processes or leadership strategies, but little time is spent on how to deal with the great volatility of our products. Often, you’ll get the impression that we’re improving at releasing games on time – but not at ensuring their success.
Can it be that this is because what is at the heart of a successful game is radically different from what makes or breaks other software?
For a long time, our project management has looked to IT for its cues, and what we learned from there has enhanced our way of making games. Still, I would argue that there are limits; challenges we have to face that other software managers will never see. Most of them start with two words: game design.
THE SMALL DIFFERENCE
Games try to entertain. This sets us apart from traditional software, like eshops. It also means that we run the same risk as any movie or novel: Our audience might just not find the game appealing. Researchers call this ‘creative risk’.
As managers, we usually think of risks as threats to be minimised, or, in the worst case, mitigated. One has to wonder: Is the same possible for the risk of people not having fun?
Fundamentally, a big part of what makes something entertaining is down to curiosity. We like new things. This will be news to nobody – pretty much every game tries to offer some degree of novelty to its players. We search, we build, we advertise fresh new features, whether in an experimental title, or a sequel.
ON GREAT GAMBLES
There’s a problem, of course: What may seem original to me, can feel trite to you. Even individually, it can be very difficult to predict whether a game will meet our tastes before we try it. For a whole audience, it becomes effectively incalculable. Just consider how often century-old Hollywood gets it wrong.
Intuitively, this means that it’s a bad idea to take a lot of creative risks. After all, if we release a product that’s different from anything that’s come before, there’s a good chance it’ll miss everyone’s tastes, right?
True, but our players still really like new stuff. Games like Portal or Wii Sports show that if you take the risk, and manage to connect to your audience, the reaction can be tremendous. Creative risk is speculative – its outcomes can be negative or positive.
Of course, it is possible to build an entertaining game around a relatively conservative concept. Take StarCraft II, a careful extension of a well proven game. Then again, take the guitar game genre. There, we have a group of very well executed titles that got too conservative – and saw their audience move on. Taking no creative risks is a risk, too.
In the end, no matter what kind of game you build and how well you build it, all you get is a roll of the dice. The game’s USPs, the very things that can make it succeed, will carry the greatest, most central risks. Accordingly, there’s nothing we should take more seriously in our plans.
DOES IT WORK?
Obviously, if we want to help our game designers deal with risky features, we should help evaluate them. Just as obviously, it’s a good idea to make these features testable as quickly as possible.
The good news here is that every discipline involved in the creation of games has found its own ways of quickly prototyping and testing ideas. Based on those, it seems pretty easy to set up whole test plans. Say, you start out by testing a paper draft of a new feature, graduate to UI mock-ups, logic prototypes, and eventually release a fleshed-out version on a beta server. Such plans are hugely attractive. They reassure the team and stakeholders. Also, they don’t work.
Partially, it’s down to time. Way too often does a team invest into elaborate tests, only to discover that there’s no room to fix what is broken.
Things can get even worse, though: User tests, by their very nature, produce messy data. It’s easy to come to rivaling interpretations, and thus solutions. If a major stakeholder subscribes to such a differing view, the game designers may quickly lose control over their own concept.
THE LIMITS OF AGILE
To avoid all this, it seems sensible to integrate large-scale prototyping more tightly into the development process. To my surprise, when I began consulting Agile experts on this, they told me it was a bad idea.
We all know the basic artifacts of Scrum and XP. You’ve got a backlog, with the most important stuff up top. You’ve got a sprint, during which a certain amount of stuff is supposed to get done. You’ve got a working increment, which grows sprint by sprint.
What a lot of us miss is that, as far as ‘traditional’ Agile is concerned, that’s it. No milestones, no gates. After the first few weeks, the most important stuff is in. Then, with every sprint, the team will be able to release something better.
Following that logic, it’s a waste to spend a sprint building a prototype that may get discarded or even lead to a rework of stuff that’s already done. Setting up whole plans full of that? That’s missing the point.
For B2B application development, the environment Agile was built for, that’s true. There, it is possible to ensure that what is at the top of the backlog is also the most valuable for the user. In games dev, that’s the very thing we often can’t be sure about.
THE ROOT CAUSE
What this means is that to accommodate the creative risks of our games, we must tailor our processes in ways unique to our field. We don’t know whether our most central features are valuable to the player. We only hope so.
To me, those features – and the degree to which they are proven – should drive a project. At the root, this means accepting that each of them will be reworked many times. In my experience, one shouldn’t plan with less than 60 per cent of feature-specific contingency here.
More challenging: We have to acknowledge that there will be controversy. Here, it can help to have the game designers prepare while they are defining the features in the first place. Ask them to name ways by which to tell that the feature doesn’t work. It provides the designers with a degree of ownership over the tests, and sets a reliable yardstick for any discussion.
Finally, we have to give our stakeholders a fair chance to take influence. For this, it’s sensible to set milestones after major tests. There, you will have learned something important about your project. Thus, if necessary, it’s the ideal time to discuss changes – whether that means budget extensions, scope adjustments, or the dreaded cancellation.
That’s another thing we don’t talk about. But if we take creative risk seriously, it’s a step we should always consider. It’s always possible that what sounded fun on paper doesn’t really work out. Pressing on nonetheless – now that’s inexcusable.
篇目4，Opinion: Communication Is Key
by Lee Winder
Successful communication is one of the most important aspects of a well functioning and productive team. Without good communication between peers, managers, publishers, and anyone else involved in the game development process, a team will not perform at it’s best.
If developers do not feel confident in the reasons behind their work, if they don’t fully understand how their work will fit into the project as a whole or indeed when it will be required, the team will produce lower quality work with last minute changes and requirements fostering an atmosphere of distrust and crunch.
But communication is one of the most difficult things to get right but so costly when it’s done wrong.
The following are methods I’ve used over the years to try and improve communication within the team. I’d be very interested to hear other ways people have tried too!
Having an open Wiki that people can contribute information and notes is a good idea for documentation and persistent information. It is not a good tool for perishable short term information.
Documentation on team processes (getting the latest build, creating submissions, setting up PC’s etc.) is usually the kind of information that finds a home on a wiki, and while it’s useful, it’s not something that affects the team on a daily basis. And as it requires people to physically search for the information in the long term people don’t bother looking for new information on a regular basis.
As a result, the Wiki is useful but doesn’t actually improve the day to day communication on a team.
We have a team blog that people update about 2 or 3 times a week, usually discussing their recent work, posting up screenshots or letting people know the state of the project. It’s a nice simple way to push information to the team, though it does require everyone to contribute to the blog to get good cross team communication going.
Discussions can take on a life of their own, which is actually a good way to gauge buy in into a project but can’t be used to judge the success of the process.
But you’d be amazed how many people don’t have any kind of RSS feed reader set up…
Internal mico-blogging tools like Yammer or Status.net allow people to quickly thrown up what they’re working on, problems encountered or general team information. The best thing about micro-blogging is it’s push communication style with people’s updates being automatically feed to clients, which people can update as much as they want (I usually recommended at least twice a day).
But so far I’ve had very little success with micro-blogging tools in a team environment.
Not because the idea was bad (when it worked it worked well), but I’ve yet to find a service where the official client is anywhere near usable and able to filter out the information people don’t want to read. Without a good way to filter and push information where you want it (like all the best third party Twitter tools do), it either becomes an information overload or a sea of noise, neither of which improves communication.
Walls are valuable real estate, especially in an Open Plan office, and I’ve rarely seen them used to their full potential. But highly visible walls in the middle of a team area are one of the best ways to communicate information across a team.
As an example, on my current project we have the entire timeline of the project (it’s only a short one) with dates/deliverables clearly indicated, a ‘where we are right now’ marker and a description – feature by feature – of what is required for a given milestone.
Next to that, we have our sprint wall, which is our most ‘live’ wall display. But position is key, and in our case, the sprint wall’s impact on the team is reduced due to it’s rather awkward position between a big TV, a constantly spinning fan, and quite a lot of server machines. But I did say wall space is valuable real estate, and it’s always hard to find a compromise between distance from team and accessibility.
Morning meetings are one of the best ways to push information across a team, but I’ve found that you need to follow a few rules to make them really valuable.
Keep the groups small. I’ve lost count of the number of 20+ people stand-up meetings I’ve seen where the majority of the ‘participants’ are looking bored or simply waiting for their turn. If your groups are not small, the information is less targeted and much less relevant, meaning more information is lost than actually passed around the team.
Keep them focused. There is nothing worse than 1 out of the 6 people speaking for 15 minutes about the most intimate implementation details, leaving everyone else itching to get back to their seats to carry on working.
Don’t make them reporting sessions. If everyone is talking at a single person (usually their manager), take the manager out for a while and get people used to talking to each other as it makes it much more likely for people to take in what is being said.
I love the concept of a milestone review. Everyone playing the game, lively discussions about what went right, what went wrong, and what we can do better next time. But it’s easy for these to be less than stellar if not approached in the right way.
If these reviews are not focused, maybe even as structured as a schedule or points to cover, people may start to feel unsure as to what they can comment on or what exactly they should be doing. You’ve also got to make sure that people feel comfortable both giving and taking criticism and manage the situations when that goes pear shape (and sometimes it will).
I’ve found that when done right, when people contribute to discussions and when people can (importantly) see change as a result of these reviews, the quality of information coming out of them is invaluable. It also has the added bonus of making people feel like they are making a difference to the team and allowing their thoughts to be heard.
The days of managers sitting in a room building up a schedule and dishing it out to the developers is (almost) long gone. And there’s good reason for it.
Getting a group of developers (again with the morning meetings it needs to be small and focused) to discuss, schedule and plan the work ahead significantly improves the knowledge people have of what is happening across the team.
Again, if people feel that have a say in how work will be implemented, how it will be assigned and when it’ll be done by is vital to spreading information about the project and the work being done.
So those are a couple of methods I’ve used to try and improve communication and information across the team. I’m sure there are plenty more (and I’ve tried a few which have been colossal failures) so what methods have you used and how well did they work out?
篇目5，The Elimination of Waste: Lean Six Sigma applied toward Game Development
by Harvard Bonin
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 PRIMER
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.
WHY WASTE MATTERS
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.
THE TWO DEADLY SINS
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.
TIM WOODS: THE EIGHT KINDS OF WASTE
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?
TIM WOODS: APPLIED
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.