Scrum as a tool for process and cultural change

Any process can be used to make games, but no process is perfect. Even if we were to find a perfect process, the constant change in our industry would make it quickly obsolete. Scrum is not a process, it’s a framework for creating your own process. It can help any organization create transparency which enables competent leadership to react to change with common sense.

When we first adopted Scrum, every few months we kept observing how things had changed. “When are we going to reach our goal?” we thought. It turned out that you never reach it. Your culture has to come to terms with the fact that there is no process goal. It’s about change and that change is continual.

Take for example a studio culture that was ruled by technology. Games were seen as platforms to demonstrate technical achievement. Tools and pipelines to improve productivity for artists and designers were always lower on the list of priorities because the programmers were always trying to dig their way out of the holes they created trying to accomplish impossible challenges. The build was rarely working due to all the bugs left along the way.

How did Scrum and agile change this? First it made broken things visible. They needed to have a working, and even potentially shippable, version of the game every two to three weeks. This raised a lot of problems. At first the teams spent half their sprints trying to cobble together a working build. This killed their velocity. Since velocity is only measured by the value of the features working in the game.

This simple measurement of velocity is important. Scrum relies on a simple psychological fact; people behave based on how they feel they are being measured. Scrum measures based on the value to the product added by a team. Teams make small changes to improve velocity. Our example team did this. They started to come up with ways to improve the reliability of the build. Because velocity is based on what is seen in the game which includes art and design, they started to form cross-discipline teams to improve their velocity. Because of the overhead of communication when the team sits apart, they moved together into the same area. Because the programmers began to see how the poor tools and pipelines impacted members of their team, they focused more on improving those things.

All of these changes occurred within teams that took ownership of their work. The role of management during all this was to facilitate the change. This is the hard part. This requires management to step back where they traditionally step in. A manager needs to become like the coach on a football team. They can give feedback to the players, but once those players are out on the field, it’s entirely up to them on how the team performs.

Does every team adopting Scrum see this kind of benefit? Absolutely not. Scrum is a tool for the team to build change their process and possibly their culture. It's like owning a hammer; it won't guarantee you will build a great house, but it's a nice tool to use when building it.