Friday, December 25, 2009

HOW TO FAIL Learn to Let Go: How Success Killed Duke Nukem

Good Wired article about Duke Nukem Forever and what happened at 3DRealms:

Many take-aways here:
- Perfection is the enemy of "good enough".
- The danger of the "it's done when it's done" approach.
- The danger of success.
- The second system effect.

Tuesday, December 22, 2009

Book Review: Succeeding with Agile

Mike Cohn's latest book: "Succeeding with Agile" is a "must read" for any agile developer. It's not meant to be the first book for those considering Scrum, but if you've read that first book, attended a Certified Scrum Master class or have applied Scrum for even a day, buy this book now!

Scrum is like chess. It's very simple to learn to start using, but challenging to master. It requires ongoing learning and experimentation to find what works best for your studio and culture, while avoiding the "bad changes" to Scrum practices that can embed organizational flaws.

Scrum pressures managers to focus on mentoring and coaching. It requires overcoming the inertia of "the old way", which includes people doing things for the benefit of their position and not necessarily for the benefit of the product. It involves buy-in from departments like HR, which can resist the emphasis on team performance. It demands people take ownership in areas they had no ownership and give up ownership in areas they once ruled over. It challenges the silos of discipline and the barriers of project managed "phases". It pressures us to change how we test, program, create content, review, manage, promise, motivate, etc.

It's no wonder that understanding Scrum practices is not enough and that so many Scrum teams fail to achieve their full potential. Mastery requires learning and experimentation. Learning comes from many sources including coaching, training, experience and reading books like "Succeeding with Agile".

Succeeding with Agile:
Mike Cohn is one of the founders of the Scrum Alliance and the author of two previous agile books: "User Stories Applied" and "Agile Estimating and Planning". Both these books built upon various knowledge of beneficial agile/Scrum practices and communicated them effectively. Mike is an experienced coach, trainer, product developer and writer (visit His latest book "Succeeding with Agile" is his best.

This book covers every angle of your organization from executives, HR, marketing, developers, IT and even facilities! It covers every aspect of what impacts agile teams and how to handle every conceivable challenge. It examines Scrum roles and practices in depth to help you find ways to find improvement regardless of your company's level or experience.

Part 1: Getting Started describes a number of ways that Scrum can be introduced into all types organizations. It examines a number of patterns and introduces the ADAPT acronym for adoption, which is brilliant.

Part 2: Individuals focuses on overcoming resistance, examining the changes to roles inside and outside the development team and the influences on the technical side of development. 

Part 3: Teams is the core of the book. It spends 150 of the 450 total pages on the roles, practices, dynamics and organization of teams. Solid gold advice on helping teams succeed.

Part 4: The Organization looks at the entire company structure, how it's influenced by and can continue to influence agile teams. It discusses ways that large scale and distributed Scrum teams work.

Part 5: Wrapping things up points the way forward. How do we measure how the teams are doing on a regular basis? How do we gauge how well the teams have adopted every aspect of agile adoption. This part shows us how.

The writing is conversational and engaging. The figures and tables are numerous with an outstanding style. The layout of the book includes numerous sidebars that discuss common objections, quotes from developers in the field and practical things that you can try immediately.

This is the best agile book on the market. I'm not just saying that because I've worked with Mike extensively. It is the best.

Friday, December 18, 2009

"Scrum is dangerous"

A good quote from Lyssa Adkins via Tobias Mayer's blog.  Both Lyssa and Tobias are Scrum Trainers and thought leaders.

As the Orson Scott Card quote says, there is something in us that desperately wants to “safely interpret dangerous things in ways that don’t require us to change our lives.” Is Scrum dangerous that way? Absolutely. If you are doing Scrum well it will require you to change your life. You will have to give away your belief that having a checklist makes things run smoothly. You will have to stop chasing the perfect process and, instead, start cultivating your ability to trust the resourcefulness of others. You will cease using line items checked off on a plan as your measure of value. You will face your fears, all of them, about yourself and other people. You will stop making progress and start making products.

Interview: SOE's Yanagi Talks DC Universe Online's Birth & Scrum

On an everyday basis we have playtests. All the different Scrum teams -- we have a combat team, a content team, an environment team -- they all do their playtests, and they can see what the other teams are doing, and see how their piece fits into the whole.

...using agile is great because, as those issues pop up from that Scrum team's perspective, if they're focused on balancing or getting all these powers working together, that can be their highest priority that they have to deal with.

Sunday, December 13, 2009

Scrum used on Left 4 Dead 2

Former Valve Designer Kim Swift on using Scrum at Valve for Left 4 Dead 2.

Full Gamasutra article.

It sounds kind of funny, just because it's really quick. A quick sequel, which is not Valve's well‑known trait.

KS: Yeah, definitely. We're pretty proud of ourselves for not moving at "Valve time". We practiced a new organizational tool. We used the Scrum method this time. We decided to give it a shot, and it's worked really well for us on the team.

And also, heading into the project, we were pretty sure about what our deadlines were, so we were able to try and be more deliberate with our planning to actually get the sequel out.

So the first game wasn't developed under Scrum and the second one is?

KS: Yeah. We decided to give that method a try.

So have you been seeing more productivity? Obviously, you have one more mission to do. Do you have a perceptible increase in productivity?

KS: I think more than anything it helps us prioritize what to work on. Since we knew that our shipping date was a lot sooner, we were able to sort out which ideas were actually doable in that amount of time, and that we knew were actually going to be successful, rather than trying a whole bunch of different stuff that wasn't necessarily going to be what we shipped.

Friday, December 11, 2009

Brutal Legend and Scrum

"For Brutal Legend, Double Fine adopted agile development, hoping to eradicate the rampant crunching that defined Psychonauts' development cycle -- and it worked:"

Gamasutra article

Repost: the Heart of the Team

I came across this post written a few months back. Shelly Warmuth had some good words to say about the goal of a Scrum team.

At the heart of the scrum team is the interaction of the team. A daily meeting around the task board is interactive, vibrant, collaborative, visual, and tactile. It is a visual way of showing the goal the team is striving toward and the progress they are making. They, each and every member of the team, are peers.

They own the goal. It's a team effort. They gather around the board to align themselves with each other, to honor each others' contribution to the effort, and to course-correct when they are missing the mark. They argue, discuss, share, learn, continually improve, celebrate, boost each other up, and create solutions.

There is another thing that scrum does for the team: it creates transparency. Since scrum depends on collaboration and continual forward progress, problems are addressed by the team as they crop up instead of dealing with them later or covering the problem under a layer of "spin".

A structured, militant environment will never create a team. A team works together toward a shared goal. A group works together toward a goal given to them. Scrum is messy, and noisy. It lives, it breathes, it stretches, it morphs and it expands. Interaction is the heart of the team. The heart of scrum, is the team.

Friday, December 04, 2009

How do we want to make games?

Being a full-time Scrum trainer and agile blabber-mouth has been an interesting experience. I'm between two worlds. I'm not really a game developer any more and I don't want to be a "methodologist" and climb some ivory tower to talk about project management theory all the time. I want to add the most value where I can helping make great products. Right now, this is the best way for me to do that. One value I try to add is by helping "great teams" exist.

Over the course of 20 years I have been a part of several great teams. But the time spent on these teams has accounted for less than 10% of it all. Being a part of a great team was an amazing experience. On such a team, we couldn't spend enough time working on the game or thinking about it when we were away. We were completely absorbed. We all shared a common vision and produced something fantastic and successful. Our passion and productivity made it more than just "work" and it was always a sad occasion when a game shipped and we were all "reallocated" to different projects. We knew something special was going away. I've always sought ways to return to this state of being part of a great team or finding ways to help them exist.

Making great games, being highly productive and absorbed in the enjoyment of it all. Isn't this how we want to be making games? Isn't this the environment that every studio should focus on creating?

What prevents great teams from existing?
  • Goals we don't believe in.
  • Lack of visibility or ownership in what we do.
  • We don't feel like we are a part of something great or adding much of value.
  • Working with groups of people that are not really "teams".
  • A bad physical environment.
  • Spending a great deal of time doing "other stuff" that don't add directly to the value of the game.
There are many more. It would seem that great teams are easy to prevent.

Great teams are not about "methodology" or "process". Some of the great teams I've been on were in waterfall environments. However, methodology can work against great teams. For example, overzealous "resource management" can prevent them from forming long enough to be great.

It's not about culture either. I've seen these teams form in some of the most dysfunctional cultures you could imagine. Culture can also support or work against great teams, but it doesn't determine them.

Great teams have more to do with the right place, the right time, the right people and surfing the edge of chaos. There are many books about great teams. I've read quite a few. They build on the list of things to help create fertile ground and to support them, but there is no science or method. Great teams are complex, like many things in nature. They are like flocks of birds that form amazing patterns, a perfect ocean swell to surf on, or the bumper crop of huge vegetables that grows from your garden every few years.

All of us who think about being part of great teams or try to find ways to allow more of them to form can't act like mechanics or scientists plugging in inputs. We have to think like gardeners. We do our bit to create the right conditions (trimming, weeding, fertilizing, watering, etc), but it's largely outside of our control that the garden will be great. We have far more control to do damage. It require subtle control to help. But full control? It's an illusion.

Nothing worthwhile is easy it seems, but that's what keeps things interesting!

Sunday, November 08, 2009

Penny wise, pound foolish

Are we harming ourselves by "saving time" not building quality into code up front?

One of the concerns about Test Driven Development (TDD) is the impact on short-term velocity; writing a function plus the tests requires more time up front than writing the function alone. The trade-off is in quality. But how much velocity do you lose and how much quality do you gain?

Well here are some numbers from the study: "Realizing quality improvement through test driven development: results and experiences of four industrial teams"
The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

Now the question becomes "how much time do we save in the long run in exchange for the extra time we spend doing TDD?" There have been numerous studies about that which show productivity increasing over the life of the code between 0 and 65%. I believe, and have seen, that for games the benefits are much higher. This is because game development productivity is more dependent on defects; we use the game to build the game. Tools are integrated with the game to allow rapid iterations that are necessary to get things right.

For example, consider Unreal Engine 3. In UE3, artists, designers and programmers use the tools embedded in the engine (UnrealEd) to add behaviors, assets and tune mechanics. If the build stability is low, if it's crashing all the time, it impacts not only the programmers, but most of the other disciplines as well.

Think about a team working on a mass-market game. There can be 100 developers working on it. How many are programmers? About 25? Even if TDD didn't speed up code development, would a 40% to 90% decrease in the defect rate still improve the velocity of the entire project?


Friday, October 30, 2009

Reminder: Certified ScrumMaster for VG course in SF soon

10 days left until the course in San Francisco November 10 & 11.

Open seats are filling. See you there!

The "Double Standard of Scrum" Myth

I frequently hear the following concern about Scrum from developers considering it:

"We hear one of two things about Scrum. Either Scrum was successful or if the project using it failed, it did so because they weren't using Scrum correctly."

This double standard creates justified skepticism on their part. This is a reaction to the Silver Bullet Myth.

My response is that Scrum can't be blamed for failure or even credited with success. Teams succeed or fail due to many factors: technology, capability, vision, communication, collaboration, talent or even the underlying idea of the game. Scrum creates transparency into how well these elements are working, often in a measurable way, but that's all. It doesn't prescribe what to do when sprints repeatedly show the game isn't fun or the velocity of the team is low. In some cases, the best you can hope for is to "fail fast".

Success is challenging. The reason is that everyone shares the same goal of success and that raises the bar. It demands talent, passion, diligence and focus if you hope to make a better game that will stand above in the competition to capture sales. For this reason, there will never be a predefined process for creating successful new games.

Friday, October 16, 2009

Montreal VG ScrumMaster Course November 18-19

Are you looking to energize your teams, reduce costs and increase performance? Has crunch, missed schedules and budgets become harder to avoid? Scrum and agile practices have helped many studios improve product development and the workplace environment.

Learn to establish and improve Scrum in your studio by becoming a ScrumMaster in the only workshop that focuses on game development from the Certified Scrum Trainer with 15 years of game development experience.

This two-day course provides the fundamental principles of Scrum through hands-on experience and interactive project simulation. During the course, attendees will learn why such a seemingly simple process as Scrum can have such profound effects on an organization.

Attendees learn to apply practical, project-proven practices that have worked for numerous video game projects
  • The essentials of getting a project off on the right foot
  • How to build a product backlog and plan releases
  • How to help both new and experienced teams be more successful
  • How to successfully scale Scrum to large, multi-continent projects with team sizes in the hundreds
  • How to help producers, artists, designers and programmers work together effectively
  • How to work with publishers and others outside the team who may not be familiar with Scrum
  • Tips and tricks from an instructor with 15 years of game development experience and 5 years of experience applying Scrum to game development

Participants who successfully complete the course, will become Certified ScrumMasters through the Scrum Alliance and receive a two-year membership in the organization where additional ScrumMaster-only material and information are available.

Pricing and Availability

The Certified Scrum Master for Game Development Course is being held just after the Montreal Game Summit on November 18th-19th. The course has limited seating and is available for $1600 by visiting
Discounts are available for members of the Alliance Numerique or groups of four or more.

More details for the course material can be found at

Monday, October 05, 2009

The Limits of Lean

Jurgen Appelo has posted yet another well written and insightful blog entry, this one called The Danger of Lean: Ignoring Social Complexity. He identifies that Lean Development methods do not emphasize teams and collaboration:

Just pick your average Lean software development book, go to the index, and try to find references to concepts like motivation, creativity, innovation, personality, or fun. You probably won’t succeed.

Wednesday, September 30, 2009

San Francisco ScrumMaster Course November 10-11

Are you looking to energize your teams, reduce costs and increase performance? Has crunch, missed schedules and budgets become harder to avoid? Scrum and agile practices have helped many studios improve product development and the workplace environment.

Learn to establish and improve Scrum in your studio by becoming a ScrumMaster in the only workshop that focuses on game development from the Certified Scrum Trainer with 15 years of game development experience.

This two-day course provides the fundamental principles of Scrum through hands-on experience and interactive project simulation. During the course, attendees will learn why such a seemingly simple process as Scrum can have such profound effects on an organization.

Attendees learn to apply practical, project-proven practices that have worked for numerous video game projects
  • The essentials of getting a project off on the right foot
  • How to build a product backlog and plan releases
  • How to help both new and experienced teams be more successful
  • How to successfully scale Scrum to large, multi-continent projects with team sizes in the hundreds
  • How to help producers, artists, designers and programmers work together effectively
  • How to work with publishers and others outside the team who may not be familiar with Scrum
  • Tips and tricks from an instructor with 15 years of game development experience and 5 years of experience applying Scrum to game development

Participants who successfully complete the course, will become Certified ScrumMasters through the Scrum Alliance and receive a two-year membership in the organization where additional ScrumMaster-only material and information are available.

Pricing and Availability

The Certified Scrum Master for Game Development Course is being held just prior to the IGDA Leadership Forum on November 10th-11th at the SF Airport Marriott. The course has limited seating and is available for $1500 by visiting
Discounts are available for those attending the leadership forum or groups of four or more.

More details for the course material can be found at

Wednesday, September 23, 2009

Development cultures

An interesting thing about traveling around the world is to compare the subtle differences between cultures. Besides hearing people's views and opinions, I love to observe things in their environment. How people drive, the graffiti, the amount of litter, the colors they choose are all interesting. As I type this, I'm in a nice hotel that is very clean and has had a lot of attention paid to the decor. However, half the stuff seems broken or poorly designed for use. Most are little things. For example, I had to go down to the desk to ask how to hook up the ethernet. The rooms don't have guides. "Oh, that jack is on the bottom of the phone" I was told. I then discovered that there was no phone. "Oh, some rooms don't have a phone". I was moved. Again, more questions, but the phone was broken. So it was back to the front desk. This went on and on. The staff seemed used to the questions and there were a lot of them being asked. I hear that this is the norm for other hotels around here.

Interesting contrasts exist for studios developing games. The differences in cultures between studios in the same town can be greater than those in separate countries! For example, there is often a dominant discipline in the building, which manifests itself in the tool chain. There is a level of tolerance to defects....sometimes little tolerance, sometimes a lot. There is a wide variety of process discipline and who "owns" the process.

The bottom line is that there is no single superior development culture. You can't look at any of these studios and predict which will make the hit game based on culture alone. You can certainly predict which one is going to make the game at lower cost with less crunch and stress, but those benefits don't get printed on the back of the box.

Sunday, September 20, 2009

Agile and Fixed Ship Dates

A common impression about agile is that it does not allow games that use it to ship on a fixed schedule. The impression is based on the idea that agile teams don’t plan, but simply iterate with a very short horizon - they just don’t know when the project will end!

Although most games have a ship date, many of these are considered “firm” rather than “fixed”. Firm ship dates are established by publishers to fit portfolio or budget projections. A firm ship date will drive the project, but if it desperately needs another month or so of work to achieve far better results, it won’t be a disaster to slip the date. Fixed ship dates, on the other hand, are critical for the success of some games. Examples of games with fixed ship dates are those that must ship simultaneously with a movie release or games like Madden Football, that must be on shelves by the start of each NFL season. The penalty in lost sales for missing these dates is major.

How is a project with a fixed ship date managed differently from one that is not? Mainly it is the way risk is handled. Risk is uncertainty about what a team is creating and how it is going to build it. For example, if we want to dedicate 20% of our project budget to creating a cooperative online deathmatch mode with AI opponents for our game, a few of the uncertainties might be:
  • Will the AI work online?
  • Is 20% of the budget budget enough to create a fun and complete experience?
  • Will problems in other areas delay work or take people away?
The list can go on. Any one of these can threaten the project’s schedule and result in the feature being dropped after almost 20% of the project’s budget has been spent on it.

So how is risk handled? Developers often try to plan and schedule their way out of risk by creating exceedingly detailed plans that attempt to identify the solution to every foreseeable problem. Unfortunately, since the danger lies in what a team does not know, it’s certain that the tasks required to overcome risk will not be identified up front. The best way to handle risk is focus on answering the unknown: creating knowledge.

Creating knowledge and value is important for any project, regardless of the ship date. For projects with fixed ship dates, the prioritization of work to reduce risk is a bit higher. For example, if a movie-based shooter game with a fixed ship date has to decide between shipping six months after the movie’s release or dropping online gameplay, they will be more likely to drop online. A game that is not based on such a license, which instead has a firm ship date, is more likely to be delayed to ensure the feature is included.

So back to the original question: Does agile aid or impede a project’s ability to achieve a fixed ship date? Executed properly, an agile project has significant advantages over other methods. There are two core principles behind this advantage:
  • Prioritizing to create knowledge and reduce risk. Focus on delivering high value and addressing risk early. Fixed ship dates only allow a project’s staff or the scope to vary. Increasing the number of developers on a troubled project usually doesn’t help. Brook’s Law says that “adding manpower to a late software project makes it later”. The same applies to game development. The best option is varying the scope, or feature set, of the project. Identifying the best features that fit within the schedule is critical for the success of a game with a fixed ship date.
  • Not postponing debt. Frequent integration, immediate defect correction and maintaining target performance will prevent late surprises that require rework and delay. When projects with fixed ship dates postpone critical work to post-alpha, they often meet with disastrous results.
The tools for applying these principles are the product backlog and the “definition of done”. The product backlog clearly lays out the order of work to be accomplished. The order is determined by the priority of features on the list. Usually this priority is determined primarily by the value of each feature to the consumer, but for a game with a fixed ship date, the element of schedule risk must often take precedence over value. An example of this is having a team do an early spike to mock up a full level. This would create early knowledge about the level dimensions to better refine the production requirements and resources. Doing this constrains some of the options for emergent gameplay, but for a fixed ship-date it might be necessary to know this information sooner than later.

The “definition of done” is the agreement between the developers and the product owner about how much each feature must achieve before it is considered done for the sprint. If a game must ship on all platforms on the same day as a movie release, a product owner might include “running on all the platforms” as a part of the definition of done earlier in the project than they normally would. While these additional criteria may slow teams down, especially if the platform technology isn’t fully mature, it will accelerate improvements there and create more knowledge about the risks of those platforms earlier.

Agile and long-term planning
Agile methods don’t attempt to plan away uncertainty with large documents, but they also don’t ignore it. They simply tailor the practices to the different level of uncertainty over time. Planning for the short term , such as sprint goals, are done at a far higher level of detail than most. Planning for medium range goals, such as release planning, is less detailed, but receives continual refinement. Long range planning for ship dates, production scheduling, etc are also continually refined and influence short-term planning. For example, an agile plan won’t say “production will start on September 14th” a year in advance. It will refine a range of times over the course of pre-production. The reason is that not only will we gain knowledge about production in pre-production, but the debt itself will actually change! As we discover or even change some of the features of the game, they will alter the amount of time assets will cost to be produced. I have an entire chapter in my book dedicated to long-term project planning, so make sure you buy a copy in early 2010! ;)

Too many times, fixed ship dates result in little innovation or a poor game that must be shipped before it’s been properly polished. Games released with movies have long had a reputation for low quality. This doesn’t need to be the case. By eliminating the waste of dropping features at the 11th hour, after months of work has been dedicated to them, is a good place to start.

Sometimes a fixed ship date is impossible to achieve. A risk-based approach for developing completed features will not work miracles, but it will expose the bad news sooner than later.

Sunday, September 06, 2009

Attending the Montreal Game Summit in November

I'll be presenting at the Montreal Game Summit this year, talking about Lean Production. It's a great conference in a great city. Someone with a camera cornered me there last year and shot this video. After seeing it, I vow to never go beardless makes me ramble and say things like "lean is a branch of agile"! ;)

It looks like the Alliance numérique is up for hosting another Certified Scrum Master for Game Development course just before the summit. I'll have an announcement for that soon.

Friday, September 04, 2009

Certified Scrum Master for Game Development course in San Francisco on November 10-11

Announcing a two day Certified ScrumMaster for Video Game Development course in San Francisco at the Airport Marriott on November 10th & 11th, just prior to the IGDA Leadership Forum.

This two-day course not only provides the fundamental principles of Scrum, it also gives participants hands-on experience. This course puts theory into action through extensive use of exercise and a project simulation. All exercises and discussions are specifically tailored for those working in video game development.

During the course, attendees will learn why such a seemingly simple process as Scrum can have such profound effects on an organization. Participants gain practical experience working with Scrum tools and activities such as the product backlog, sprint backlog, daily Scrum meetings, sprint planning meeting, and burndown charts. Participants leave knowing how to apply Scrum to all sizes of projects, from a single collocated team to a large, highly distributed team.

The price for the course is $1500. IGDA members and non-members attending the Leadership Forum on November 12 & 13 receive a discount.

More information about the course is here.
Register here.

Tuesday, August 18, 2009

Speaking at Austin GDC

I'll be at the Austin GDC, speaking on Wednesday, September 16th. My session is called Lean Production. Please send a note if you are going and have a chance to chat!

Thursday, August 13, 2009

Announcement: Certified Scrum Master course in Taipei

I am teaching a Certified Scrum Master course in Taipei with cotrainer Bas Vodde (coauthor of Scaling Lean and Agile Development) on October 19-20.

Details and registration are here.

Sunday, August 09, 2009

Announcement: Certified Scrum Master course in Seoul Korea

I am teaching a Certified Scrum Master for Game Development course in Seoul Korea with cotrainer Bas Vodde (coauthor of Scaling Lean and Agile Development) on October 19-20.

Details and registration are here.

Saturday, July 18, 2009

Mike Cohn's Next Book

Mike Cohn's two books (User Stories Applied and Agile Estimating and Planning) are two must-read agile books and his next book, Succeeding with Agile: Software Development Using Scrum, is moving closer to being released.

I've read the draft chapters and it is a fantastic book. If you want to get a jump on reading a rough cut version (1/3rd so far), go over to safari:

Thursday, May 28, 2009

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?

Tuesday, May 19, 2009

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.

Friday, May 15, 2009

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.

Friday, April 24, 2009

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).

Tuesday, April 07, 2009

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:
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:

View Clinton Keith's profile on LinkedIn

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.

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.

Wednesday, April 01, 2009

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!

Sunday, March 29, 2009

GDC Wrapup

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!

Saturday, March 21, 2009

GDC Week

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!

Thursday, March 12, 2009

Certified Scrum Master for Game Developers in Boston

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.

Friday, March 06, 2009

Monday, February 16, 2009

ScrumMaster Certification FAQ

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!

Wednesday, February 11, 2009

How long should a sprint be?

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.

Thursday, January 22, 2009

Waterfall Game Development

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.

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!

Monday, January 19, 2009

The Golden Age of Iteration

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.

Monday, January 12, 2009

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

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".

. 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.

Wednesday, January 07, 2009

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

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.

Tuesday, January 06, 2009

Announcement: Certified Scrum Master course at GDC

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.

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

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.

Thursday, January 01, 2009

Industry Broadcast Hits 50

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.