Friday, December 31, 2010

Tools quote

From Don Reinertsen's "Managing the Design Factory":

"We must continue to think about what we are doing and avoid value-laden labels that oversimplify decisions. It is for this reason that this book focuses on tools rather than rules and rituals. A tool enhances our ability to achieve a certain effect in a certain contact. A hammer is good for sinking nails but a poor way to drive screws".

Monday, November 22, 2010

Tips for Effective Daily Stand-up Meetings

When visiting a studio, I'll often ask to observe the daily stand-ups meetings.  It's the best way to sense where a team is and how to focus coaching time for the visit.  An effective daily stand-up meeting is an energetic swarm of committed team members that need to quickly synchronize their efforts and identify anything that is threatening their shared goal.

Some daily stand-ups (or daily scrums), aren't like this.  They are monotonous, manager-led and pointless to the attendees.  Teams here lack any sense of commitment or ownership and they eventually question the merit of the practice and perhaps even abandon it.  Unfortunately, abandoning the stand-up doesn't improve their chances of building commitment or ownership, which are principles of Scrum.  So I've compiled a list of pointers on ways to improve the daily stand-up meeting and improve commitment and ownership.

The stand-up is for the team.  This meeting is for the team to synchronize their efforts towards achieving their goal, not just as a status report.  If their are any "management artifacts" that need to be created (such as an update to a tracking tool), it should be done outside the meeting.

The rules aren't fixed.  The "answer the three questions" rule you read about in books is only the starting place.  Teams add questions, change the format, and do anything necessary to address their needs.

It's about the commitment to the goal, not just the tasks.  Task tracking is critical, but work will arise on a daily basis that wasn't considered during sprint planning.  Teams need to react to this new work and balance it daily against their goal.  They need to inform each other about new developments and threats to their goal.  They should care about accomplishing the tasks, but they should care about the goal more.

The ScrumMaster must know their role.  ScrumMasters do not run the daily stand-up.  They facilitate them.  The difference is that the rules for the stand-up come from the team and the ScrumMaster ensures that those rules are followed.  If the team has decided that being late to the stand-up is not acceptable, they'll likely have a rule in place to chastise those who are late.  Paying $1 or singing a song is common.  ScrumMasters must not let them off the hook. 

It's a "stand-up" meeting.  If you took the same meeting and had everyone sit down, its duration would increase by 50%.  Standing creates a sense of urgency.   Try making another meeting "standing only" and see what happens!

Respect the time-box.  Some of the most effective stand-ups I've seen were five-minute "hurricanes of energy and activity".  The team shared what they needed to share and went back to work.  Stand-ups that take longer than 15 minutes are just wrong and need to be fixed.

Prefer a physical task board.  This is not always possible to have, but here is no electronic replacement that is equivalent.  A physical task board with cards allows everyone on the team to handle the tasks simultaneously at the same location.  It encourages team ownership.

Avoid projectors.  This might seem a bit redundant given the last point, but projectors used in a stand-up meeting should be renamed "conversation killers".  Projectors usually involve a software tool that provides information in a linear, one-at-a-time way with someone, unfortunately often the ScrumMaster, at the keyboard/mouse controls.  If defeats the non-linear, swarming-on-the-goal, value of the stand-up.  Software tools are often a critical part of project planning and tracking, but they have no place in a co-located daily stand-up.

Prefer stand-ups in the team workspace.  The ideal stand-ups are around a task board in the team's working area.  It reduces the amount of time walking to a war room and allows the team to have the task board near them all day.  This is not possible with distributed teams, but helps collocated ones.

It's owned by the team.  The team picks the format and time of day of the daily stand-up.  Since they own it, it should run the same way, regardless of whether the ScrumMaster is there or not.  One simple test I recommend to ScrumMasters is to occasionally hide around the time of the daily scrum and see what happens.  If the team meets and runs the stand-up the same way as when you are their, you are doing a good job.  If they don't meet or stand around wondering what to do, they have some things to fix.

Friday, November 12, 2010

No more play-doh

My courses and workshops, use  exercises, discussions and simulations to help attendees embrace the principles of Scrum and Kanban.  The simulations are among the most challenging to create.  Finding the best way to--for example--simulate a sprint in 15 minutes to creative game developers is not easy.  So I try variations of games other trainers use and invent some of my own.

Over the past six months, one simulation I've used is called Movements of a Hypnotic Nature (see slide 14 for more details).  Good things were said about it, so I tried it.  The simulation requires play-doh, golf balls, string, straws, etc: lots of interesting things used to build a simple product that  moves and has an aesthetic quality.

There were two problems with this simulation.  The first is that the connection between the simulation and Scrum can be a bit nebulous.  It's not a bad simulation, but I've found better ones (e.g. some based on Legos).  The second is traveling with all this stuff.  It adds a lot of weight and recently when I was packing, I noticed that the pay-doh, timers (used for time-boxing the simulation) and wires for all the gadgets I carry happened to pile-up in a  disturbing configuration:

Airline security is enough of a hassle right now without this being seen by a baggage inspector.  Sorry future workshop attendees, but play-doh based Scrum simulations are now off the menu!

Tuesday, September 21, 2010

The manifesto for agile game development

The Agile Manifesto contains four values and twelve principles for "Agile Software Development".  It's simple yet powerful and still applies nearly 10 years later.

I've modified them slightly to better fit game development.
We are uncovering better ways of developing games by doing it and helping others do it. Through this work we have come to value:
  • Individuals and interactions over process and tools
  • Working game over comprehensive design documentation
  • Publisher collaboration over milestone negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

The principles behind the Agile Manifesto:

  • Highest priority is to satisfy the customer through early & continuous delivery of valuable software, assets and gameplay.
  • Welcome changing requirements, even late in development. Agile processes harness change for the developer's competitive advantage. 
  • Deliver working gameplay frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people & developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient & effective way of conveying info within a dev team is face-to-face conversation.
  • A working game is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors and developers should be able to maintain a constant pace indefinitely.
  • Continuous attention to balanced artistic quality, technical excellence and good design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done—is essential.
  • The best architectures, budgets, assets, requirements, and designs emerge from self organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Thursday, September 09, 2010

Success with Agile Managers

The studios I visit that have the most success employing agile have something in common.  There is often a champion of the effort to become more agile who has a position of authority there.

Some of the things I have noticed about them are:
  • They understand the principles of agile and Scrum.  They understand the source of change comes from the teams, not a process.
  • They care about their people.  They want to see an end to the cycles of project madness.
  • They are willing to grow trust with the teams.
Although this role isn't defined as part of an agile process, it is often is a valued one.   Lately I came across the description of a role called the "Agile Manager" in a great book by Lyssa Adkins called "Coaching Agile Teams".   In the book, she writes that an agile manager's role is:
  • "Organizational change artist:  Guides the organization through agile adoption (and re-adoption).
  • Boundary keeper:  Reinforces healthy role boundaries both within the team and between the team and the greater organization.
  • Value maximizer: Manages the portfolio of projects like a product owner manages a portfolio of user stories, always asking what the highest business value project is now.
  • Lean manager: Uses lean thinking to improve organizational flow so that the value teams deliver can be realized without delay.
  • Organizational impediment remover: Finds the gritty courage it takes to remove entrenched impediments.
  • Team champion:  Offers observations from the team boundary and releases the team to reach their fullest potential by truly believing they can.
The agile manager is like water--patiently, water can carve away the hardest surface, and it will always find a way to flow.  Making things flow so the team delivers again and again is an honorable (and challenging) job.  In so doing, agile managers offer their highest service to the team. "

While this role isn't unconditionally necessary for success in all cases, it is for teams that don't have the authority to overcome organizational inertia that can prevent a team from becoming agile.

Agile Development in Practice at Epic Games

Someone posted the slide deck from Epic's presentation made at a GDC tutorial a few years back.  It's brief, but it was a good presentation.

Tuesday, September 07, 2010

Great product owners don't count on miracles

As a CTO or Director of a game studio, one of my principles was to hire the best people possible (the most talented and committed) and trust them to do their job. 

This always got the job done, but at a cost.  Those talented people showed their commitment by working grueling long hours and wasting weeks of effort.  I'd given them plenty of rope to hang themselves from and they used it.  I expected miracles as part of planning process.

When we started using Scrum, one of the biggest challenges was the product owner role.  Casting an existing role, like a lead designer, into it wasn't enough.  The transition of thought, from executing on a detailed plan, to iterating with a critical eye on emergent value, doesn't happen overnight. 

At first, we iterated on a fixed and detailed plan.  This led to a phenomenon, described in my book, (chapter 12, Agile Design) called "parts on the garage floor".  In doing this, we produced separate polished parts of a mechanic.  However, the value of the mechanic didn't prove itself until all those parts were integrated together in a production level and demonstrated.  By the time this happened, if the value emerging wasn't good enough, it was too late to do anything about it.

The art of great product ownership requires a different mindset:
  • Product owners have to trust the team to do miraculous things within a sprint, but not count on miracles beyond that.
  • Product owners should not fall in love with their vision.  The must take the truth from the working game and use it to "true up" their vision.
  • Product owners should demand value be added every sprint.
  • Product owners must be honest and transparent with the team.  Even when it hurts.
  • Product owners must take council from their domain experts and prioritize based on cost and risk as well as value.
The last point was crucial to my role as the CTO-who-depended-on-miracles.  Although I couldn't create these miracles, I certainly could foresee where they were needed.  I knew where the risks usually lay (when you are burned enough times, you eventually figure out that fire is hot).  The knowledge of risk was applied to the order of the backlog.  For example if porting our engine to the next generation platform is a major risk, we should do something about it earlier than later.  Then we won't need the miracle.

It's important for the product owner to understand risk and use it to prioritize the backlog. They are responsible for the direction of the project outside the sprints.  They have their hands on the steering wheel of the project and need to steer it in the right direction.

Monday, September 06, 2010

An iterative and incremental scale graph

The phrase "iterative and incremental" development is tossed around quite a bit without much distinction between the two.  The distinction is important for large-scale games (the kind shipped on discs).  In talks over the past few years I've shown a table that compares the differences, but on a recent flight I came up with a more graphical way to express the differences.

For such large games, there are usuall several phases of development that can't be blended perfectly even under an agile framework.  Theses are:
  • Concept - Ideas are considered, prototyped, and thrown out quickly.  
  • Pre-production - Ideas, winnowed through the concept phase, are built upon and refined.
  • Production - Multiple levels, characters and other assets are mass-produced based on what was discovered in pre-production.
In an ideal agile project, all of these activities are mixed equally.  For such games, this proves to be impractical.  For example, if you change the jump height of the player on a platformer in the middle of level production, you may need to redo hundreds of ledges that baked in that height.  An "agilist" would recommend that you make all your ledges procedural so that you can continue to tune them, but this is often not a practical or cost effective solution.  We have to make decisions before production starts.

So here is the graph I jotted down (I love Omnisketch on the iPad):

What this communicates is the flow of development (the green line) from concept, through pre-production into production.  This flow can be for the entire game or a class of assets (such as levels).  The goals for the team and stakeholders moves from "correctness" (making the right game or asset) to that of "efficiency" (making it as low cost as possible).   Each goal guides how we do the work, either using spikes in concept development, Scrum in pre-production, or mixing in lean practices such as kanban in production.

The blue box in the lower left represents "total certainly" in our requirements and technology, which is fine if your mass-producing widgets, but is never a state we're in making games.

I find this useful in explaining that the work chooses the methods, not the other way around.

Monday, July 19, 2010

Book link - Agile Retrospectives

Here's a book that must be on every ScrumMaster's book shelf:

Retrospectives are among the most commonly overlooked, yet most important agile practices.  Without the "inspect and adapt" cycle of teams examining how they work together, there is little chance that they'll enter the state of continuous improvement.

Agile Retrospectives shows you how to best facilitate this essential practice and to keep it fresh by choosing from many different types of retrospectives.   It offers great advice on eliciting feedback from everyone and digging deep into underlying issues.

Retrospectives will be the topic of my IGDA Leadership Forum 2010 session.  We'll be talking about the best flow for retrospectives and running a few of them to discuss how well the Leadership Forum functioned.

Sunday, June 27, 2010

Video: Kanban for Video Game Development

The video of my presentation at the Lean Systems Software Conference in Atlanta in April:

This session describes how Lean Production and Kanban has been applied to game development. Lean principles and Kanban tools have been used by a number of developers, including the presenter, to slash production costs by over 50%. As a complement, or replacement, to Scrum, Lean/Kanban provides predictability, transparency and optimization for complex game production. 

Saturday, June 12, 2010

What makes a creative company? Ed Catmull interview

Many great pearls of wisdom here.  One of the main things that stood out was the regular postmortems that occur.  What he describes is very close to agile retrospectives.

- "Fundamentally, successful companies are unstable."

Tuesday, June 01, 2010

"Agile Game Development with Scrum" book is shipping!

I'm very happy to announce that the book is shipping from Amazon!

Thanks to my manuscript reviewers: Bendik Bygstad, CJ Connoy, Jeff Lindsey, Erik Theiz, and all of 38 Studios, Jason Della Rocca, and Senta Jakobsen. Their level of detailed feedback was tremendous and added a great deal of value to the book.

This book took almost two years to write. During this time, I received much feedback and advice from those who downloaded draft chapters and helped steer the direction the book took: Bas Vodde, Chris Oltyan, Diogo Neves, George Somaru, Heather Maxwell Chandler, Jamie Briant, Julian  Gollop, Karen Clark, Lia Siojo, Lyssa Clark Adkins, Martin Keywood, Paul Evans, Philip  Borgnes, Robert Bacon, Ron Artigues, Rose Hunt, Scott Blinn, Sheldon Brown, Steve Sargent, Wanda Meloni, LaRae Brim, Keith Boesky, AĆ°alsteinn “Alli”  Ɠttarsson, and Barbara Chamberlin. Extra thanks to Justin Woodward for all his artistic help and advice!

To Bruce Rennie, Michael Riccio, Rory McGuire, Stephane Etienne,  Caroline Esmurdoc, Shelly Warmuth, Chris Ulm, and Alistair Doulin. I thank them for letting me use their words.

Friday, May 28, 2010

Robbie Bach and J Allard Leaving Microsoft

Two of the best people I met at Microsoft are departing

I have a few outstanding memories of these guys.  Around 2000, when the Xbox was in development, I was visiting Microsoft to talk about Midtown Madness 2.  This intense but friendly bald guy pulled me aside, shoved a huge controller in my hand and asked me what I thought about it as a console interface.  He was very open and inquisitive and I ended up talking to him for about an hour.  I later learned he was the lead designer for the Xbox.  I like designers who are inclusive and want to test their ideas.  I like them a lot.

Robbie was a class act.  Around the same time we (Angel Studios) were struggling to get a contract signed for Midtown Madness 2.  We had lost money developing MM1, but it turned out to be a big hit, so we were asking for more reasonable terms on the second.  Microsoft management was having none of it and we were months into the project, burning through a lot of money without a signed contract.  The game was about to be terminated.

Robbie called our CEO at home on Saturday morning, got right to the point with him and the two of them came to an agreement in a few minutes.  Doing this was several layers below Robbie's pay grade, but that's what good leaders need to do sometimes. 

I wish them both the best of luck and hope they enjoy their well deserved time off.

Wednesday, May 26, 2010

AGD Book: Sample Chapter Posted

A sample chapter of my book Agile Game Development with Scrum has been posted on InformIT.  This chapter describes the impacts on the designer role when on an agile project.

You can read it here.

Friday, May 14, 2010

Book update

My book should be released within the next few weeks (by the end of May).  The Amazon page is here.

Wednesday, April 21, 2010

Agile Game Interview - Agile Engineering for Online Communities

James Birchler is an Engineering Director at IMVU, where he implemented and manages IMVU’s product development process using Agile and Lean Startup methodologies. Prior to joining IMVU in 2006, he redesigned the product development process at Bargain Network, Inc., helping complete the company’s acquisition by Vertrue, Inc. Previously, James was a Director at, responsible for technical design, creative design, and content of the web applications and GUI for There’s virtual world application. James will be presenting on Lean Startup methodologies at the Startup Lessons Learned Conference on April 23 in San Francisco, and is a frequent contributor to the IMVU Engineering Blog.

Clinton Keith: What is IMVU?

James Birchler: IMVU, Inc. ( is an online community where members use 3D avatars to meet new people, chat, create and play with their friends. IMVU has reached 40 million registered users, 10 million unique visitors per month and a $30+ million annualized revenue run rate. IMVU has the world's largest virtual goods catalog of more than 3 million items, almost all of which are created by its own members.  IMVU achieved profitability in 2009 and is hiring aggressively with plans to double the size of its team in 2010.

CK: What is the overview of the IMVU engineering process?

JB: Our engineering team practices what people refer to as "Agile" or "Lean Startup" methodologies, including Test-Driven Development (TDD), pair programming, collective code ownership, and continuous integration. We refactor code relentlessly, and try to ship code in small batches. And we've taken continuous integration a step further: every time we check in server side code, we push the changes to our production servers immediately after the code passes our automated tests. In practice, this means we push code live to our production web servers 35-50 times per day. Taken together with our A/B split-testing framework, which we use to collect data to inform our product development decisions, we have the ability to quickly see and test the effects of new features live in production. We also practice "5 Whys" root cause analysis when something goes wrong, to avoid making the same mistakes twice.

CK: How do you get so many changes out in front of customers without causing problems, either for your customers or your production web servers?

JB: I think it’s important to point out that sometimes we actually do introduce regressions and new bugs that impact our customers.  However, we try to strike a balance between minimizing negative customer impacts and maximizing our ability to innovate and test new features with real customers as early as possible. We have several mechanisms we use to help us do that, and to control how customers experience our changes. It boils down to automation on one hand, and our QA engineers on the other.

First the automation: we take TDD very seriously, and it’s an important part of our engineering culture. We try to write tests for all of our code, and when we fix bugs, we write tests to ensure they don’t regress. Next, we built our code deployment process to include what we call our "cluster immune system," which monitors and alerts on statistically significant changes in dozens of key error rates and business metrics. If a problem is detected, the code is automatically rolled back and our engineering and operations teams are notified. Next, we have the ability to limit rollout of a feature to one or more groups of customers--so we can expose new features to only QA or Admin users, or ad-hoc customer sets. We also built an incremental rollout function that allows us to slowly increase exposure to customers while we monitor both technical and business metrics to ensure there are no big problems with how the features work in production. Finally, we build in a "kill switch" to most of our applications, so that if any problems occur later, for example, scaling issues, we have fine-grained control to turn off problematic features while we fix them.

CK: You mentioned QA engineering, too: how do you approach Quality Assurance at IMVU?

JB: Most features go through some level of manual testing. Minimally, the engineer that pushes code verifies the functionality in production. In many cases, features get dedicated testing time from a QA engineer. By the time a feature is ready for QA testing, our QA engineers can focus on using the feature much like a customer would. They expose bugs by doing complex, multi-dimensional manual testing based on more complicated use cases. People are really good at this work, which is more difficult to cover with automated testing.

In terms of our overall approach to QA, for the last 18 months we have tried to find ways to leverage the strengths of our small QA team--we have only two QA engineers currently. Our ratio of QA to engineering has ranged from about 1:9 to 1:14 in that time span. Initially this was because we didn’t have any QA engineers in our hiring plan. However, we decided to delay hiring until we got a clear signal from our product owners that they needed more QA bandwidth.  While this has been challenging in many ways, having limited QA resources forced us to innovate on process, and to triage and focus on features that are most important to our customers.

In practice, this means that our teams are always reviewing QA priorities to see which features get attention. In some cases there is so much important QA work that needs to be done that we organize group tests, either with the team or the entire company, to quickly find and fix issues. Our software engineers are also becoming skilled in carrying out manual testing, and following our QA test plans. When this happens, it is more akin to classic Scrum, where all tasks (including QA tasks) are shared among the team.

From a process standpoint, we integrate QA engineers into our product design process as early as possible. They provide a unique and valuable point of view for developing customer use cases and exposing potential issues before engineering begins work. The collaboration between our product owners and QA engineers adds tremendous value. I’ve written more about IMVU’s Approach to QA on our IMVU Engineering Blog.

CK: What about the rest of your product development process--are you using a Scrum framework?

JB: We are now, but we didn't from the outset. We had mixed success using several different development styles, and we didn't standardize on a single set of methods for all our teams to follow until about 18 months ago. Before we standardized, we had many problems. One was that we didn’t have a good infrastructure for ensuring clear visibility about what teams were doing and why. Another was that there was a ramp-up time when moving people among teams, since had to figure out how the new team operated. I think our process reflected what was a fairly decentralized product management organization--product level decision making authority was distributed among many product owners, each responsible principally for their own area of the product. The dynamic made it challenging to get agreement on how to allocate team resources. One result of this was that we shipped a lot of small features, but were unable to ship large features or major product improvements in response to customer needs. In Lean Startup parlance, we failed to execute a Pivot. For example, revamping the UI for our instant messenger product interface was impossible for a long time because it required implementing a new infrastructure for building and updating our UI—a major undertaking.

We've transitioned over the last 18 months to using a consistent set of Scrum practices for all our product development teams, accompanied by our key hire of a VP of Product. We don't follow Scrum dogmatically, though we adhere to some important tenets. Fundamentally, we use Scrum to facilitate communication. Maximizing face-to-face communication among team members while issues are minor adds a lot of efficiency.  Like all our processes, our Scrum is subject to iteration and incremental improvements.

CK: What are some of the modifications you've made to your Scrum process?

JB: For starters, we encourage two important meetings that we’ve found are particularly valuable. The first is a meeting involving the product owner, engineering technical lead and QA engineer, which occurs prior to sprint planning. These stakeholders review their respective design documents (project brief, technical design and QA test plan) to resolve inconsistencies and potential issues, and update those plans. By the time we have the sprint planning meeting, we have a high level of confidence that we have a solid technical plan for building the feature, that the team knows how the feature will be tested by QA, and that our customer use cases will be fulfilled.

The second meeting occurs during the sprint when a feature is nearly complete. The engineer that built the feature meets with the product owner and QA engineer to demonstrate the feature and ensure it is functioning as expected and that it has all possible automated test coverage in place. Demonstrating a feature to other team members almost always exposes issues that result in minor changes and optimizations.

We're currently at a stage of growth where we are planning to add a user experience design lead to both of these meetings--again, we're iterating on our own process based on experience and seeking to optimize and improve.

CK: How difficult was your transition to using Scrum exclusively in your product development process?

JB: The transition was fairly smooth, but not without problems. For example, it took a few sprints to get used to the daily Scrum meeting routine. We had to practice and iterate on how to give a daily update that made sense to the team. We even had to institute a $1/minute late fee to help ensure everyone showed up for the meeting. We had some great parties with all the money we collected.

I think our success with Scrum has hinged on two factors: first, we have unwavering executive-level support for using Scrum and constantly iterating to improve our processes. Second, our engineering team was already completely bought in to TDD, pairing, and continuous integration and deployment.  This made it relatively easy to add a consistent Scrum framework across all our teams, and proceed to iterate on the process sprint by sprint.

CK: How has your Scrum process evolved?

JB: Initially, we were quite strict about following classic Scrum ground rules and processes. For example, we tried to ensure that any team member was able to take any task from the board. I think this would be a good practice if you can make it work, but we discovered pretty quickly that sometimes it's most valuable to recognize specialties among the team. For example, we often have one person assigned to a task or even an entire feature at the start of the sprint. We also tried to keep new tasks from being added to the sprint.

This turned out to be really hard, and it caused a lot of stress. When a product owner wanted to add work, the team would push back hard, afraid that they wouldn’t be able to meet their commitment for the sprint. If the team tried to add tasks (typically addressing technical debt or fixing issues found in the code), the Product Owner would push back hard, too. Eventually we realized that no matter how hard we tried, we couldn’t anticipate everything that would happen during a sprint, and that we needed a way to accommodate issues that needed to be addressed immediately. What we did was we added a “New” column on our task board, where anyone could add a task. We review all the new tasks during scrum, and agree as a team on which tasks will be added to the sprint backlog, and which are moved to the product backlog. When we add a task, the team agrees to either remove a task of similar size, or to agree to change the team commitment for the sprint.

Currently, we evaluate our Scrum practice each sprint in a retrospective, and we optimize our process each sprint.  One interesting thing we noticed was that sharing best practices among teams didn’t necessarily work. While a certain best practice might make perfect sense to one team that was reacting to their own recent experience, other teams often need to experience the same problem themselves before they successfully adopt the practice.  

Our careful practice of doing sprint retrospectives is key to ability to evolve process overall.  We take time to review the events of each sprint, being careful to recognize patterns and make changes to improve.

CK: What are some of the other unique aspects of IMVU’s Scrum processes?

JB: For example, our planning meetings involve a detailed walk-through of the technical design for each feature in development, so that everyone on the team participates in task estimation and understands the path each project is likely to take over the course of the sprint. In practice, this doesn't take as long as it might seem, since a fair amount of pre-planning has already taken place.

We also added a permanent lane to our Scrum board called, "Engineering Project Follow-up", where we constantly track and make time to improve engineering infrastructure. It's a lane where an engineer can actually add tasks to the backlog and have them prioritized and implemented. We did this in part because as we have scaled our product development process, we noticed that our velocity was being negatively impacted by past technical debt. Making time to make infrastructure improvements is also a key to ensuring a consistent velocity. Our product owners recognize and appreciate the value in doing this.

Another example is that we learned to be comfortable with our velocity without relying on a burn down chart. When we started off with Scrum, we spent a lot of time trying to create an accurate daily burn down chart—and it was useful initially as we figured out what our velocity was. After many sprints under our belts, our teams have developed a good sense of their velocity, and we routinely complete planned work each sprint.  Currently, we only create a burn down when we've had a problem delivering a product feature or when we have the feeling that something isn't quite right. That said, if we could find a simple, automated tool for tracking tasks and creating accurate burn down charts, we would find it useful.

CK: What is the relationship between Product Management and Software Engineering on your teams?

JB: This is an important and large topic, and I'll share just a few thoughts here. Overall, Engineering is a service organization supporting our Product Management team. Put simply, Product decides what to build, and Engineering decides what technologies we are going use to build it.

In Scrum, product management is represented by product owners on each team, which consists of between 6-12 software engineers. We have developed a strong sense of trust and respect between these disciplines over time. This trust and respect is important. For example, refactoring code is a strong part of our engineering culture at IMVU. Initially, product owners would question the introduction of work into a sprint by the engineers, asking, "Do we really need to fix this technical debt? Isn't there a faster way to implement this feature?"

It didn't take long for several concrete examples to appear highlighting the value of engineering things correctly from the outset, and of paying back technical debt that causes ongoing drag on engineering efficiency. At present, product owners trust engineers who say, "I'm delayed on my task because I needed to make time to refactor code.” Engineers also trust product owners to help ensure that the team has time to build and maintain solid engineering infrastructure and repay technical debt.

We've had plenty of conflict, though. To help manage that, we put a simple process in place: if the team technical lead and product owner couldn't agree on a how to handle an issue, then the matter was simply resolved by escalating the issue to the management team. Overall, our product owners consistently report that our development teams are the most productive that they’ve ever worked with.

CK: What’s next for IMVU’s product development process?
JB: We continue to scale up our processes as we continue hiring. We’re starting to find ways to integrate design functions into our processes now. Our overall strategy remains the same: continue paying close attention to how we are doing, and keep on iterating.

CK: James, thanks for sharing.  Congratulations on IMVU’s success!

Friday, April 09, 2010

Announcement: Certified Scrum Product Owner Course in San Diego May 26-27

Building a product with a new process can be a daunting prospect. Being asked to serve as the team’s Product Owner can be downright intimidating.

I'm teaching a Certified Scrum Product Owner course in San Diego next month.  This 2-day course teaches you the requires knowledge to become an effective product owner and guide the emergence of the product your customers need in the most direct way possible.  It employs hands-on exercises as well as interactive instruction to give you the best possible foundation for succeeding in the Product Owner role.

The course is limited in size, and there is an early bird price of $1100 until the end of the month and groups of 3 or more get an additional 10% discount. 

Details can be found here and registration is here.  The course is being held at the Four Points by Sheraton on Aero drive.

Hope to see you there!

Free Realms and Scrum

From a postmortem on Gamasutra:
There are many different opinions about the best way to organize a team. Even with a significant organizational change in the middle of development, the Free Realms team found Scrum a great tool:

"Traditional wisdom states that you should never change horses mid-stream. But what if your horse can’t swim?

"The Free Realms team used a traditional waterfall approach for over half the game’s development. It was working about as well as it usually works in a complex scope, large team environment. With only about a year left in development we decided to move to agile development and start using scrum with a team of 80 people. We sent all the leads and key personnel to scrum training, asked those team members to train everyone else, and then made the leap.

"From the start, there was a marked improvement in team morale and communication. Although there were (and still are) a few holdouts who gripe about the daily meetings, everyone recognized that the game was making more progress in less time than it had before we started agile development.

"Over time, we modified some of the more traditional scrum elements as we added team members and features, but we maintained the heart of scrum: daily meetings, user stories going into a backlog maintained and championed by a product owner, and increased scrum group responsibility and ownership.

"Sense of ownership is key to understanding the impact scrum can have on a large team. When you have so many different people working in parallel, it’s easy for each individual to lose his sense of purpose—he starts to feel like a cog in a machine. You could definitely see that 'just doing my job' feeling in parts of the Free Realms team before we used scrum. Many people on the team didn’t understand the big picture, had no idea what other parts of the team were developing, or had lost some of the entrepreneurial spirit that started Free Realms off so strongly.

"Scrum brought with it daily meetings and bi-weekly sprint reviews where we saw what everyone else had developed. Those meetings were inspirational when we saw fantastic work from other teams, and embarrassing when one group’s work wasn’t quite up to par. The team morale woke up and the quality of the game improved along with productivity."

Friday, April 02, 2010

Quick and Dirty Prototyping: A Success Story

Great feature article on Gamasutra about rapidly iterating on a prototype.

While our studio, Boomzap Entertainment, is agile in the simplest definition of the word ("can move fast, is flexible"), we don't follow Scrum, XP, or any of the popular frameworks. Instead, we've tweaked a process that works best for our indie studio for the past five years -- a process I like to call "quick and dirty prototyping", though no one else at Boomzap refers to it as such. 

Too many teams get lost in the labels and terminology and miss finding what makes sense. Good processes, no matter what the source, should lead to similar common sense practices. For example, I loved seeing the cost-of-change curve figure. That's the same curve that XP-ers use to justify the value Test Driven Development.

Wednesday, March 17, 2010

GDC "Beyond Scrum" slides

My slides for the "Beyond Scrum" GDC session are here.

There is a nice set of notes for the session posted here.

GDC was great this year.  Props to Meggan Scavio and the rest of the Think Services folks for doing a top-notch job!

Saturday, March 06, 2010

At GDC 2010 next week

I'm happy to meet up!  Send my an email: clint [at]

In addition to the CSM4VG course I'm teaching, I have the following sessions:

Beyond Scrum: Agile Project Management for Games
Date/Time: Thursday (March 11, 2010)   9:00am — 10:00am
Location (room): Room 305, South Hall
Session Description
The session is not an introduction to Scrum. It describes how Scrum fits in to an entire game project management framework.

Agile: No Silver Bullet
Speaker: Chris Oltyan (Director of Product Development, ZeeGee Games), Rich Vogel (Co-Studio Director, BioWare), Clinton Keith (Clinton Keith Consulting), Michael Capps (President, Epic Games)
Date/Time: Friday (March 12, 2010)   9:00am — 10:00am
Location (room): Room 303, South Hall

Session Description
The goal of this panel is to discuss the good and the bad of agile development. Let's not sugar coat it, agile development is hard and does not fit all production paradigms. We'll discuss where the dogmatic approach to agile fails and where to apply practices from other areas, such as waterfall and lean. The panel will also answer audience questions directly and help diagnose how and why Agile projects went wrong, and methods teams and companies can use to get their processes back on track.

It should be a great GDC!

Thursday, March 04, 2010

Survey Results - The State of Agile in the Game Industry

Gamasutra just posted the article based on the survey conducted last month.  Thanks to everyone who participated!

Monday, February 22, 2010

Scrum: You're Just Going to Fail, So Don't Bother

Some tough words to soak in.

Making an MMORPG on a shoe-string

Just read an article about Forever Interactive, which calls itself "a completely virtual agile game development studio" and how they are developing their MMORPG:

The nearly 50 programmers and artists working for Forever Interactive are not pulling paychecks but instead banking on eventual compensation that will be a percentage of the revenue - a percentage based on their performance - when money comes in, Harmsen says.

It's a "sweat equity" model, and performance includes things such as communication, meeting deadlines, reaching milestones, with accomplishments compounding until the game launches.

I'll be keeping an eye on them over the next year.

Saturday, February 20, 2010

Micromanage at Your Peril


Have you ever worked with a micro-manager? This is someone who thinks he or she needs to be involved in everything that happens within the company. These leaders are closing out the talents of others by not divesting themselves from the day-to-day problem-solving activities of the company. Great leaders let go of the day-to-day, problem-solving activities of the company. Rather, they choose to maximize strategic and relationship-building efforts. These contribute to the forward momentum of the company rather than causing a "bottleneck" at the leader's desk. No one person should do it all — and if they are self-aware, most people will realize that they really aren't capable nor knowledgeable enough to do it all.

thanks to Kim Sellentin for the link.

Friday, February 19, 2010

Agile Game Development Checklists

The Agile Game Development Checklists are meant to help drive discussion about the implementation and effectiveness of agile practices (including Scrum, XP, TDD and Kanban) for a team and stakeholders.

This first version contains a checklist for the ScrumMaster role. Revisit how this role adds value to a Scrum Team and how that role can be improved.

Wednesday, February 17, 2010

Agile Game Development Book Online

My book is now available at Safari Books Online.
The printed version will be out at the end of May.

This is the "rough cut" version that is available while the book is in final production.

Monday, February 15, 2010

Ed Catmull, Pixar: Keep Your Crises Small

Ironing out the little problems can make it so companies can avoid big disasters.

Notable quotes and points:
- "The trick is to stop that behavior (of not showing something until it is absolutely right)"
- "We confused the organizational structure with the communication structure"
- "Managers: you don't need to be the first person to learn something.  Don't get upset.  Get over it."
- "Because the were working on things they loved, they put up with stuff they didn't like."
- "Success hides problems."
- "This isn't good for our souls to do that (mix quality projects)."
- "If you have a good idea and give it to a mediocre group, they'll screw it up.  If you give a mediocre idea to a good group, they'll fix it, or they'll throw it away and come up with something else."
- "The goal of development [department leadership] is not to find good ideas, it's to put together teams of people that function well together.  And that change altered the way we thought about making movies."
- Nice retrospective (five questions) and empirical process!
- "Human organizations are inherently unstable.  They will fall over and you have to work to keep them upright.  But they fall slowly.  Most people don't notice it.  They let their success blind them.    You have to do constant assessments.   You have to look for the hard truths."

Wednesday, February 10, 2010

100+ Resources for Video Game Professionals

This list contains resources for people in - or interested in - the video game industry.  Here you'll find general and specific news resources, career resources, and more

Tuesday, February 09, 2010

It's always been about common sense

A response to another Scrum-bashing article:

"I believe no single model or framework is enough when managing complex systems. Anyone who favors one method and pisses on another is just showing off his ignorance of complexity thinking. "

Scrum isn't the goal.  Agility isn't the point.  It's about finding ways for groups of people to make better products while reducing wasted effort.  It's about creating never-ending cycle of improvement.

Brand loyalty or bashing shuts out wider possibilities.  Labels allow higher cognition to be disabled.  The goal is to always explore practices, use common sense, knowledge and observation to decide what works better and what doesn't. 

Friday, February 05, 2010

Product Owners and Innovation Games(r)

A product backlog needs to be well thought out.  Are we prioritizing the right features?  Are the features really what our customers want?  Are we missing anything?

The least effective product backlogs come from limited viewpoints or from seemingly endless boring meetings dominated by a few voices.  They result in one-dimensional backlogs whose vision isn't understood or shared by the team.  This impacts the potential of what a game can be.

How can backlog creation be made more collaborative, innovative and effective?  The best way I've found is to introduce gaming to backlog creation. 

In search of solutions, I recently attended an Innovation Games (r) Master Class for Scrum trainers in San Jose run by Luke Hohman.  Innovation Games (r) have been used in a wide range of product design and is the subject of a great book.  For two days, we practiced selecting, running and facilitating each of the game types.  Some of the games I'd used in past training (like "Product Box").  Most were new.  It really opened my eyes to the science and psychology behind such games and the power they hold.

In March, I'm planning to attend the first Certified Product Owner training class designed with Innovation Games(r) with Luke and Mitch Lacey, an excellent Certified Scrum Trainer, in Seattle.  I'm very much looking forward to attending this class.  I highly recommend it for any product owner, especially those working on video games.

I can't imagine a better application of gaming for product planning than for video games!

Wednesday, February 03, 2010

If you can see this post, everything is working

You've either changed the feed location or the redirect has worked.

This could have been easier!

Tuesday, February 02, 2010

The blog has been moved.

The new address of this blog is now:

Apologies for any inconvenience.  Blogger is dropping their FTP service, which is what I used in the past.

Blog move complete

The new blog address seems to be working!

Agile Game Development Blog Moving....

Blogger is soon going to drop the publishing service I've been using, so I need to change it.  As a result, this blog's feed will become

Blogger is promising me that this change will be transparent to you and that the old address will redirect your readers to the new address.  

See you there!

Friday, January 29, 2010

Congratulations Bioware!

I just received my copy of Mass Effect 2, developed by Bioware in Edmonton, Canada, a client of Clinton Keith Consulting.

I met the developers of Dragon Age late in the game's development and was bombarded with a wide range of insightful questions about Scrum and agile in general.

The ME2 team I met was talented, well led and experienced in using agile practices (having adopted agile during ME1).  They explored lean practices for ME2 production and spoke about them at GDC.

Bioware has always been at the forefront of exploring ways to improve their development processes.  Talent, vision, focus and leadership are in abundance there.   They understand that Scrum is merely a tool for leveraging those attributes and that continual improvement is a necessity.

Congratulations to both teams and Bioware!

Thursday, January 28, 2010

Agile Video Tip - Applying Kanban to Support Teams

New 5-minute video up on my website (at the bottom).  Applying Kanban practices to support teams that use Scrum.

Saturday, January 23, 2010

Agile Game Development Video Podcast

I think graphically, which is why my book has lots of figures. Now that the manuscript for the book is about to enter production, I've decided to start producing short (~5 minute) video podcasts (vodcasts?) that contain tips about using agile.

You can find my first one, about using Scrum to pull work rather than to push it through a sprint at the bottom of my home site.   Let me know what you think and how it can be improved!

Tuesday, January 19, 2010

Agile Game Development Survey

Gamasutra has asked me to write an article about the "state of agile in the game industry", but it's best if that knowledge comes from you.

Take a short survey! 

The results will be compiled and included in the article.

Thursday, January 14, 2010

Announcement: Lean Software and Systems Conference, April 21-23

I'll be attending the Lean Software and Systems Conference in Atlanta this April (21-23), presenting this session:

Kanban for Video Game Production

The session will describe how Lean Production and Kanban has been applied to game development. Lean principles and Kanban tools have been used by a number of developers, including the presenter, to slash production costs by over 50%. As a complement, or replacement, to Scrum, Lean/Kanban provides predictability, transparency and optimization for complex game production.

Although there is a strong software bias to the conference, anyone who is implementing or planning to implement Lean/Kanban practices in their company for any product type will benefit from attending.

Monday, January 11, 2010

Agile Game Interview - "Simplicity Is Hard"

The following is an interview with Chris Ulm, CEO of Appy Entertainment about iPhone game development and using agile.

Clinton Keith: Chris, tell us about iPhone game development:

Chris Ulm: iPhone game development is faster, more competitive and far more unforgiving than any other platform I have developed for. On the plus side, original ideas can become innovative games very quickly. On the minus side, the three month development cycles and low retail prices mean that budgets are tight and we must be ultra efficient. We've found that using agile methods have allowed us to prioritize the scope of our small projects and work effectively with contractors all over the world.

Our iPhone projects are quite complicated with third party advertising APIs, Bluetooth multiplayer, social network and email wireless connectivity. We allow users to use their photo albums and their iPod music as essential aspects of gameplay. We have integrated the OpenFeint social network in all of our games, allowing users to browse leader boards and compare scores with anyone playing the game, anywhere in the world. All of this complexity needs to be built quickly and for a price that starts at free. Without agile, it would be very easy to lose sight of your end goals.

CK: What's different about being agile for iPhone games

CU: Unlike most agile projects, on the iPhone you can LITERALLY work for two weeks and "ship" what you have as a finished product. So knowing when to ship is the most important thing.

A unique challenge for the iPhone is knowing how much to give. People expect a LOT for $0.99. The number one complaint about Zombie Pizza was that the game was only three hours long -- three hours for .$099!

CK: What do agile iPhone projects look like?

CU: Strong vision led by white-boarded interface description and a minimal document to kick off the concept. Big huge whiteboards are everywhere. Everyone contributes, but leadership and vision are important -- we don't have the time or budget to create the vision as we go, so all of Appy's games have a single creative lead with a very specific vision for the game. The vision is always based around a single point of differentiation that fits with the Appy brand values of Personalization, Quality and Fun.

Prototypes: Each game is a series of prototypes until we have one we can ship. We try to get a mechanical prototype as humanly early as possible. Small amounts of pre-visualization - but only enough to serve as a guide for actual code.

Our projects vary depending on complexity; taking anywhere from two to five months or more and our team size averages between four and six people on a given project.

Sprints are either one week or two depending on the project and what "feels" right for the work. We generally have two releases: complete prototype and alpha game.

Sprints, Stories and task cards are used for the "development" phase of the project (2/3 length of the project). How the vision is implemented is left very loose and we are opportunistic about how we modify on the fly based around working gameplay and market conditions.

Time-boxing is critical and we have two values on every decision: Dollar cost and player benefit. It helps if it’s your own damn money at stake!

Lots of testing and watching people play. We are very informal at this stage in the company’s growth, so we’ll bring people in and have them play while we watch, then fill out specific questionnaires. We divide initial comments into three groups:
  • Must fix before release: these are usability and navigation issues primarily, though we have also added a last minute feature if it becomes painfully obvious that it would add a lot of player value to the app.
  • Add to our active update list: these are features or ideas that we like, but are not considered worthwhile enough to add to the 1.0 version by the game director. These are always the toughest ones, because our impulse is to always keep making the app better. But, you have to have the discipline to ship.
  • Add to the update backlog: these are features that we think have value, but we’re going to wait and see what the actual paying audience thinks before assigning them to a an update release.
The alpha/beta phase of the project is dominated by bug lists and daily prioritization. At this point, the product becomes highly "produced" and we have to choose the optimum amount of testing.

CK: What is challenging?

CU: Requiring everybody being in the building at the same time -- we have to outsource with contractors.

The iPhone user experience has to be simple. We have to fight complexity all the time. We have to remain focused and avoid “hobby horses” from design, code or art.

Focusing on scope and smart technical, gameplay and marketing trade-offs. This is the most critical aspect of our product development and requires the focus of the whole company. We need to be efficient, yet our business plan calls for us to create original games that are differentiated from the thousands of game apps in the marketplace, so there is always a tension between doing what we know how to do and biting off an experimental feature.

Our Executive Producer, Steve Sargent, assigns an exclamation mark to any feature, no matter how small, that we have not done before. These typically take us 2-3 times longer than the initial estimate as refinement and quality always take more time than initial proof of concept. By looking at the board filled with task cards with exclamation marks, we can get a real sense of the shipping risks of our projects.

CK: Tell us about your agile practices…for example, what is Appy’s “definition of done for sprints and releases”?

CU: "Done" varies, but for the most part, every sprint's work runs on the target platform. Releases are always pushed to everyone's iPhone for testing and evaluation over the weekend. We are informal at this stage. Done means "potentially shippable" and we don't move on to new functionality until the previous functionality is shippable. We strive to avoid at all costs the "parts on the garage floor", and would elect to ship "better with less".

CK: What are the things that surprise you in alpha/beta?

CU: Usually some of the final integration aspects (full audio, stress testing) will turn up some late issues. We are also surprised sometimes by miscommunications between contractors -- not a big or endemic problem, but it happens. We try real hard to identify mistakes as we go and not do them again.

CK: What "feels" the most different between iPhone and console development?  What is different about maintaining and communicating a vision?

CU: The platform and audience on the iPhone desire simplicity whereas on the console; technical and gamplay complexity are demanded by a more hard-core player (especially on the PS3 and Xbox). Right now, what constitutes a "genre" is still very much in flux on the iPhone and there are over a hundred thousand apps.

Development teams are much, much smaller and in Appy's case are integrated fully with the financial and marketing needs of the larger company. The vision of the game is communicated through a brutal process where we winnow down many ideas into one that the company is fully behind. That one idea is championed and led by a single person who has authority to be the final arbiter of trade-offs.

The visions are much smaller and more personal to the end user, usually built around a single mechanic.

From my point of view, having led both large console teams and iPhone teams, I spend almost NO time on "career coaching" or re-focusing individuals on the work at hand (which seemed to chew up a majority of my time with the larger teams), but instead spend the majority of my time solving problems, preparing the next game, working on marketing or working on Appy's strategic goals. I love working with my co-founders who are an incredibly creative and talented bunch and we are not big enough at this stage to have a lot of communication problems that can’t be solved by yelling at the guy sitting next to you or across the room.

About Chris Ulm:
Chris Ulm, CEO of Appy Entertainment: A “serial entrepreneur” addicted to building companies from scratch and guiding them to acquisition, Chris leads day-to-day operations, production, and creative development for Appy. An expert in building teams, Chris was essential in developing the creative teams and product development at High Moon Studios and was essential in High Moon Studios’ acquisition by Vivendi and later Activision-Blizzard, as well as the sale of Malibu Comics to industry-leader Marvel Comics.

About Appy Entertainment:
Appy’s first game, FaceFighter, was chosen by Apple as a “What’s Hot” pick and reached the status of “Top Ten Paid Game” in 5 of the 6 major markets worldwide. Their second game, Zombie Pizza was a “Top Ten Puzzle” game in the U.S. and was featured by Apple as a “Hot New Game,” a “New and Noteworthy” app and as a “Best Halloween Game.”  In addition, Zombie Pizza was featured in Entertainment Weekly magazine’s “Must List” and on the Huffington Post as a “Best Game for Halloween.” Tune Runner, their newest app, is a music-based action game that provides an interactive platform for players to use their iPods to discover and recommend songs to their friends

Appy's games have both earned "4.5 mice" from Macworld and Appy's apps have been downloaded well over one million times.


Great explanation of Scrumbut by Ken Schwaber.

Thanks to Attila Buturla for sending the link!