Search

Friday, August 29, 2008

Should the Scrum Master also be a member of the team?

This question is raised frequently. I prefer that a Scrum Master (SM) not be a member of the team, but this is not a strict rule of mine. An SM as team member can create problems:

  • A focus on their own tasks over the team issues.
  • Prioritizing their own impediments over those of other team mates.
  • It can impede team ownership through the “Scrum Master as Team Lead” anti-pattern.
These problems are usually created subconsciously, but they do create barriers to team commitment. Sometimes there is no choice but to have the SM be a member of the team. There may not be enough teams for the SM to fully occupy their time. An SM can handle 3-4 teams before it starts becoming a full time job (your mileage may vary).

If the SM has to be a member of the team, keep an eye out for these problems. Raise them in the retrospective. It’s not easy, but it has to be done. One great way to overcome this is to rotate SM duties. If your current SM is the only one certified or experienced, they should coach the other people who rotate into the role.

Rotating the SM role has many benefits. Team members appreciate and understand the role much better after trying it.

Wednesday, August 27, 2008

Survey - When and where to hold next CSM class?

I've received many requests for another 2 day "Certified Scrum Master for Video Game Developers" class (the one in Austin last May filled up).

So I'd like to collect a your opinions about when and where to hold the next class. If you are interested in attending one of these, please answer a few questions in the short survey below.

Click Here to take survey

Thanks!

Tuesday, August 26, 2008

Agile values - Individuals and interactions over processes and tools - Part 2

Question: How does a large software project get to be one year late? Answer: “One day at a time!” - Fred Brooks

Our processes and tools to manage ever growing projects have built up over decades. Large teams have driven the creation of hierarchies of management. Project schedules and design documents that attempt to predict every requirement and task necessary to make a fun game now require expensive databases to manage. All of these are considered necessary to tackle the complexity that rise from having upwards of a hundred people working on a project for years.

Game development requires developers of widely different disciplines. Take for example a cutting edge AI character that needs to walk around an environment and challenge the player in the game. The creation of this character requires the participation of animators, designers, character modelers, texture artists, programmers audio composers among others.

It’s important that these disciplines collaborate as much as possible to be the most effective. If the animator is experiencing a problem with the animation technology, then it is important for them to work with a programmer as quickly as possible to address the problem so they can continue working. Often the processes and organization will prevent that. In our example with the animation bug, the programmer may be working on a series of tasks that were assigned by a lead. This may prevent that programmer from helping out the animator without permission from their lead. This leads to a chain of conversation as shown in the following figure:



The animator has to pass the request up through the chain of command which then has to make it back down to a programmer who can solve the problem. In this example, the change involves five people and four requests! This flow is prone to failure and delay.

So what has been described?
  • Over 100 people of various disciplines on one team.
  • Thousands of unpredictable problems that can introduce wasted time and effort
  • Detailed plans and tools to manage them that can’t predict these problems and are potentially inflexible at changing.
  • Hierarchies of management that can lead to further waste.
Agile can address these issues from the bottom up. This is a major benefit from self-managing teams. They self-manage the smallest level of details, not necessarily the highest levels. They aren’t self leading teams. They unburden leadership of the role of managing minor details. They allow leadership to focus on the big picture.

When teams learn that they can take a small amount of ownership to solve the smallest problems, they start taking on larger problems. They begin to ask for more ownership in other areas:
  • In creating better teams that can solve more problems by reducing external dependencies.
  • In demanding more of themselves to achieve commitments they own.
  • By identifying risks early and addressing them before they become problems at all.
  • By growing leaders among their own ranks.
Agile values are preferences and not binary decisions. We can still have process and tools to support the team, but we value individuals and interactions more to solve most of the problems that occur on a daily basis.

Scrum Rising article posted

I've posted my February 2007 Game Developer Magazine article "Scrum Rising" here.

It's an overview of applying Scrum to game development.

Monday, August 25, 2008

Scrum makes you smarter

http://jeffsutherland.com/scrum/2008/05/scrum-makes-you-smarter.html

"Recent research shows that people who work in command and control environments actually lose a significant number of points on their IQ. They get stupider."

Sunday, August 24, 2008

Agile values - Responding to change over following a plan

“Plans are nothing. Planning is everything” - General Eisenhower.

When the allies stormed the beaches of Normandy in 1944, they had a very detailed plan of attack. This plan led to their assumed victory over Germany before Christmas of that year. That plan was doomed from the start. How could it be otherwise? How could a plan for hundreds of thousands of soldiers, millions of pounds of supplies and thousands of missions all work out according to a plan on paper? Eisenhower knew it wouldn’t. That’s why there were always contingencies. That’s why the allies were always adjusting the plan based on the reality of the emerging battles.

Agile project management follows similar reasoning. A popular misconception about agile is that it doesn’t allow for plans. This isn’t true. Agile focuses on the activity of planning rather than focusing on a fixed plan. A certain amount of knowledge about any project is going to be well known. Just as the allies knew the location of the beaches they were going to land on, a game development project will begin with quite a bit of knowledge about the genre and market targets for the game to be developed. It is necessary to plan for these things and to share that plan. The problem occurs when the planning goes too far. I’ve seen a game design document for a fantasy shooter game that had the bullet count for each of the clip types of every weapon. How can we know how many bullets per clip we should have in a game? Why do we need to plan for that detail before we have the knowledge of what we need? This is an example of the source of problems that detailed plans can create. If the team sticks to the detailed plan, then it won’t be the best game possible. Great game emerge.

The agile approach is to plan for what is known and to execute against what is not known iteratively. In other words, agile is focused on gaining knowledge. If we don’t know how many bullets in a clip or what type of weapons will be the most fun, we don’t try to plan away that uncertainty on paper. We address it head on by building weapons early and learning what is best.

Many elements of a plan are assumptions. We assume the things that we put into a game design document are going to contribute to a hit game. Some of these assumptions are correct, some are not. By implementing and testing these assumptions, we change some of them. We then alter the plan to create a better game.

Saturday, August 23, 2008

Looking for a great programmer who does TDD?

A former co-worker. Very talented and only interested in a US game developer who embraces agile & TDD. Highly recommended. Contact me.

Thursday, August 21, 2008

Iterations and vertical slices

Any game developed using agile makes progress using iterations. The goal of every team for every iteration should be to make progress by adding value to the game or pipeline for a customer. This might be a the improvement to a core feature for the player who buys the game or a function for the animator using the asset pipeline or a tool.

Iterations (or Sprints) are like mini projects by themselves. They often include design, coding, asset creation, tuning and debugging. However we are not always producing full vertical slices of a game every iteration. We’ll use a an example of what we might deliver for a team which is focused on creating AI behaviors: One of the most difficult aspects of AI behavior is navigation in a complex environment. The AI logic has to identify objects that will prevent the NPC from moving and calculate a path around them. Throw in some other moving characters and objects and the problem can become very complex to solve. Navigation can become the most riskiest problem to solve AI and therefore one the the riskiest problems to solve for the entire game.

Naturally we would want to solve the navigation problem as early as we could. The problem with doing this work early is that other related systems such as character animation and physics might not be developed enough to support the sprint goal of having a polished AI character walk through a complex environment. In this case, the iteration goal for the team might be to demonstrate simple cylinders navigating a complex test environment.

Does this solve all the risk associated with AI characters navigating complex environments? No. It probably addresses a big part of the problem, but there may be other problems that show up when progress is made with the animation and physics. The benefit is that those systems will have some basis to work against. If we find that our cylinders have problems navigating up stairs, then that might influence animation and physics work over the upcoming iterations.

It's a much more intractable problem when you discover your nicely animating AI character can’t climb the stairs that are duplicated in every level.

Iteration goals are prioritized based on value, cost, risk and knowledge. Addressing high risk and creating knowledge sometimes drives the highest priority stories on the backlog. A Product Owner has to understand the risks of the project as well as the value of the features when prioritizing.

Wednesday, August 20, 2008

Agile values - Individuals and interactions over processes and tools

The agile manifesto defines four values that the criteria for any method which calls itself "agile". I'm going to cover the ideas behind each:

Individuals and interactions over processes and tools

Back in the early days of mass-production, when companies like Ford were discovering the efficiencies of assembly lines, the theories of Fred Taylor were being applied in factories. These theories were based on the idea that complex jobs, such as assembling a Model-T car, could be performed by relatively unskilled and cheap labor if each step in the assembly line was broken down to a simple job that could be standardized. Workers were considered to be interchangeable cogs in a large machine.

Though “Taylorism” has been discredited, many management practices are still based on the idea that as long as a well defined process and set of tools exist, then the work that can be done by a group of people can be predicted and defined up front. Workers are considered “fungible” or replaceable and anonymous on a large project plan that attempts to predict what each part of the whole will take a worker to complete. Managers find comfort in this. As long as people and hours are are interchangeable, then we can play with the amounts of each to achieve predictability. This idea has been disproved for decades. It was the basis of Fred Brooke’s book “The Mythical Man Month” in the sixties. People and months are not interchangeable.

This is why agile values individuals and interactions over processes and tools. Teams of people make games. Artists, programmers, designers and testers all have to communicate to be the most effective. Collaboration and shared vision are key to great teams. Tools and process are still important, but they can’t replace this.

So why do we cling to this idea? Because it’s easier. Process and tools, interchangeable hours and people, spreadsheets that are meant to be crystal balls only require management. Collaboration and shared vision is harder. They requires leadership. Leadership is harder than management.

Tuesday, August 19, 2008

Production Debt

Have you ever seen a schedule for a game project that picks a day for production to begin? I think I've seen that on every project. Some day is chosen, a year or so in advance, and you have to start creating "production assets (levels usually)" on that day. I've never liked it and it's never worked out very well.

The problems are:
  1. Teams never transition from pre-production to production as if a switch were thrown. Different asset types transition at different rates. E.g. we may have level production down, but our animation system is still lagging.
  2. Where does this date come from? How do we know how much time we need for pre-production, and more importantly how do we know how much time we need for production, especially when we have a fixed ship date? How do we know if the time slot we're giving ourselves is enough so that we don't paint ourselves into a corner? How many times have you entered a nine month production phase with 12 months of work to do?
  3. What are the criteria for determining we CAN be producing assets? The date comes and we have to be in production, so we usually tell ourselves and our publishers "sure...we're in production! All those assets you see there are really production assets that aren't done...yeah". You're still iterating to find the fun and you can't iterate as much in production!
Measuring Production Debt in Preproduction

Production work is a necessary debt that we create in preproduction. One of the goals of preproduction releases (or milestones) is to measure that debt. During the first few releases that debt will be uncertain. You might say "we believe that we have 1000 people months of production work, plus or minus 200". The project would continuously refine that number during subsequent releases. Towards the end of preproduction you want it to be a much more accurate number.

Why Measure Production Debt?

Imagine you are on a first person shooter project that has 12 levels planned and 12 months of production scheduled. During development your team implements some cool technology that allows every piece of non ground geometry to be destroyed or have holes blown in it. This is a great new addition but it creates a problem. It doubles the amount of effort required to build a level.

How do we react to this? The first problem is that we have to know the problem exists. In many cases we don't do a proper job of measuring the production impact of design and technology changes. We paint ourselves into the proverbial corner. This is why demonstrating the cost of production should be a part of every release review.

If we know that we will double the level production debt with a new feature developed, such as the destructible geometry feature, we can make solid decisions early. Some choices would be:
  • Drop the feature because we can't afford it
  • Drop half the levels
  • Start production earlier
  • Extend production and ship date
  • Scale up production resources
Some of these choices are harder than others, but they are all better choices than the one that is usually taken: trying to stuff 24 months of production effort into 12 months of schedule.

How to Measure Production Debt

The only way to measure production debt is to make a small set of production quality assets, measure the effort and scale the measurement. For our example, our release would demonstrate a small level with a couple of buildings that are destructible. If we estimated that the demo level was 10% of an entire level we could say that the level asset debt would be 10 times the effort spent on the demo times the 12 levels we are planning.

As mentioned this would be an inaccurate measurement in early releases. We can't always make truly shipping quality demo levels early in a project. Subsequent releases would get closer and the estimate more accurate.

The good thing is that we can expect that we'll get more efficient at creating levels during production and that will free up time to incrementally improve the levels during that time.

What Happens to the Production Date?

Publishers will rarely allow a team to tell them "we'll pick a production date when we know more". It's OK to pick a production date with the caveat that the date will be refined per asset type every release. Back the refinement up with higher quality asset demos every release. Publishers and developers should have ongoing discussions of the questions raised above when it's clear that new features are impacting production debt. Publishers rarely get good information about cost and benefit information about major features.

Production debt (like every other debt it seems) always grows. The problem with production debt is that we can't retire it in an ongoing was as other debts (design, technical, etc.) are. Don't make your team attempt to pay it off with crunch.

Sunday, August 17, 2008

Cooper Product Design applied to Video Games - Part 2

In Part One, I described Alan Cooper's model on how agile fits in with his Goal Driven Design process. It made a lot of sense to me and it bears examining if it can be applied to game development.

As discussed, Cooper doesn't shy away from applying phases to product development...something that many agilists do. However his phases are more integrated and overlap their responsibilities throughout the entire project. So rather than calling them phases, he refers to them as "stages".

Comparing this to games, we typically have two distinct "stages" that be identified in game development: preproduction and production. I added the concept stage in part one since games do not start iterating from a blank slate on day one.

To better apply the Cooper design principles, I'd now like to divide up the pre-production stage into two stages: design and engineering. These are not phases divided by time. Both are intertwined, but they are answering two different questions. Design is focused on "what" we are building. Engineering is focused on "how" we are going to build it. This would include the tools as well as the engine. They are really both design stages, but the goals of what they are designing are a bit different, so I'll separate them here.

Here are the four stages we are going to talk about:


We ask questions of the first three stages and make a statement at the production stage:

The stages that ask questions seek correctness. They want the right answers. In the production phase, we seek to maximize efficiency while we are building. We know the answers from the previous stage. Entering production without these answers is one of the most common reasons for cost and schedule overrun.

The "toolsets" for each stage are different. In the concept stage we use our intuition to determine which path to take. In the design stage, we're focusing on player and stakeholder needs. The engineering stage focuses on how these ideas are going to be realized and if it's possible to produce with the resources we have . The production phase focuses on efficiency; how can be build things faster, better and more inexpensively.

There are three different states of mind that for the four stages. The two middle stages are where collaboration occurs among mixed discipline teams. The concept stage is more solitary. It's driven by vision and insight. Consider visionaries such as Miyamoto. Their major contribution comes from their vision and concept of game ideas. You can't take a group of non-Miyamoto (lesser) game designers and expect them to scale their vision to his level.

The production phase is not as collaborative either, especially in cases where we are trying to outsource production assets. It's more about the flow of productive work and improving the flow. This does require some collaboration, but it's not the same. We shouldn't stop to discuss and change the goals with the customer at this point. Changing genres when half your levels are produced is a bad thing.

Finally, let's look at the procedural approaches we use in each stage. In the concept stage, it's pure iteration. New ideas are tried and old ones are discarded. We have total freedom to explore in any direction necessary. Insights are not incremental.

The design and engineering stages are iterative and incremental. We increment towards production through time-boxed iterations that improve value toward customer value (humans) and the means to provide it (technology).

The production phases is incremental. We are not iterating on things we discovered in preproduction. We're mass producing the assets and finding ways to incrementally improve how we create assets.

Where does agile fit in?

The two center stages are the agile stages. This is where fully collaborative cross-discipline teamwork takes place to push the product forward and achieve the best results.



The other stages Cooper refers to as the "fragile stages". The concept stage is "magical" and unpredictable. It's hard to know when it is successful. You can't create a large team do it faster. The production state is fragile because of its size, length of time and potential for waste.



However with the production stage, we can apply Lean principles which are largely derived from product manufacturing (e.g. Toyota). These focus on eliminating waste and focusing on where value is added. It focused on a constant set of incremental improvements that do support collaborative work but also work standards for larger groups of people.



Conclusion

I feel this model has some value. Over the past five years, I've considered & discussed a couple of the issues with adopting agile for video game development:

- Game development is a combination of product development (preproduction) and manufacturing (production). Applying the same Scrum practices to both is not ideal.

- Our one release model for large scale games isn't an ideal fit with the regular release model of other products where agile is more commonly applied. We can't get proper customer feedback for our iterations. Focus/play testing is not enough. We need visionaries.

Stages seem a good fit to describe what we do on an agile game project. Cooper's breakdown adds value in discussing the practices, tools and goals of each stage. Stages also address the problems of phases by not handing off responsibility between them.

Scrum is a good fit for the design/engineering stages. Based on production experiences, Lean is an ideal process for the production stage. Many studios do the concept stage, but as Cooper says: "it's magical". How did Apple create the concept for the iPod? What practices do we create for the concept stage that allows many ideas to be inspired and filtered? How do we know when we are done?

Cooper's model is a step forward is defining that.

Article - How to fail with agile

Better Software Magazine just published an article that Mike Cohn and I wrote called "How to Fail with Agile". It's a tongue-in-cheek set of advice for those seeking to fail at agile.

You can find it here.

Certified!

After months of review, I've finally been approved as a Certified Scrum Trainer by the Scrum Alliance!

What does this mean? It means I can "officially" train Scrum Masters anywhere. It means that every Scrum Master I train is certified through the Scrum Alliance and has full access to the resources there. It also gives me valuable feedback and instruction on what and how I teach these courses.

Having access to members of the SA such as Ken Schwaber, Mike Cohn, Jeff Sutherland, etc has been a huge benefit to me as it will be to every CSM I teach who automatically becomes a member.

Plus I get to use this nifty logo:

Wednesday, August 13, 2008

Cooper Product Design applied to Video Games - Part 1

One of the keynotes at Agile 2008 was by Alan Cooper on his views on agile. Alan is an agile proponent who has differences with some of the other popular "agilists". Alan a more design and interface driven approach to product development. I feel that Alan's approach to design and construction as necessary stages of product development, surrounding an iterative and incremental core, mesh well with what I have experienced in game development.

When we talk about the waterfall methodology these days, we're usually not talking about the original definition of waterfall defined by Winston Royce in 1970. We're talking about projects that are mostly planned up front (using BDUFs) and designed/optimized/tuned at the end. The issue we have with this is that the documents & schedules created up front are usually wrong and we end up with a poor product or blown schedule and budget.

Conceptually, waterfall looks like this:


The arrows are hand-offs from one stage (or phase) to another. Alan refers to these as not only hand-offs of work, but hand-offs of responsibility. The difference with agile is that responsibility is not handed-off, but continues throughout the project.

The popular opinion is that agile does away with these stages or at least mixes them up every iteration. While this may work for mostly software driven projects that have regular and frequent releases to customers, I don't believe it's ideal for games. A typical console game has one release in 2+ years and has a large content component that must be mass-produced at the end.

In 2002, I read about the Cerny Method for making games. This was a major inspiration for how games should be developed. Later, when reading about agile, I felt that an agile model for development could support the Cerny Method very effectively.

The Cerny Method identifies that the goals of preproduction and production should be entirely different and managed differently. Preproduction should be exploratory and minimally planned up front. The goal of preproduction is to find the fun of the game and produce a few shippable levels which would answer all the major questions of cost and quality for the production phase. The production phase would be entirely planned against the knowns from preproduction and executed to that plan.

What agile does is provide a framework for these stages. Preproduction is iterative and incremental and can be based more on the Scrum practices. Production is mostly incremental and can leverage the lean production practices. Production is less iterative due to the cost of iterating on a large number of produced assets. For example, we don't want to iterate on the jump height of a platform game after we have created a dozen level with hundreds of platforms based on the previous jump height!

I've left concept phase in to represent the idea that we don't start creating incremental value on day one. Concept is purely iterative phases where we develop our "big ideas" about the game before pre-production. A opposed to production, concept is where we are meant to throw out most ideas. Concept could be very short, but the responsibility of the designers in concept does not end when the project moves to preproduction.

If we look at the stages with Cooper and Cerny in mind, the responsibility for the concept of the game continues throughout the entire project. This doesn't mean that the concept will iterate throughout the project, but that there will be collaboration and overlap between the the groups. It also means that the boundaries are a bit fuzzy. The same goes for preproduction. We're not going to finish pre-production on Tuesday and start production Wednesday on all assets. We're also going to encourage refinement and incremental improvements during production.

In the next part, we'll look at how the tools and techniques differ for each of the three stages.

Monday, August 11, 2008

Warnings from Chris Deering

From Gamasutra this morning, from former Sony Europe boss and current Codemasters chairman Chris Deering:

----

Despite all this growth, however, Deering warns that current development costs, currently in excess of $10 million for major titles, are unsustainable, given that less than 3 out of 10 games actually recover their costs.

Moreover, he says software sales may decline even as hardware proliferates. "Traditional revenue sources will not be sufficient to fund games development," he says. "Especially as global retail sales will be 20 percent lower in 2011 than in 2008."

----

We're still a hit-driven industry (where a profitable game will pay for a larger number of unprofitable ones), but the margins of profit for the hits are declining. This is due to higher development costs and what he refers to as a decline in software sales.

I hadn't considered the decline in software sales part, but if fewer games are made that leads to fewer choices for the consumer which leads to the consumer buying fewer titles overall then that makes sense.

Saturday, August 09, 2008

IGDA Leadership Forum

The IGDA has recently opened up registration for the upcoming Leadership Forum. This is the second year of this forum. Last year's event was a bug success and very worthwhile. Any producer or leader should sign up quickly before they fill up. I suspect it's going to sell out quickly again.

I'll be presenting a talk called The Myths of Scrum. We're going to have some fun with this topic!

Agile 2008 Conference

Just returned from the Agile 2008 Conference in Toronto. This is a great conference that applies the agile principles in its organization and execution. Lot's of impromptu "knowledge jam sessions" and even an area for the musically talented to get together and play. It's can be a bit chaotic, but not dull.

The conference had ~ 1600 attendees. It's been growing pretty steadily since it was formed from merger of two smaller conferences about five years ago (including an XP conference). Many popular agile, XP, Scrum and classic CS authors were there. Most were very approachable and friendly.

The attendees were divided up equally between coaches, developers using agile and people new to agile. There were about ten tracks and about 40-50 talks going on at any one time. The sessions dived deeply into agile problems, developments and successes. I gave a 90 minute presentation on agile game development and participated in a CTO panel run by Jim Shore and Dianna Larsen.

The conference was very lightly attended by game developers. I believe there were only three of us, but we smelled each other out soon enough. The other two were a couple of developers from a large company that makes "computerized gaming machines" in Nevada. We had a great conversation over some tasty Indian food about their challenges and stories of making video gaming machines for casinos.

My focus at the conference was attending sessions on building and facilitating great teams. There were plenty of sessions on this topic. I received an overwhelming amount of information on theory, team practices and coaching in the area of hyper-productive teams. You just can't fully appreciate the value of a daily scrum until you've heard about the decades of research on group theory and complex adaptive behavior systems that reinforce the practice. :)

Toronto is a great place for conferences like this, as long as it's in the summer. There are plenty of after hours things to do and great places to eat. All the city dwellers take full advantage of the perfect summer climate. Due to it's terrible winter weather, there are many malls below street level that you can get to quickly for lunch or a quick Starbucks fix.

Next year the conference will take place in Chicago. Hopefully more game developers will attend (think great food and Rush street).

Sunday, August 03, 2008

Scrum experience at Nokia

Interview with Scott Foe, Producer at Nokia: http://www.gamasutra.com/php-bin/news_index.php?story=19210

Quote:

You said you're using Scrum.


SF: That's the project development methodology that we've employed. You know, Scrum is - especially with the recent [Game Developer magazine] article from, I believe, last year, “Scrum Rising” - a hot topic in the games industry of late.


People have strong opinions.


SF: People have strong opinions. I definitely have my own strong opinions. It's definitely not a silver bullet, nor is any development methodology. I mean, for example, yes, Scrum leads to greater team communication and cooperation, but if one of your team members is an axe-wielding barbarian, then that might necessarily be a good thing.


But there is certainly, in publishing minds, this kind of idea that Scrum is this evil dragon that - “Oh, if we don't have a waterfall project planned with everything mapped out in detail, then this project is just going to go way overboard, and way over budget.”


I have to say that if you're doing a quality-driven title - so I'm basically separating the universe of game projects into release-date driven, and quality-driven; release-date being, “We gotta get it out by this date,” and quality driven being, “It's gotta be out when it's ready” - for a quality-driven product, using an iterative development model like Scrum is excellent for bringing that home, and for revisiting issues, and making sure that everything is just perfect.


For a release-date driven model, Scrum is excellent because, at the end of every sprint - Scrum project cycles are broken down into a number of sprints - you have something which could conceivably go to quality assurance. So if your due-date has to be - cannot miss! - this certain date, then at the end of every sprint you have something that you can conceivably ship with. Whether that's good or not, that's in debate. But you could theoretically launch it.


From the publishing side, Scrum has very few artifacts, so when you go into a Scrum product development methodology, instead of having, like, oodles of Microsoft Project files and Excel files, and this and that, what you have is the product backlog. People take product elements off the product backlog, the team puts it in the sprint backlog, they complete it, then they give you a sprint report and a playable build. The sprint report and the playable build are probably the best visibility into how the health and well-being of the development project of any of the corporate artifacts that come from the different development methodologies out there.


So, for example, if you're at a publisher, and you really want complete visibility into how is the team doing, what are they accomplishing, you have that sprint backlog and can see, at the end of each sprint, what the team did, what they failed at, and why.


You can't get more clear-cut than that. Having the actual sprint review build, that build of the game, to be able to take around internally and say, “Here, look. This is what the game is about. This is how we're doing. This is how we're going.” There's no better feel for how a project is going, instead of waiting however long for a given milestone build.


From the contractual side? I mean, it requires flex. Say you're doing a release-date driven title, and you're making a contract, and you know the team is operating on a Scrum development methodology. Well, it's easy to say, “This is the due date. These are the payments. And go. These are the number of people you have, and we'll be out on this date.”


Now when you go for a quality driven title, contractually it becomes a bit more sticky, in that you either have to, one, plan on going back to amendments to the contract to say, “Okay, we need two more sprints. We need three more sprints. We need this many more sprints.” Or actually building into the contract the possibility of approving and paying out more sprints on an as-needed basis. And of course, most business development people, and people who write the contracts in the publishing arms of organizations everywhere are probably not familiar with this, and very married to the standard way of doing things, which, of course, causes friction within the publishing organization.


Again, not a silver bullet, but I definitely couldn't see myself using any other development methodology that's in current practice today. I definitely am a huge Scrum fan.


I imagine that kind of heavily iterative method would be particularly suited to a game like this, where you've got fairly disparate gameplay styles that you're bringing together. I suspect that took a lot of trial and error.


SF: Most definitely. I mean, a piece of paper is never fun. Right? First person shooter is easy. Well, easier. You've got a point of reference, you know you're going to need some weapons, and some enemies, and maybe you're going to do an amazing narrative structure, and blow everything else out of the water. But for the most part, you know what you're aiming at.


For something where you are planting the flag, and you are running out ahead of everybody, and there are rocks, it does take time and iteration, and polish to get the jetpack to be as fun as the jetpack could be, or to make sure that the princess-rescuing is satisfying.


One other point, going back to the transparency, I don't think it's really part of the standard Scrum development methodology, although I may be incorrect about this, but one of the things we found really useful on this project is doing our burn-downs by discipline, so you have a burn-down chart which is basically, here's all the work that needs to be done on the project, and you watch it burn-down as elements are taken out of the product backlog.


When you burn-down by discipline, and you see the velocity of how the project is going, you can say, “Oh, we need more artists, or we need more designers, or we need more programmers.” And it becomes more obvious, sooner, although, again, that might already be written down somewhere. I haven't read all the Scrum books. That might be out there.