Agile Game Development

Big documents and bananas

2009-05-28T10:29:00.000-07:00

Consistency is a hard-coded survival trait. Change is resisted. It’s a primal instinct. I never fully appreciated this fact until I read about the following experiment:

This experiment placed five monkeys in a room with a banana tree in the center. Whenever a monkey attempted to climb the tree to pick banana, a sprinkler system would spray all the monkeys with water until the monkey retreated from the tree. They repeated this experiment until all the monkeys learned to not approach the tree. The monkeys liked being dry more than they liked bananas.

The next stage of the experiment involved replacing one of the monkeys with one who had never been sprayed with water. The new monkey soon started to approach the banana tree. However before the sprayers started, the other monkeys jumped into action and beat the new monkey away from the banana tree. This was repeated every time until the new monkey learned not to approach the tree.

The researchers continued to replace the original monkeys who were sprayed with water one by one with fresh monkeys. Eventually none of the monkeys in the room had ever been sprayed with water for climbing the banana tree. The monkeys still continued to beat up any monkey for approaching the banana tree. None of them "knew why” they couldn’t approach the banana tree. They just knew that the banana tree was off limits.

Sometimes we developers do the same thing. A company’s culture becomes intertwined with the “standard best practices” that aren’t questioned and never replaced. Personally I did this for many years pursuing waterfall methodologies. I wrote big documents up front (BDUFs) for projects that always failed to account for everything. Even after those projects shipped--following months of crunch and despair--I would start the next project the same way.

Are there any "banana tree" rules where you work?

Encore San Diego Certified ScrumMaster Class June 18-19

2009-05-21T11:07:00.000-07:00

The followup San Diego CSM class registration is open:
http://www.pmi-sd.org/cde.cfm?event=264055

June 11-12 CSM class sold out

2009-05-19T13:54:00.000-07:00

The San Diego CSM class has been sold out. We're scheduling another for a week after that. I'll announce that here when it's posted.

Certified Scrum Master course in San Diego

2009-05-15T06:43:00.000-07:00

I'm teaching a Certified Scrum Master course in San Diego on June 11 & 12 (Thursday & Friday). This is hosted by the PMI and is not focused on game development.

More details here.

Scrum Master for Games Course in Massachusetts

2009-04-24T09:44:00.000-07:00

There's less than two weeks to go before Mike Cohn and I give our "Certified ScrumMaster for Video Game Development"course in Cambridge Massachusetts. We still have seats available.

Mike Cohn is the author of User Stories Applied for Agile Software Development and Agile Estimating and Planning. Mike is a founding member of both the Agile Alliance and the Scrum Alliance. He was also our agile/Scrum coach at High Moon Studios.

If you are interested in knowing more, please visit the course site (click on the banner ad below).

Book: Agile Game Development with Scrum

2009-04-07T16:06:00.000-07:00

I've been working on a book for the last year. The working title is:
Agile Game Development with Scrum

I hope to have it done by the end of summer. It will be published by Prentice-Hall as part of Mike Cohn's Signature Series books. I'm very proud to have the book be a part of the series!

The first draft is complete and second draft chapters are being posted on the book's website:
http://www.mikecohnsignatureseries.com/books/agile-game-development-with-scrum
I am looking for not only feedback, but also your stories of adopting agile in your studio or working with agile game development teams! I want this book to be a reference for the industry. If you have stories to tell, they may be included as sidebars with full credit given.

There is also a LinkedIn discussion group forming. If you have problems joining it, send me a message:

I put off writing this book for years. I've never enjoyed writing big documents, but I have loved the experience of writing this book! Hopefully that will come through to the readers.

Publisher side product owners

2009-04-07T14:07:00.000-07:00

Product owners for a video game project using Scrum are usually a member of the development team. The reason for this is that unlike projects outside the game industry, product owners are needed to provide a much higher level of subjective feedback. Does the control of the player feel right? Is a mechanic “fun enough”? This feedback requires daily engagement with the team.

However, in some cases the publisher will require that product ownership be placed in the hands of someone on their staff. This could be an executive producer or someone who works directly with a licensee. In some cases this makes sense. If a licensee wants to maintain oversight or the publisher wants to make sure that their franchise is well tended, then product ownership at the publisher level makes sense.

Unfortunately this usually means that the team loses the day-to-day involvement of product owner. This can lead the project down bad paths. These projects can lead to “iterative and incremental death marches” when there is a reckoning between what the game provides and what the license or franchise owner sees much later.

A solution is to divide up the Product Owner roles. With this solution, a publisher product owner and a developer product owner would divide and share the role. The figure below shows the arrangement between the two.

Figure - The Publisher Product Owner Role

The publisher product owner would have the following duties:

Own the product backlog. They would have the final say on the PBIs and their priorities. They would focus on the larger release sized epics and not the sprint sized stories that are manipulated between sprints.
Establish the release goals. Identify the "Big Hairy Audacious Goals" for the release.
Attend release reviews and planning. Attendance is a must. This role won’t work if they can’t sit with the team for at least one or two days between releases.
Call for release dates and manage the release plan (the potential set of sprint goals). The release plan has some flexibility by definition. The publisher product owner needs to be involved in any changes are made to the release plan and dates.
Is the “one voice” for all the publisher side customers such as sales, marketing, executives and licensees.

The developer product owner has the following duties:

Attend the release reviews and planning sessions.
Works with the team to refine the sprint goals during sprint planning.
Available daily to work with the teams to refine the understanding of sprint goals.
Remains the “one voice” for the development team.

The key to making this work is that both product owners need to be “on the same page” with the vision for the game and understand their duties. The entire organization from a tester at the studio up through the executive staff at the publisher need to have the same vision for the game.

Hardening Sprints and Dead Frogs

2009-04-01T10:39:00.000-07:00

Teams will often schedule a "hardening sprint" at the end of a release. The purpose of the hardening sprint is to add a level of polishing and testing to the game that doesn't normally occur every sprint. An example of a hardening sprint task is to conduct an eight hour smoke test of the game to catch any problems that don't occur when the game is played for a few minutes.

Unfortunately the hardening sprint can end up becoming a dumping ground for work that should be done every sprint. This should be avoided as it postpones the team and customers from evaluating the value features that should be emerging every sprint.

I like to think of a hardening sprint the same way I think about detailing a car. I have a couple of sons, so I’m often cleaning out rocks and once living organisms they collect and forget weekly. Every month I’ll pull out the shop vacuum, rags and hose to give it a quick cleaning.

Every several months I’ll treat myself to getting the car detailed. I’m always amazed at how the detailers will clean out every nook and cranny in the interior. They even clean out the dirt from areas as obscure as the folds of the boot at the base of the shifter. Of course a week later all evidence of this cleaning is gone.

I don’t polish the shifter boot once a week. I don’t have the time or the need to clean to that level so frequently. On the other hand, I don’t put off cleaning out the rocks and wildlife from my car for the detailers. I don't think they'd appreciate cleaning out mummified frogs.

A hardening sprint at the end of the release is like having your car detailed. It’s important that it only be thought of as the extra bit of polishing detail that you don’t do every sprint. It shouldn’t be a dumping ground for bugs, tuning and stand-in asset work that should be tackled every sprint.

So don't leave the dead frogs for the hardening sprints!

GDC Slides

2009-03-30T10:38:00.000-07:00

Slides for my GDC presentation "Advanced Scrum and Agile Development" are available here.

GDC Wrapup

2009-03-29T16:54:00.000-07:00

GDC was good this year. Although attendance was down, you couldn't tell it from the sessions. They were packed. The expo floor and especially the career pavilion, were a little more sparse.

All the sessions I wanted to attend were good. I added some comments on a few:

Failure is NOT an Option - Basic Survival Techniques for any Producer/Designer
This was one of the best sessions of GDC. Rich Vogel talked about true, hard-won leadership and PM wisdom. He "told it like it was" and his one-liners had us laughing. Get the slides and audio.

Building Your Airplane While Flying: Production at Bungie

I met Allen Murray and Patrick O'Kelley earlier in the week and was interested to hear how they were adopting a very Scrum-like process to production. It sounds like Bungie is applying a lot of common sense to production following some heavy crunch on the Halo titles. Sadly, I had to dash to a meeting halfway through this presentation, so I'll be downloading the slides and audio for this one as well.

Bend Microsoft Project To Your Will - Again
Good session! I almost wish I was using MS Project 2007 after suffering all those years ago using its predecessors. Almost. Although Mike says he has some issues with Scrum, he professes a lot of wisdom that is in line with the principles of agile development:
- "If you are spending more than 30 minutes a day using Project and not working with the team, you are doing it wrong. Your real job is getting out of your chair and looking at the game".
- "Don't get caught up in tracking the past".
- "Game development is agile whether you like it or not."

Mike suggests that daily work be tracked and that a Project database be limited to 1500 tasks. However a console project team using Scrum can easily generate over 1500 tasks every four week Sprint. Tracking to the level of detail that Scrum teams can do themselves doesn't sound like an effective use of time and tracking to a higher level of team is less accurate.

It's a better tool these days, but I think it's best used for production.

The Iterative Level Design Process of Bioware's MASS EFFECT 2

I had to skip this one for my flight back. However I had a great chat with Corey the day before. Bioware continues to be a very progressive development house that is discovering great things. I'll be grabbing the slides/audio for this one as well.

I can't recall attending a more enjoyable GDC. I'm looking forward to GDC Canda in May!

GDC Week

2009-03-21T10:32:00.000-07:00

Another GDC! I'll be presenting my session on Thursday at 9 AM called Advanced Scrum and Agile Development. This has probably been the most challenging presentation I've had to come up with. Over the past year as I've visited a lot of studios, I've seen some very common challenges that Scrum teams has been struggling with. As we addressed these challenges I started to see some common patterns emerge about how studios see Scrum. For example, many studios new to Scrum see it as a way to slice and dice a push system of task management -- and it does give some improvements to the way they managed tasks in the past. The challenge is to transition to a pull system of creating value every iteration; tasks are critical, but achieving "done" is more important. Changing this state of mind is a challenge that most Scrum teams will face.

Issues like this have been the most valuable to address over the past year, so that's why I'm addressing them in the session. We'll see if it translates to a 45 minute talk.

There are plenty of interesting sessions again. Some of the ones I'm looking forward to are:

Failure is NOT an Option - Basic Survival Techniques for any Producer/Designer
I attend any talk that Rich Vogel gives at GDC.

Building Your Airplane While Flying: Production at Bungie
Production case studies from Halo3. Enough said.

Bend Microsoft Project To Your Will - Again
Have I gone mad? Microsoft Project? Mike McShaffry always has something interesting to say, but when the session description includes statements like "...even how to track agile development (even SCRUM!) using Microsoft Project", attendance is a must.

The Iterative Level Design Process of Bioware's MASS EFFECT 2
C'mon GDC organizers! This talk at 4 PM Friday?! Unfortunately I'll be waiting for my plane. Bioware is pushing the boundaries of Scrum and Lean for level production. If you are around, this should be interesting.

There are plenty of other great sounding sessions as well.

See you at GDC!

Certified Scrum Master for Game Developers in Boston

2009-03-12T08:44:00.000-07:00

Mike Cohn and I will be providing a Certified Scrum Master for Game Development course in Boston (Cambridge) on May 5th and 6th. Details are here. Mike is the author of User Stories Applied and Agile Estimating and Planning and was our agile coach at High Moon Studios.

Also, there are just five seats remaining for the Certified Scrum Master for Video Game workshop at GDC.

The ideal agile workspace

2009-03-06T05:46:00.000-08:00

Mike Cohn has created a great list of all the things that should be visible in an agile workspace:

http://blog.mountaingoatsoftware.com/the-ideal-agile-workspace

ScrumMaster Certification FAQ

2009-02-16T15:27:00.000-08:00

People have been sending questions about the Certified Scrum Master for Video Game workshop. Below are some common Q&A:

Where and when is the workshop?
Monday (3/23) and Tuesday (3/24). It's located at the International Hotel (across the street from Moscone). It runs from 8:30 AM to 5 PM each day.
Is there still room in the workshop?
Yes. It's about half full.
What does the workshop cost?
$1500 per attendee. There is a 10% discount when you send three or more.
Is there an agenda?
Yes, you can see the outline here. A more detailed agenda will be sent out prior to the class in email.
Is this for people who have never used Scrum or those who have Scrum experience?
The class typically has both. I suggest to attendees new to Scrum to read up on Scrum before the class, but that is not a strict requirement. There is a lot of information to absorb over two days and it's more valuable to focus on the principles of Scrum rather than just the basic definitions. I do cover the basics though.
How is this workshop different from the other Certified Scrum Master courses?
This is the only course with material and exercises specifically aimed at video game development. You'll learn the same principles of Scrum but you'll benefit from half a decade of practical application to our industry.
How much of the workshop is instruction and how much hands on exercise?
Almost 50/50. Hands on team work once an hour is very effective in learning these practices.
What does the "certified" part mean?
It means you'll be certified/recognized as a Scrum Master by the Scrum Alliance. Following the course you will receive a certificate and a one year membership in the Alliance.

Any other question? Please let me know. See you in San Francisco!

How long should a sprint be?

2009-02-11T09:43:00.000-08:00

What is the ideal length of a sprint? Sprints typically last two to four weeks, but many factors influence this::

The frequency of customer feedback
The experience level of the team
The time overhead for planning and reviews
The ability to plan the entire sprint
Balancing the intensity of the team over the sprint

Customer Feedback
The duration of a sprint depends on the amount of time the customers can go without seeing progress and providing input, or direction on the game. Some core mechanics require frequent feedback in the early stages of development, so a shorter sprint is required to be sure the game is headed in the right direction. Some teams don’t need such a rapid cycle of feedback (e.g. production teams) so a longer sprint is better for them.

The key idea is that the team must not have their goals changed within the sprint. If four weeks is unbearably long for customers to wait for a review, then they need to demand a shorter sprint.

Team Experience
The experience level of a team influences the length of an sprint. Teams that are new to game development, agile, or working together, should start with shorter sprints. This allows them to iterate on the practices and learn how to iterate properly. Teams that are new to Scrum should be discouraged from practicing longer sprints. New teams will generally approach a sprint like a mini-waterfall project; (see Figure below) inexperienced scrum teams will still approach development sequentially (one activity after the other). They’ll spend a couple of days exclusively in design, a few weeks creating code and assets and finally integrate, test and tune during the last few days of the sprint. They end up crunching at the end of the sprint to reach the finish line. This doesn’t give them the opportunity to achieve the best possible result.

Experienced teams will perform these activities more in parallel. Working this way creates better results and allows the team to iterate more during the sprint.

Planning and review overhead
Shorter sprints require a larger portion of a team’s time for planning and review meetings. Review and planning usually require a good portion of a day regardless of the length of the sprint. Even though planning for a shorter sprint may take less time, the remainder of the day following the meeting is never 100% effective. Imagine that you had a sprint that lasted one week. You’d probably spend one day that week in review and planning. That’s 20% of overhead!

Plan to party - Allow the team to have a little celebration time between sprints. Besides, game developers don’t need much excuse for a party!

Ability to plan the sprint
If the sprint goal is uncertain: if experimentation or prototypes need to be done then the sprint should be shorter. Uncertainty implies that the work required might be significantly different from the one anticipated at the start of the sprint. If this is the case, it’s better to change direction after two weeks than four.

Prototype sprinting - Some prototype teams have chosen extremely short sprint times of days!

Balanced Intensity
Sometimes four weeks is too long for a sprint. This is especially true of teams that are new to agile. As described above, new teams will work sequentially during sprints. This leads to a low intensity mini-design phase up front and a high intensity debug mini-crunch phase at the end. While the “mini-crunch” isn’t going to kill anyone, it’s not the most efficient way to work.
Teams will find what works best for them.

Choosing a sprint duration - On my last team, two week sprints felt too short. It was as though the review was too soon to “do anything too challenging”. A four-week sprint was too long to create a sense of urgency. We compromised and chose a three-week sprint because “it felt right.”

When is the sprint too long?
A product owner will usually limit a Sprint’s length to four weeks. Some may argue that some technical areas (e.g. engine or pipeline development) cannot achieve any significant progress in as little as four weeks. The need for longer sprints to show value is usually an indication that the technical practices need to change. Any development practice that can’t demonstrate progress at least once a month should be changed. Interim goals can demonstrate a reduction and have value. The longer a team goes without proving or disproving architectural assumptions, the greater the potential waste.

Who selects the sprint duration and when?
The customers and the team needs to be determine the duration of the sprint. If there is a disagreement, the product owner has the final say. The length of the sprint can only be changed between sprints and shouldn’t change frequently. Frequent changes to the length of sprints can be disruptive. It takes time for teams to adjust to this change; the rhythm and pace of a particular sprint length takes some time for the team to adjust to.

Whatever the duration you choose, don't be afraid to change it throughout the project. The conditions listed above will change.

My "Myths of Scrum" talk

2009-02-04T16:34:00.000-08:00

From the IGDA Leadership Forum:

It can also be found at:

http://video.google.com/videoplay?docid=-3758696344833692025

Waterfall Game Development

2009-01-22T11:45:00.000-08:00

In the dawn of video game development, a single person working on a game didn’t need much in the way of a “development methodology”. A game could be quickly developed in mere months. As the video game hardware became more complex, the cost to create games rose. Within a decade, instead of taking three or four person months to create a game, a game might take 30 or 40 people-months. Software and art production became the greater part of the cost of a releasing a game to market.

In response to the increasing risk, many companies adopted waterfall methodologies in attempt to reduce risk. Waterfall is forever associated with a famous 1970 paper by Winston Royce. The waterfall methodology employed the idea of developing a large software project through a series of phases. Each phase led to a subsequent phase more expensive than the previous. The initial phases consisted of writing plans, which gave detail to what and how the software would be built. The middle phase required writing the software. The final phase was integrating all the software components and testing the software. The idea was that each phase reduced risk before moving on to the following phases that were more expensive. A project would never return to a previous phase once that phase was complete.

The following figure shows what the waterfall phases for game development look like:

Waterfall Game Development

Waterfall describes a strict one-way flow of phases; once design is done, a project moves to the code phase and there will be no more design. In reality, no game developers use this method based on its original definition. Instead, most games use a sequential phase approach to game development. This approach weighs each phase sequentially in time (e.g. we do more concept work at the start and more debugging at the end), but does not impose the one-way flow that Royce’s model does.

Ironically, Royce’s famous paper illustrated how this process would lead to project failure. In fact he never even used the term “waterfall”. However the association stuck; when we use the term “waterfall” we are really referring to a sequential phase methodology. So don't bother adding a comment that "waterfall really isn't waterfall". We know!

The Project Manager Role

2009-01-20T09:11:00.000-08:00

Some organizations using Scrum will add the Project Manager role. Although not "officially" a role in Scrum, it can benefit the project by helping the Product Owner.

The Product Owner has a lot of responsibility. Their fundamental responsibility is to insure a Return on Investment (ROI) for the game; they have to take the currency of development cost and decide where to spend that currency every Sprint. They have to "know the mind" of gamers up to two years in advance and predict what they will want to play. It's no small role.

There are a number of things that make a Product Owner's job particularly challenging on a game development project:

Game projects can have a large staff, with a dozen Scrum teams or more. Projects may create a hierarchy of product owners to help communicate vision, but responsibility for ROI cannot be so easily delegated.
The Product Owner role requires vision and creativity. These skills don't always go hand-in-hand with those necessary to be mindful of costs and ship dates.
The "debt of production" can require more traditional project planning than Scrum-led projects that have true releases every several months.

If these challenges are not met, Scrum teams can lose track of time and cost.

Enter the Project Manager

I like to think of the Project Manager as the "Super Scrum Master" for the project. The Project Manager works with the Product Owner to insure that cost is always a consideration when evaluating the Product Backlog.

Let's use an example: if the Product Owner is thinking about layering a whole new mechanic that would allow the player to traverse levels in multiple ways, the Project Manager has to ask:

What cost does this add to level design and production?
Does this add play time or replay value to the game?

Maybe the answers to these questions don't exist...that means we have to add some stories to the backlog to "find out" first!

Among the Project Manager's responsibilities:

Facilitate the Product Owner's role (backlog maintenance and meetings)
Tracking costs, especially for production
Communicating with studio executive, publishers, license holders and outsourcing companies
Tracking project risk

The Project Manager on a Scrum project has to be a Scrum expert and evangelist. As each Scrum team on the project evolves their practices, the Project Manager will insure that they are continuing to work effectively with the other teams. One example of this would be the application of Test Driven Development and similar practices to build stability. It doesn't make sense for some teams to use TDD while others don't. The PM would have to step in and work with all the teams to insure that practices won't interfere or cancel each other out.

Project Manager is a natural evolution of the senior producer role for a studio applying Scrum.

The Golden Age of Iteration

2009-01-19T09:12:00.000-08:00

In the golden age of the video arcade, during he late seventies and early eighties, games like Pac Man, Asteroids, Centipede and Defender were gold mines. A single $3000 arcade machine could collect more than $1000 a weekend in quarters. This new gold rush attracted quite a few prospectors. Many of these “wanna-be” arcade game creators lost their shirt in the rush to release games. A manufacturing run of 1000 arcade machines requires a considerable investment; a poor game burned into these machines would return little on that investment.

Faced with millions of dollars of potential investment, arcade game developers sought to insure that the best possible game software was developed. Games themselves cost less than a single arcade box, so it was highly cost effective to throw bad games out and try again and again before committing to manufacturing hardware. As a result, game software development was highly iterative. Executives would fund a game idea for a month of development. At the end of the month they would play the game and decide whether to fund another month or move to field testing.

Companies like Atari would field test a game idea by placing a mocked up production machine in an arcade along-side other games. Several days later they would count the quarters that the machine collected and — based on the money collected — decide whether to mass produce the game, tweak it or cancel it outright. Some early prototypes were so successful that their coin collection boxes overflowed and led to a failure of the hardware!

This iterative approach help fuel the release of consistently high quality games from companies like Atari. The decline of Atari and the market in general in the mid eighties was caused by the larger proportion of inferior games released due to dropping hardware costs (through the introduction of cartridge based consoles). The financial “kill gate” of distribution cost disappeared and so did much of the disciplined iteration that insured better games.

Traps & Pitfalls of Agile Software Development - A Non-Contrarian View

2009-01-12T09:20:00.000-08:00

Sean Landis and the Salt Lake Agile Roundtable created a good list of traps and pitfalls of agile.

"Contrarians reject the majority opinion and often have personal reasons to degrade Agile. These writings often disqualify themselves through bias, thus failing to benefit the community. But non-contrarians - practitioners who tend to support the majority view - may be in the best position to drag the skeletons out of the closet."

1. Agile teams may be prone to rapid accumulation of technical debt. The accrual of technical debt can occur in a variety of ways. In a rush to completion, Iterative development is left out. Pieces get built (Incremental development) but rarely reworked. Design gets left out, possibly as a backlash to BDUF. In a rush to get started building software, sometimes preliminary design work is insufficient. Possibly too much hope is placed in refactoring. Refactoring gets left out. Refactoring is another form of rework that often is ignored in the rush to complete. In summary, the team may move too fast for it's own good.

This is a common problem discussed earlier here. Games can be impacted by design and art debt as well as technical debt.

2. Successful Agile development presupposes that team members will all act like adults. That's a euphemism for being competent and professional. Agile teams are expected to to accept a high level of responsibility and accountability. When they don't, things can fall apart really fast.

Don't expect everyone on the team to have the same level of competency and professionalism though. Teams need to have a mix. Teams will identify leaders that can mentor others on the team. However some teams can lack leadership and get stuck in the "storming stage".

3. Agile methodologies misunderstood may lead to team burnout due to an irrational culture of urgency. We even use the word sprint, a term that is not connotative of sustainability.

I really haven't heard of this or seen it. I suppose that we're a little battle hardened when it comes to crunch, so the constant level of urgency we see on Scrum teams doesn't seem like a big deal.

4. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be able to bear. Yet a dysfunctional organization is likely to place excessive hope in Agile as a silver bullet.

Oh yeah. This is a common one.

5. The high visibility on agile teams causes poor performers to stand out. The benefit is that the organization can take corrective action. In the absence of corrective action, poor performers may try forms of sabotage to avoid detection.

One of the biggest types of mistake I made would be "wishful thinking" about poor performers. These would be the people that team after team would reject. I would hold out hope for them to "turn things around"; maybe because they were smart or passionate about making games. In the end they always left (on their own or finally fired), but it always did more damage than it would have had I acted sooner.

You have to pull the band-aid off quickly to suffer the least pain.

6. Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals. Missing the big picture can lead to long-term failure at the expense of sort-term success.

This is a problem for agile teams that think planning is unnecessary or who have a poor product owner. This leads to "incremental and iterative death marches".

7. Agile can be hard on the product owner who has a lot of responsibility. They are often asked to provide real time requirements support, make feature and business decisions, define acceptance criteria, and be constantly available to answer questions. The product owner is often responsible for understanding and communicating the needs of the customer and the company. This role can become a bottleneck because it is unable to "feed" the development team fast enough.

Yes! Large projects need a PO for every Scrum team.

8. Agile is over-hyped, thus leading to unrealistic expectations. People are led to believe agile development will solve all their problems with minimal effort and experience disillusionment when it doesn't meet their expectations.

Backlash from the silver bullet myth. I often hear the phrase "yeah, we tried Scrum on a project and the project failed, so now we....".

Scrum doesn't insure success. At best it creates transparency so you can make better decisions. If you choose the wrong project or the wrong team for a project, Scrum won't insure success; it will point these facts out to you quickly. If you decide that the problems can't be fixed and the project must be canceled early, that's better than waiting until the end.

9. A variation on The Blame Game can arise. A moderately successful agile development team usually will no longer be the bottleneck. Other departments can no longer blame development and this may give rise to a shift in political games.

This is absolutely true. Troubled development projects hide a lot of problems in the rest of the chain. Marketing, licensing, etc. can be caught flatfooted by an agile team that delivers at a far steadier pace.

10. Too much power can be granted to the product owner when it comes to steering the product. If they have an agenda, they can cause a lot of damage. Agile teams often seem to lack sufficient checks and balances.

Yes. A Product Owner who ignores the value of iteration can cause problems. You don't want to replace a plan on paper with a plan in someone's head. A Product Owner has to communicate their vision and react to the emerging game.

11. Agile is too programmer-centric leaving it unclear how to balance work across an organization. There is a need for better documentation and coaching for non-development participants.

This is the purpose of "Agile Game Development" and what I do.

Thanks to Jason Yip for pointing out the original post.

"Sorry Goose, but it's time to buzz a tower"

2009-01-07T16:26:00.000-08:00

In 1990 I was a member of the team that was developing the avionics testbed for a experimental fighter jet called the YF-23. This work required me to live for almost a year at a McDonnell Douglas facility in St. Louis. Members of the team had gathered from all around the company to prepare the avionics for demonstration to the Air Force. We faced many imposing challenges; the various components of hardware and software had been separately developed and were resisting integration. The avionics were designed to survive destruction of up to half of their components and still perform their function. Unfortunately the actual hardware could hardly tolerate being installed. One key component, a fiber optic communication interface was so sensitive that 29 out of 30 initial boards produced failed before our final demonstration!

The team was led by a former F-14 pilot. He was an outstanding leader. He didn’t understand the details of how each of us did out jobs. He hadn’t written a line of code in his life. What he did very well was remove obstacles from our path.

We were guaranteed to see him every morning at the daily stand-up meeting. Scrum was largely unknown to the world in 1990, but apparently F-14 pilots knew how to have a stand-up meeting. Each of us, in turn, would describe our progress, what we were doing next and what problems we were having.

Our F-14 pilot-lead had this interesting habit that I have never forgotten: he used to trim his nails every day during this meeting. He focused on his nails, but you knew he was listening. I didn’t realize it at the time, but it forced me to speak to the group instead of to him. If the discussions got too involved, he would cut it off.

During one of the first daily meetings I reported that a McDonnell Douglas system administrator was not giving us access to a computer as he had promised a week earlier. It was cutting into our efforts to test the avionics. The administrator was being a jerk to us contractors.

As soon as I told the story, our lead’s head snapped up. With a steady glare he repeated what he heard me say. I verified that he had heard me right; the administrator was messing with the team. I thought I was in trouble, but he didn't say anything else about it.

Five minutes after the conclusion of the meeting, we heard our lead swearing at the top of his lungs at the administrator. They must have a class for F-14 pilots on the creative application of profanity. It was impressive to hear. It was even more impressive to realize that our pilot-lead had our back. He was our “wingman”. As Tom Cruise learned in “Top Gun”; you never leave your wingman.

We received access immediately and never had another problem with the administrator. It was a pivotal moment for the team. We started the day as a collection of contractors from around the country. By noon we were the team you didn’t mess with. Did it effect our work? You bet. We didn’t have any excuses not to solve our own problems with the dedication demonstrated by our lead.

Our lead wasn’t a Scrum Master, but he would have been a good one. Our daily meeting wasn’t a “Daily Scrum”, but it sure served the purpose of one. Scrum invented very little. It was derived from observing what worked and formed a framework to encompass these practices. While I don't teach Scrum Masters how to be as effective with their profanity as our lead was, I'm sure to let them know that their job is to be a wingman for their team.

Announcement: Certified Scrum Master course at GDC

2009-01-06T14:50:00.000-08:00

I'll be giving a Certified Scrum Master for Video Game Development course/workshop in San Francisco the week of GDC (on Monday 3/23 and Tuesday 3/24). The course will focus on the game specific application of Scrum to game development including team exercises.

Location:
It's being held at the new Intercontinental Hotel, one block from the Moscone Center.

Dates:
Monday 3/23 and Tuesday 3/24

Registration fee:
US $1500 per attendee

Registration and further details for the class can be found here.

No prior experience with Scrum is necessary. At the conclusion of the course, all attendees will be Certified Scrum Masters.

Industry Broadcast Hits 50

2009-01-01T11:16:00.000-08:00

Industry Broadcast, the podcast for the games industry, has hit the 50 article mark - about 16 hours of ear candy. The site carries a some of my articles and those by some of my favorite bloggers including Daniel Cook and Noel Llopis.

http://www.industrybroadcast.com/

Learning about production in pre-production

2008-12-21T09:50:00.000-08:00

Have you every been on a project with a date scheduled that says "Start production"? This is the date when the team transitions from pre-production to production and a ton of people (internal or outsourced) join the team to create the 10+ hours of gameplay to ship? The idea is that the team knows what's fun about the game and can build a ton of assets in parallel.

Did that deadline really work out? Was the team really ready to "go into production"? Most aren't!

The main goal of pre-production is to build knowledge, or learn about the game. We want to know how fun our game is, how we are going to make it and how much it is going to cost. Building this knowledge requires iterating on the areas where we lack knowledge. We choose what to work on based on a priority of the knowledge we want to build. For example, we’ll iterate on the core mechanics first because the provide the greatest knowledge of the value they provide to the game. We’ll also iterate on building characters and levels to learn how much effort and cost is required to make many more of them in production.

We often focus more on learning about the core mechanics, or the fun of the game, and not enough on how we are going to make it. This results in many projects exceeding their production budgets or schedules. What we need to do is to learn the cost of building assets during pre-production as well as learning about how fun the game is going to be. Both of these go hand-in-hand since we can’t determine the cost of production assets until we know what makes levels fun.

Let’s look at level production. Level production can easily require 50%-75% of the production budget. We need to refine our understanding of the effort to build levels during pre-production so that we do not build mechanics which inflate production costs beyond our budget. For example, a fantastic feature for the consumer would be a mechanic that allowed every object in the environment to be destructible. However implementing this may also double the effort to create levels since building destructible geometry everywhere requires far more effort. By knowing these cost implications, the Product Owner (PO) can better judge the value of adding this feature or not.

Learning about production cost is an iterative process. We begin with a range of estimates based on existing knowledge (perhaps from a previous title) and iteratively refine these estimates during pre-production. As we move forward in pre-production, we are building a vocabulary. At first we are establishing the alphabet. This may be the second-to-second game-play experiences such as battling one enemy character. We then start building words from our alphabet. These are the 10-60 second loops of gameplay, perhaps dispatching a wave of AI characters in a room. From here we build sentences, then paragraphs and chapters of larger loops of game-play.

We follow this same pattern in building levels. We don’t start by building an entire level until we build a vocabulary of rooms. We may build several different types of rooms with different experiences (e.g. lots of AI in a plain room followed by a boss in an ornate room). We don’t wait until our room vocabulary is final before we start building our level vocabulary. Building a shippable level before we have a minimum room vocabulary will waste a lot of time. This waste is seen on many milestone driven projects. Teams feel compelled to show a level of polish to their publisher when the gameplay is still undetermined. These polished milestone levels end up as either waste or debt; They are eventually thrown out or require a great deal of rework when the team learns more about the game-play.

Firing tracer rounds

Sometimes it’s valuable to demonstrate a 20 minute experience with a quick and dirty level filled with stand-in assets to build knowledge of our level goals. This in turn may influence the lower levels of our vocabulary. Another valuable test would be to create a single room with as much graphics polish as your engine can muster to help refine our visual DNA and target. Although these assets may be thrown away, their cost is easily worth the knowledge they create for your project and customer. The key is to not waste more effort than the knowledge is worth.

The PO is responsible for ROI

Since the PO owns the return-on-investment for the project, they need to demand that the team demonstrate improved knowledge of production costs refined through pre-production iterations. They do this through separate stories or conditions of satisfaction on existing stories. An example is “demonstrate the cost (in actual hours) to create the X level”.

The last pre-production release should have a level or two which demonstrates the major range of vocabulary at potentially shippable quality. This is the only way the team can demonstrate that the knowledge of production costs have been learned.

Scrum for artists

2008-12-10T16:18:00.000-08:00

“Why use agile for art? When Michelangelo painted the ceiling of the Sistine Chapel he wasn’t using agile. He had a plan to paint the entire ceiling.”

These words were spoken by an artist I worked with when we first started using Scrum. Little did I realize at the time that Michelangelo might have been better off using a more agile approach to painting the ceiling. He had no idea about how to painted images on a curved and segmented ceiling. He signed a fixed price contract calling for 12 figures painted. Four years later he had painted 300 figures. There was a great deal of trial and error and false starts. It’s no wonder he referred to it as one of the worst experiences of his life.

Historical accuracy aside, the questions and impressions about how relevant agile or Scrum is for art creation remains common.

The following are common perceptions about Scrum from artists:

Scrum was created for programmers.

Scrum is largely used in software development projects, but it wasn’t created for programmers.

In fact it has no practices specifically for any discipline. Scrum was defined by studying how many different products (such as cameras and cars) were developed. It’s just as applicable for artists as it is for any other discipline.

Art production runs on a schedule. We can’t be iterative.

With video games, art and technology have to serve the gameplay mechanics together to create a great experience. We have to explore how all these components work together to create the best possible experience. Once we discover this, we can schedule making 10 to 12 hours of this experience. Exploring what we need to create before we mass produce assets is beneficial. Cross-discipline teams support this.

Artists often want to work with other artists.

This is the same with other disciplines. They speak the same language. The problem again is that our product requires an integration of all disciplines. This forces some form of collaboration eventually. Unfortunately a studio structured to separate the disciplines (though a heavily matrix management structure for example) will discourage collaboration or at least make it more difficult. If an artist is evaluated by the number of assets they can create (through promotions or salary reviews), then they will optimize their work along this line. Interrupting an artist to help with a game problem will impact the number of assets they can create, so they discourage those interruptions.

Scrum might be good for preproduction but not for production

It’s true that Scrum is better for preproduction than production. Production requires a more defined work flow that must create a fixed amount of gameplay to ship on a specific date. The Scrum practices should be modified by the team in production. However this doesn’t mean we won’t have challenges in production. The game will still continue to throw challenges at us that we don’t expect. These play havoc with the best planned schedules. Artists creating assets will still need rapid response to problems emerging that they can’t solve. They will need to continually find ways of working more effectively through improved tools and pipeline processed.

While the iterative nature of development will slow during production, the need to incrementally improve what we are making and how we are making it will never slow down.

What specific problems are we trying to solve on the art side with agile? How is this going to make better for the artist and team in general?

We need to know if we are creating the right thing and not wasting time.

Parallel development of assets and technology that the assets depend on is a traditional source of wasted effort. Engine development is often started with optimistic feature sets, performance goals and schedules. We can’t simply shift engine development to iterative development without an iterative asset creation effort. Iteration on technology requires an ongoing conversation and experimentation with what looks and works best. Every artist knows that the quality of a complex asset such as a level depends on a tradeoff between polygon count, texture quality, lighting complexity and the palette of effects available. None of these qualities is independent of the others. Some levels will require more effects than others and there will be a envelope of tradeoffs that occur to balance the overall aesthetic.
We want to build the knowledge of these tradeoffs during engine development before we commit to production. This requires daily collaboration between the engine creators and the first order customers: the artists that use the engine.

We need to have a working build.

Nothing will impact progress more than not having a build that fully works. Graphics bugs that impact the visual quality can prevent an artist from fully evaluating their work. What’s worse, addressing these problems can be put on the back-burner by a separate technology group that is solving problems more relevant to their own local needs. Cross-discipline teams are more likely to have someone on the team who can solve the problem or know someone who can.

We need faster tools and pipelines

Artists are often constrained by the limited or slow control they have over the game. There are often barriers to iteration that slow their progress down. Less iteration means lower quality. The fundamental problem is often that the programmers who have control over improving tools and pipelines are not impacted by their limitations. They don’t see how slow it is to change a texture on a game and see how it looks in the game. They are focused on the tasks that are important to their local team.

As with the build issues, having a programmer on a cross-discipline team experience the drag on the team’s velocity that poor tools and pipelines will help solve the problem. Smoothing the entire pipeline from concept to user experience will allow a better game to be made. Cross discipline teams are the best way for this to happen.