Clinton Keith, long-term industry guy and the person who introduced Scrum to the industry, mostly through his company High Moon Studios (though he now works as a Scrum consultant). He introduced his talk by telling us he wants us to get good info on good and bad myths about Scrum before you take it on, as well as the kernels of truth that gave rise to those myths, and what the real experiences of teams shipping games in Scrum are.

First a quick overview of the process:
Start with a list of prioritized features (owned by a project director). We sprint to develop portions of these features in 2-4 weeks, taking things that are most important to the consumer. And we break those down into a “sprint backlog” of parts of those features we think we can implement, with the goal of an incrementally improved game at the end of that sprint, which goes back into the product backlog from which our overall feature set is drawn.

Daily scrums: everyone gets together to talk about the goal, getting that feature in, what’s holding it up right now, etc. (These are the 10 minute stand-up meetings you might have heard of.)

Scrum teams are usually cross-disciplinary — a little from every department. In addition, there’s a scrum master, who isn’t a lead but who is following the process rules of the scrum (what they agreed to). The product owner (publisher, internal director) — prioritizes the backlog, etc, and communicates vision.

Scrum: “Silver Bullet” Myths
Talks about various “silver bullets” which have been applied to programming along the way — object-oriented programming, CASE tools, automatic programming, and then used that as an intro into what myths have popped up around Scrum.

Scrum Myth 1: “Scrum doesn’t require competent leadership! It’s self-organizing!” (this makes me think about self-documenting code…) — he found you still need leads to mentor people to help people to understand their role in the organization. For agile teams, though, we’re moving from directed management (where in our industry the best people get taken out of what they do well to “manage”) to facilitation (best people serving as an example and mentor).

Scrum Myth 2: “Scrum will prevent problems.” No. You always end up with problems. The benefit of scrum is that you have transparency as to what your problems are — it finds everything that impedes productivity. Unfortunately, one common problem is that people associate those problems which are uncovered as being a result of Scrum itself, when they are more likely simply made more visible by the process.

Scrum Myth 3: “Scrum can achieve impossible goals.” If you already have impossible goals, adding a new process probably won’t help. However, it might help you realize just how impossible they are (and therefore fail faster), which may be cheaper for you in the long run.

Keith next addressed things that prevent people from adopting Scrum, what he calls the “fear, uncertainty, and doubt” myths.

Uncertainty: Endless iteration. “You’re always iterating with Scrum, you’re never getting closer to the goal.” Keith points out that that’s true, if you don’t have someone who has the vision to make sure you’re doing the right things. Agile planning is more about moving planning to the center of development, rather than a specific plan.

Doubt: “Scrum is just another management fad.” Scrum ideas, agile ideas, have been around for more than half a century. It’s been an evolution, though it finally got a name in the mid-80s. It has been a process of returning a fair amount of leadership back to individual craftsmen, rather than the assembly line process introduced by Henry Ford.

Fear: “It’s scary to change our process.” However, Keith notes that our industry has seen huge external changes that have led to internal changes in our industry — new platforms leading to bigger teams. But we didn’t really change how we did things, we kept writing big design documents first to plan everything out. But that didn’t keep us from being late or overbudget, and yet we’d still go back to doing that. Big plans up front didn’t work, but we’d still do them.

Keith moved into some more anecdotal development experiences.

He noted that Scrum can be a tool for changes in culture — if you have to have a playable game every two to four weeks, it forces you to make your practices more effective. It pushes more into data, and you get more feedback.

The big thing about adopting Scrum is that you need to be aware of the underlying principles. You need to focus on value — and tracking tasks are only useful for knowing what you’re doing to increase value (better gameplay, better looking environments, whatever). You should only change away from the existing Scrum methodology once you’ve done it long enough to understand the principles it values. He showed clips from Karate Kid — in which our young hero Daniel does a bunch of menial tasks for Mr. Miyagi, not knowing why, and comes out able to block Mr. Miyagi’s various attacks without really thinking about it.

Keith next illustrated that the practices of Scrum aren’t the value of Scrum, they’re just a way to show the underlying values you’re trying to achieve. (He talked about cargo cults which sprung up after World War II — google it, I’m not going to repeat it all here. Suffice it to say, making fake airplanes doesn’t give you the industrial knowledge to bring all the trinkets that the real planes brought.)

He then showed a roadmap for improvement — starting out as an apprentice, becoming a journeyman, and ultimately a master.

Scrum is best for pre-production — in identifying where the game fun is, so that you can then go into production and replicate that information across the game. He noted with an example that once you’ve identified a jump height and length in preproduction, you don’t want to alter that in production and end up having to move every ledge and change the spacing on every obstacle. But it’s good for finding the fun in an iterative way. Shorter term milestones with not a lot of longer term milestone and production detail to “find the fun” might be a good way to begin a developer/publisher relationship, with the idea that eventually you’ll be in a position to know that you can build the full game and get a full production contract at that point.

The goals of scrum are to focus your culture on the following things: delievering value quickly and early, continuously improving your game, transparency and communication.

Presented by Clinton Keith, CTO High Moon Studios.

Since High Moon has started using Agile methodologies, cross-discipline team collaboration has been a hot topic. Clint addressed the Goals, Impediments, Solutions, and Tools which relate to cross discipline collaboration.

Agile isn’t about process — it’s about leadership. Its goals are reducing waste and making products (i.e. games) better, cheaper and faster. It’s also about collaboration and teamwork; the core of success.

It is important to understand that the people who make up traditional game teams — artists, designers, developers — speak different languages. They need to learn to understand each other, and a great way to do this is to bring them together. That leads to questions about organizational structures, which in themselves can detract from collaborative efforts. Rewarding your people because of their skills instead of their teamwork or collaboration abilities is fine, but can result in silos where people don’t need to collaborate. Clinton showed a diagram showing the lengths people go through in a typical organization to get a bug fix.

Impediments such as team size are major problems — sizes between seven and eleven are optimal, but most console game projects require 50 or more people. The schedules for all of these teams MUST match for success, but they never do. The small size is key here because it keeps problems manageable. The flow of work is another place where too many people and parts causes problems. Resource constraints, dependencies and so forth prevent solid progress and demoralize the team.

Another point that Clinton made is an astute observation about the overhead of hierarchy. Concentrating on roles and organization can easily lead to getting hung up on responsibility.

To solve these problems, a company needs to make radical changes. High Moon has an open floor plan where people can team up at will. An active work environment is promoted, and while it causes some chaos, it keeps people thinking and alive. Remove artifacts from spiral development process which reduce face-to-face time.

The Agile environment where teams have immediate focus (as opposed to the organization) offers a great amount of feedback for members of that team. People get ownership on the project, and they succeed or fail together. Anonymous peer reviews give people a chance to talk frankly about progress. Finally, keeping the team together whenever possible gives people a feeling of ownership, which is the most important sociological aspect of agile.

Clinton described a team building exercise where his team took a mountain biking trip to Colorado. He relates that the best way to get the team to work together is to save their boss — which he found out the hard way by falling off a path and breaking a rib. (Don’t try this at home, kids!) Of course, Clinton doesn’t recommend this at all, BUT it is clear that the team will learn together and bond together when they understand there is a common goal to be solved.

Play testing on games gives focus on specific issues — the team gets to see the enjoyment or disappointment of real consumers. This is invaluable since they give the kind of feedback that the team can’t provide

Solutions are many, but one of the most important is to clearly define roles in the company. What does a game designer do? What areas and responsibilities do they posses? Without an equal footing for all of your team members, there will inevitably be questions and possibly even strife.

So what is “Agile”? Clinton described different ways to approach an Agile development environment. Bascially, the goal is to add transparency to your organization and allow you to act upon problems. You can be the most transparent company in the world, but if you aren’t fixing the problems that surface, you aren’t Agile. Scrum, for example, comes from the sport rugby. It’s being used primarily as a software development tool, but it has been used in manufacturing and other areas. When it comes down to it, Scrum is a box of practices that work together — try not to break the way that they fit together.

High Moon has used Scrum as a development tool, but what about art and design? What tools can be used for those groups? They have found that Lean and Kaizen (“continual improvement at every level”) offer a solution for all groups. Kaizen assumes that something always needs fixing, and that improvement of the whole often requires a cross-discipline approach. The “Stop the line” mentality improves quality and makes life better for everyone.

Clinton discussed Value Stream Map tools. These allow you to visualize the flow of real work so that you can reduce waste and cycle time. More collaboration means fewer hand-offs, and the shorter path means fewer things in play at the same time. This process allowed them to take a 16-week cycle and turn it into a one-week cycle, that produced 1/7th of the assets. That’s a 44% improvement in output! Best of all, it was driven by the artists and designers and required no new technology.

In summary, every culture is different and while the prinicples are the same, you will find that some things work and some things don’t in your environment. Pick a metric to focus on and follow that — for example, the daily ratio of stable builds from the continuous integration system. Take that data and make it real by displaying it to the team, and give them a chance to improve it, and to take responsibility for the improvement.

www.agilegamedevelopment.com — Clinton Keith’s own Agile game site

www.lostgarden.com — Daniel Cook’s site for XP for game development

www.projecthorseshoe.com — site for the 2007 Project Horseshoe conference