Why Isn't It Easy?
Although the average ratings were positive, surveys of agile outside the game industry have also shown that a large portion Scrum adoptions fail to achieve their full potential. It's difficult to gauge what Scrum's "full potential" really is. In fact, it's definitely designed to help create successful games by great teams.
When developers talk about making a successful game, they often mention the "great team" that made it. Great teams can form in any culture or using any methodology. They are hard to define, but some of the following points apply. Great teams:
- Follow a shared vision and purpose: Everyone on the team understands the goal of what they are working on.
- Complement other team members' skills: Team members depend on each other to achieve their goals by applying their unique skills to a shared goal.
- Exhibit open and safe communication: Team members feel safe to communicate anything to one another.
- Share decision-making, responsibility, and accountability: The team succeeds or fails together, not as individuals. Everyone earns their spot on the team daily. There is no room for titles or egos.
- Have fun together: They spend time together and enjoy each other's company. They care for one another.
- Deliver value: Great teams take pride in their work and deliver high value consistently.
- Demonstrate shared commitment: Great teams have a unified cause. When one member has a problem, the entire team will pitch in to help them out. As a result, great teams deliver value because they focus on the whole rather on their own parts. Great teams are committed to their goals. They'll go the "extra mile" to achieve a goal that they believe in.
These attributes sound good, but they aren't the result of any process. The people and the culture of a studio enable them. The goal of Scrum principles are meant to be a framework for organizations to foster great teams, but the hard work belongs to the organization. There is no set of rules and no methodology that can replace that.
So how do implementations of Scrum fail to achieve that? Let's look at some of the warning signs reported:
Is micro-management destroying self-management?
- Is management forcing a top-down adoption of Scrum and focusing on the practices alone? Teams need to focus on the principles of Scrum while slowly taking ownership of practices to improve how they work.
- Does management allow the team to commitment to what they can accomplish? Teams should slowly take on more ownership of task estimation and achieving goals. This takes time and requires trust to be built, but increased commitment pays off.
- Are the agreed upon practices ignored when they are inconvenient? Are sprint goals being regularly changed? Nothing will destroy a sense of team commitment when this happens. Sometimes business reality has to trump sprint goals, but there are practices that allow that to happen without the damage it can cause.
Are the organizational challenges too great?
- Are teams being tossed in the deep end of the pool without a swimming lesson? Is the studio deciding to use Scrum without careful consideration and study? Perhaps one team should try it first to see if it will work in the studio culture. Skepticism is good. Proof is better.
- Is leadership supporting the change? Teams shouldn't go off on their own to experiment with Scrum. Leadership needs to mentor them and ease them into their new responsibilities (such as estimating tasks). Poor leadership is poor leadership under any methodology. If teams aren't provided with a vision or have no guidance and mentoring from experienced leaders, don't expect them to succeed.
- Is the studio "inspecting and adapting" practices through retrospectives? Doing a daily standup alone isn't enough. Continual improvement requires continual inspection and adaptation.
Is the dogma messin' on the Lama?
- Is goal to be "agile" and not finding ways to improve the work? The question shouldn't be "Are we doing Scrum?", but "Are we continually improving how we're working?"
- Is an agile enthusiast telling teams "this is the way you must work"? Nobody likes to be told exactly what to do. Teams need to explore what works best.
Does agile mean I don't have to eat my vegetables?
- Is the team using agile as an excuse not to plan? Planning has a bad rap because the "big documents up front" approach doesn't work so well. Agile teams that abandon planning in favor of pure iteration fail a different way. It's called an "iterative and incremental death march". Agile teams should spend more time in planning. The only difference is that planning is spread though the project.
- Is the team measuring key metrics? If teams don't measure their velocity and gauge changes in practices against it, how do they know if they are improving? Some say that it's impossible to measure the size of features, and therefore impossible to measure velocity, but then, how are ironclad schedules being justified? What are the other things that can be measured to help teams explore improvements? Iteration time? Build stability?
Is a round peg being driven into a square hole?
- Some publishers refuse to allow much change to the contracted plan. They've been burned by "iterative and incremental death marches" and can often be put off by the mention of Scrum. However, "rolling milestone definitions" and other similar contract/project "tools" have been used for a long time to allow some flexibility to exist. Studios have to slowly build trust with publishers and their own teams over time to allow more flexible scope, but that shouldn't prevent teams from finding better ways to work.
- Are practice changes creating "ScrumBut"? ("We're doing Scrum, but...") Is a practice being changed to improve the work or to hide a problem? If you are thinking of adopting Scrum, watch this video first.
- If your studio is adopting Scrum, do any of these warning signs apply? If so, they should be addressed. You may not end up with "great teams", but it won't hurt your chances.
In the mid '90s, our new studio was working with Shigeru Miyamoto on a Nintendo 64 launch title. We implemented many of his odd ideas and followed his mantra to "find the fun". One of Miyamoto's talents was to try to quickly prove or disprove something and build on what worked or abandon what didn't. We never felt like we failed him when we couldn't find a way to make one of his ideas fun on the hardware.
We didn't call ourselves "agile" at the time. We felt like we owned our methodology. Perhaps this is the one take-away from this survey: own how you make your games. The challenge is to find ways to continuously improve how you do it.
Some organizations adapt well to agile; others cannot. The main advice is to not take anything on faith. When something doesn't work, address and fix it. Development success depends on talent, leadership, vision and common sense. Once you start following a label, those things tend to take a back seat and that's not good.
[Photos by Drew Stephens, used under Creative Commons license.]