Big documents and bananas

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

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

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

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

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

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

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

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!