Using Scrum in “Real World” Game Production

Scrum.  Even the name is annoying.  It’s just so…fancy.  Short for “scrummage”, it originally came from the term used in rugby to restart play, sort of like a huddle in football.   It was first introduced in 1986 by Ikujiro Nonaka and Hirotaka Takeuchi as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal"(1). Nowadays there are certifications offered by the Scrum Alliance and scrum.org and there are very stringent rules surrounding its use in development. You can even become a “ScrumMaster.”  Maybe that’s my exact problem with Scrum.  It’s too rigid for my tastes.  I find it interesting that a methodology that espouses being agile is itself full of hard and fast rules.  It can really turn off a team.  Scrum can also be viewed as slightly religious and its practitioners zealots for the cause.   Also, Scrum adopters are often only trained in Scrum so they don’t know that there are perfectly good traditional project management tools available as well.  Worst of all, when implemented poorly Scrum will mismanage titles and remove any hope of team adoption.

But…

I still really like it…or at least the spirit of it.  There’s a term in the field used for what I’ll describe shortly called “ScrumBut.”  As in “it’s Scrum…but not all the time.”  I am a believer that the internal team producer or project manager must be well versed in lots of methodologies and tactics in order to apply the right tools to the specific problem.  Traditional project management often relies on very well-known products and is generally applied to production lines such as creating a car or house.  As we all know, software development is forever in flux and Agile methods (Scrum, in this case) were specifically created to manage these continuous changes.  In this article I’ll discuss my own experiences and how I think Scrum in particular can be best applied to game development.

This article assumes the reader has at least a basic knowledge of Scrum and will not go into detailed definitions of the method.  I’m also assuming the producer works on an internal studio team. External production and publishing is a topic for a different day.

TRAINING

The first thing a producer needs to do is get trained.  As you’ll see in my last article http://www.gamasutra.com/blogs/HarvardBonin/20140412/215368/The_Future_of_Being_a_Video_Game_Producer.php this is a big emphasis for me.  This training should not cover Scrum alone.  It needs to include a variety of Agile methods along with traditional project management approaches.  There are lots of books available that outline Scrum.  A couple of my favorites are Essential Scrum by Kenneth Rubin and Succeeding with Agile: Software Development using Scrum by Mike Cohn.  Both give a good overview of how to apply it in practice and can easily be found on Amazon.  There are also lots of workshops to attend, often run by the authors of the many books.  Clinton Keith has a pretty effective one, I’m told.  This information can be readily found online but these provide insight to only one slice of the pie.  Scrum is categorized as an Agile Methodology and its only one in an array of these methods such as Prince2, Feature Driven Development, Dynamic Systems Development Method, Crystal, Extreme Programming, etc.  To top it all off there’s a whole other category called Traditional Project Management and there are a ton of books, classes and certifications as well.  The Project Management Institute (PMI) is the organization that leads and upholds these standards.  It offers the Project Management Professional certification (PMP) for project managers and producers as well as program, portfolio, Agile and other certifications. I recommend pursuit of these too.   A responsible and informed producer must have a knowledge base that includes all the topics noted above so that he or she can pick and choose the right approach to game development.  Without this wide knowledge base the producer will be limited to only a few weapons to attack project management problems. 

The reality is that there isn’t a “one size fits all” solution to the many challenges that arise in game development.  While Scrum alone may work pretty well early on when the team is small, the backlog is fairly known, the development is very iterative and in discovery mode requiring a lot of collaboration, it may not work very well within a large team in Execution Phase (i.e. full production).  In fact, it may slow things down.  The full development team should never be in concept and discovery mode within the execution phase.  The full team usually has a more expensive burn rate and if core design decisions have not been made before their assignment the team (which usually has the most members in this Execution phase) will bleed money and lower the chances of success.  That is not to say creativity cannot occur during full production for all team members.  An easy metaphor I’ve used is “the execution team sculpts the statue, the concept team creates the clay.”   Traditional waterfall approaches generally work best for full production. 

AGILE FOR BEGINNERS

Scrum is actually just one part of the Agile family of methods.  The Agile Manifesto was created in 2001 as a result of the collaboration of some veteran software developers (2)…

            Individuals and interactions over processes and tools

            Working software over comprehensive documentation

            Customer collaboration over contract negotiation

            Responding to change over following a plan

These points were created in response to traditional project methods that were mostly ineffective in the forever changing world of software development.  Building software is not the same as building a house.  The blueprints for a house generally won’t change drastically.  In software development the design can change daily.  They also created some guiding principles which are:

As a producer I generally agree with the sentiment of each.  Sure, they’re idyllic but we all need to aspire to some development philosophy and generally I like these.  However, there’s one that I fundamentally disagree with.  Can you guess which one?  If you guessed #2 you’d be correct.  On its face it seems that the creators didn’t consider the reality of business requirements very much, at least in game development.  Traditional project management will teach you that changes, especially big ones late in the project lifecycle are also the most expensive.  Furthermore, the very nature of Agile development would by definition negate the need for late changes due to its iterative process.  In other words, the team should have already discovered what it would discover much earlier in the project lifecycle. To me it’s unrealistic and not founded in business reality.

So why is it necessary to know the basics of Agile to operate in a Scrum environment?  Simple.  If you don’t you’ll implement Scrum blindly without fully understanding why it is the way it is.  You’ll fall into the Maslow’s Hammer trap AKA “When you only have a hammer everything looks like a nail.”

SCRUM TOOLS APPLIED

There are many usable tools within Scrum.  I have found that blind application of them without fully understanding their purpose and how they work is misguided.  Here are some ways I’ve tried to apply them in, what I consider to be, a responsible way.

Assigned Roles:  In Scrum there are a few key roles like “Product Owner” (Decider of the backlog and priority), ScrumMaster (organizer and Scrum traffic cop) and Team (content contributors).  Whatever your terminology I am a big believer in assigning clear roles on the team, communicating them and then requiring those people to act accordingly. Scrum or no Scrum this is important.  If you’re the Product Owner then you have to be the one prioritizing the back log and making decisions so the team can move forward.  If you’re the ScrumMaster, make sure that you’re holding and enforcing the Scrum rules of work.  In other words, if you are going to use Scrum make sure you’re at least going through the established motions, regardless if you’re a believer or not.  If you don’t then it’s not going to be very effective.  Both need to fully understand their roles and what’s expected.  In my experience, if the Product Owner or ScrumMaster don’t understand and execute their role the Team will not buy in and Scrum will fail. 

Daily Stand-Ups: I’m a fan of daily, focused standups around a Scrum Board, a core technique used within Scrum, regardless of the project phase - even in the Execution Phase. It’s a simple, quick way for team members to get an update on what everyone is doing and how the team’s work may affect them.   In this case I’m an advocate of doing it “by the book”.  Stick to the standard “What did you do yesterday? What are you doing today? Do you have blockers?” line of questioning led by the ScrumMaster, keep it short (no longer than 15 minutes), keep it small (7-11 people) and do it live.  If a large team is broken up into lots of stand-ups make sure the ScrumMasters are having a “Scrum of Scrums” to share data between groups.  Some teams prefer to rely on software only like Hansoft, Rally or Greenhopper in place of the meeting around the board.  I personally prefer keeping it tactile instead and using the software in conjunction.  Information shared by teams actually meeting face to face is valuable and sometimes the information shared next to the water cooler after the standup is even more so. 

For the producer, whether or not he or she is the ScrumMaster, Product Owner or on the Team the blockers raised in the stand-up should take the highest priority.  They are the highest immediate risk items and will reduce the productivity the most.  Watch for them and kill them.

Scrum Board: I like the Scrum Board a lot.  I like that it’s a meeting place for the pod or team around the work daily.  I like that it’s easy to see work being done.  It can take up a lot of space and without proper maintenance it tends to get messy.  Just remember to keep it simple and limit it to the following categories: Sprint backlog, Doing and Done.  Other agile methodologies have more complex boards but for what we do it’s not effective.  Remember, simplicity is key.  I’m not a fan of keeping the board in software alone.  The tactile, highly visible wall has a lot of benefits and promotes team communication around work.

Burn Down Charts:  Both Agile and traditional project management advocate collection of metrics consistently.  I agree with this and believe that metrics help establish predictability.  The burn down chart is one way to collect data and help plan upcoming sprints. It’s not perfect but it’s something you can analyze and track.  Team members may balk at this since it seems like production is attempting to be the Eye of Sauron.  While that’s not exactly the intent since it’s really about daily checking on the team velocity toward the end of the sprint it could certainly be used for this.  After all, a responsibility of the producer is also about keeping team members accountable.  Trust, but verify as they say.

Planning and Review Meetings:  Both of these meetings are another aspect of Scrum that I find valuable but like most tools they have a place.  Planning Meetings are team or pod meetings where the backlog work is chosen for the next sprint.  Review Meetings are designed to review the work complete from the previous sprint.  If not run correctly they can devolve into chaos and they will lose their value.  The producer needs to understand how they should be run and when they should occur in phased development.  Planning Meetings are most useful when much of the product work is unknown.  In both cases I’ve found, even in the concept phase, they are not very useful to do as a whole team if there are a lot of team members working siloed (i.e. their work is their own and it’s agreed that no other feedback is required presently except from the Product Owner.  Usually this can occur with initial design spec write-ups).  Planning meetings can be chaotic and ineffective.  Sometimes a sit down with the Product Owner is much more useful when team members are working on siloed tasks. They most are valuable when a small pod of a few developers from a variety of disciplines are working on the same prototype or feature.   Also, I’ve found that Review Meetings performed to review anything other than a tangible asset (piece of art, working prototype, etc.) for the software aren’t very effective.  If the project is very early and working on simple documentation they can turn into a “verification of work done” meeting and that’s not the point.  It’s not meant to be a “prove to me you’ve been busy” inquisition meeting. 

Retrospectives:   These are basically simple meetings conducted at the end of sprints, usually after the Review Meetings.  They are essentially mini-post mortems and encourage self-refection and process improvement.  They are also called “look back” meetings.  I like these a lot.  They can be as simple as asking each person “What went right? What do we need to change for the next sprint?”  Assuming your team is no more than twentyish it can go reasonably quickly if done regularly.  If it’s larger the meetings should be split up based on the logic of the work breakdown.  It’s important for the team to participate and be honest, but to do so they need to know that they are protected from their comments and in a safe environment.  This can only be built with trust between the team, Product Owner, ScrumMaster, Producer, Project Manager and Stakeholders.

Sprints:  These can be fairly useful in all phases.  Typically they are time boxed from two to four weeks.  Think of them as focused work sessions for a short duration.  The best ones tend to be themed around a key deliverable that focus the team on a singular goal.  Working, integrated software prototypes across disciplines benefit a lot from sprints.  Alternatively, I’ve found they are less valuable when team members are siloed working on less related tasks.   The best sprint results come from collaboration and time boxing helps guide the team toward a collective goal.  Ever notice how much work gets done right before a milestone is due?  Sprints are like milestones every two weeks except they are focused on showing work to the team not some execs that may fly by every three months.  They are also useful as measuring tools to see how the team is progressing toward the ultimate goal of product delivery.

SCRUM VS. THE EXECUTION PHASE

For the purposes of this article I assume projects have seven distinct, overlapping phases: Initiation, Concept, Protoyping, Pre-Production, Onboarding, Execution and Conclusion.  In a future article I will go into depth about what I believe is included in each phase.  (Some of you may notice I don’t adhere to the exact PMBOK definitions but thematically I’m generally aligned.)  Overall, my biggest gripe with Scrum when it’s adhered to strictly is that it’s most effective when the work is unknown and changing, not in Execution phase when it should be fairly understood.  By definition when a project is in Execution (i.e. full production) it should not be fundamentally changing.  It will be modified, tweaked and refined but the core mechanics, gameplay, art direction, technology or systems should never change at their most basic, foundational level during this phase.  If this occurs then the previous phases did not achieve their goal.  Agile methodology, of which Scrum is a member of, encourages and endorses fundamental change right up till release, which I find to be misguided for the reasons noted earlier.

This is not to say that things like daily standups, collaboration, etc. can’t still be useful in modified forms.  Often, during execution standups are for functional leads, producers, etc. as reports of assets, design mechanics and code are transparently discussed.  They may turn into regular daily hour long meetings which can be effective during this phase.

I will caveat this, however.  My assertion does not take into account market alterations late in the project cycle.  For instance, if you’re working on a title that is strategically initiated by the organization as a market definer of “X” but six months before release another product comes along that blows your X out of the water and negates the original strategic initiative the organization will have to rethink the strategy.  It might be that the original goal need to be changed so that this risk is accepted (kind of an “oh well”, that’s the way it goes” moment) or the original strategic goal of being a market definer is retained which will likely cause the team to delay the title. 

SCRUM VS. ACCOUNTABILITY

One last issue I have with Scrum is its tendency to be "ok" with moving tasks to subsequent sprints if they are not completed in the current one.  While this is going to happen I'm not comfortable with a methodology that gives implicite approval that this is a good thing.  Teams need to be held accountable for doing what they say they are going to do.  Generally, if a person or team is continually missing their estimates is likely that the planning for the sprint wasn't detailed enough.

    Author note:  Check the comments section below for a great discourse on the above point.

IN CONCLUSION

At the end of the day Scrum can work and work well.  It has its flaws and is rigid. I think it’s this rigidness that turns a lot of people off.  Were it more flexible like some other Agile methods then it may not get the undeserved bad wrap that I’ve heard discussed in hallways and carpools.  With a little training and education producers can be the ones to help the team get past their misgivings and onto acceptance and real work. 

As always, these are my own experiences and I realize there are much smarter people in the room.  If you have differing opinions please feel free to post.  You can also reach out to me at [email protected].

References