Wednesday, May 12, 2010

Scrum Software Development and the Gamers Who Use It

I’ve heard of the Scrum development method but never learned how it works or what makes it different. Last night I joined the Georgia Game Developer’s Association (GGDA) for a review of how CCP Games is using Scrum for their various products. As a commercial real estate agent who works with software companies, I was curious to know more about their worlds and how their methodologies affect space requirements.

Before I talk about how it works, there are a few things worth knowing:
  • Scrum is a process, not a product. The term is borrowed from a rugby analogy, where a team works as a unit to move a ball down the field by fluidly passing it back and forth. Some choose to capitalize all the letters (SCRUM), although the term is not an acronym.
  • Scrum is not just applied to software development. It is reportedly a process for any new product development, but you’ll want to note the next bullet point as a qualifier.
  • Scrum is ideally suited to projects in which variables change constantly and/or the desired end product evolves through the process. It is fast-paced, very flexible (it can turn on a dime), and appears to offer many small victories that keep morale high along the way.
As I learned from CCP’s great overview, the basic philosophy is that a massive project is broken into a many small projects and the small projects are assigned to teams. All teams work in concurrent two-week blocks, with deliverables at the end of each block. When the time block ends, all of the teams convene to deliver their results and to address inter-dependencies and/or changes to the overall project. When the meeting is over, the teams go back to work… on their NEXT two-week deliverables.

There three are roles that are played on a team. The ScrumMaster is what I like to call a “blocker.” His or her job is to identify and eliminate any obstacles to the team’s ability to deliver, whether the obstacle is internal or external to the team. The Team Members are the ones who create the deliverable. The Product Owner plays the role of the customer to whom the deliverable is owed. The Product Owner may be a part of the team but doesn’t have to be.

CCP implemented Scrum globally around 2005. When I asked if the implementation was tough, the reply was that in the USA is was easy because CCP’s team was small and was beginning a new project (World of Darkness, not yet released). In China and Iceland, the implementation was not a simple task because those teams were working on mature products (ex: Eve online) with larger teams and established business practices to rewrite. In short, it’s much easier to start with Scrum than to switch to Scrum.

For anyone considering Scrum, the rewards appear to warrant the process.  Team members remain motivated because there are many victories along the way.  Teams are largely self-directed, so there is a sense of being in control of one's destiny.  Product development can be adapted "on the fly," so the end product will be the RIGHT product.  Frequent product updates are easily accomodateded, keeping customers engaged. And the sense of family I've observed is among the best I've ever seen.  The challenge?  Management must be willing to live with "managed chaos." But looking at the results, it works!

Oh, and on the real estate side:
From a real estate perspective, this method is best served by a pod layout. Each team will have a highly collaborative (i.e. “open”) and somewhat isolated work area. The team members can speak to one another without ever getting up, and may well be able to see each other directly. There will then be collaborative spaces for scheduled and/or impromptu meetings, and there will be at least one very large room for ALL the teams to come together at once. Throw in a few executive offices and you’re there!