Lean and Kanban for Game Developersby Clinton Keith
It's common for game development teams to start the process with Scrum and in later stages switch to Waterfall, ending up with a combination of the two. Clinton Keith wants to introduce the ideas of Lean and Kanban to this situation. There is the possibility to improve such processes with Lean, without abandoning Agile practices.
The big difference between any Agile project and a game development project is, that typical projects begin with a release, whereas a game project is an ongoing work, ending with a release after several months or years. However, there can be 2 main phases of the game development content, that need to be distinguished. They stem from the way the games are being funded by publishers, and are: preproduction & production. In the preproduction, the team can look for the best ideas, iterate back and forth, but in production the process is decided and demands simply an execution.
Since the production phase works very much like a factory production line, there doesn't seem to be much value in applying iterative Sprints to it. But say you did, and at the start of a Sprint you commit to delivering a set of assets. Coming to an impediment in developing one of them allows you to simply move on to the next one. But, when the string of tasks needs to e completed in order, and all previous ones provide information necessary to work on the next ones – you come to an issue.
Let's try to apply this sequential process to a typical, simple Scrum board (Not started – In progress – Needs approval – Done). If only the first stage (game script) is complete and placed in Done, what needs approval is the concept, and the rest of the stages (level design, art, sound, tuning) will end up in Not started. Does this give any process visibility at all? No. On top of this it clearly shows, that each team section only works for some time of the process (and what are they doing in the rest of the time?).
More of Agile will add more efficiency
It's easy to see that in order to streamline this process, we need to forget about the iterations and bring more directive to it. At the same time, there needs to be room for unexpected changes. Here, Clinton introduces the idea of Lean to these processes. Just as with automotive production (where Kanban had begun) – there is a definite process here to be followed. Lean and Kanban concentrate on elimination of waste, continuous delivery and allowing the team to see the process as a whole, not just their fragments. Lean also underlines the need of constant improvement, leveling of the production – eliminating the unnecessary steps and optimizing the valid ones.
Kanban for games
It's a natural step then, to apply Kanban to game development process. By building the Kanban board in a way that will represent the actual stages of the process, seeing the progress at a glance will be easy. Once this is done, you can begin measuring the cycle time and making efforts to improve it. There are also other ways to make improvements.
One of the ways of improving the system is time boxing each of the production stages. Once a good estimation of how large a time box to apply, neither the quality will suffer, nor the team. The one to make the decision on how much time should be spent on one stage is the product owner, responsible for investment return, therefore needing to say what quality of a product he wants.
Leveling the workflow
In order to make sure that the team's work is balanced, ideally that people have always got enough to do, but not in amounts that cause the following stage workers a wait for completion. This requires managing the numbers of people assigned to particular stages in specific times. Although very demanding, it is within one manager's capacity to make the right decisions based on the information placed on a Kanban board. The perfect solution to this type of balancing act is a Heijunka board.
A perfect way to do this is asking the team's opinion on what is the biggest waste within the process. Good way of implementing this is simply asking the team to reduce their delivery rate by 10% (do it in 9 instead of 10 days) – surprisingly, what normally happens is – not a delay or quality drop, but own reduction of inefficiencies.
The greatest example of the scope to improve quality with Kanban is the original Toyota application of it (to mange stock replacements). Thanks to not having a great amount of stock, by detecting a faulty part in the system, it was easier to replace it and therefore improve the quality of the product. This is how they are now known as high quality, reliable cars, and are easily overtaking all markets. By quickly reacting to a defect, it is easy to improve the entire process and to do it effectively. And each improvement, as well as a waste reduction, brings a cycle time reduction along with it.
Clinton's team had applied all the steps described above and managed to reduce their game development process from 16 to 7 weeks, without making any costly technological alterations. And this was at the very beginning of making these changes. The key to making this work for you is tailoring the process to suit your environment, respond to changes well and implement great process visibility.
Read more about Heijunka boards in Game Development »
Read more online »