Search

Monday, September 22, 2008

Shared Infrastructure Teams

Shared Infrastructure (SI) teams provide low level support such as engine, audio, online, etc services that multiple games rely on.

A frequently asked question is how shared infrastructure (SI) teams should organize themselves in an agile project environment. Since they support multiple teams, they receive requests for features that cannot easily prioritized as they are for a single team. This can create confusion and conflict between the SI team and their "customers", the games that depend upon them.

I've found that a number of practices are valuable for these teams:
  • SI teams require their own backlog and product owner (PO). Having more than one backlog and one PO is a recipe for disaster. The team should have every benefit that other agile teams have in an understandable backlog and single vision.
  • Customer teams should identify priorities during release planning and include the SI team (or at least their lead and PO) in their release planning. SI teams usually need a longer planning horizon than a single sprint.
  • SI teams should factor support into their velocity whether it is identified for tasks or not. Setting aside a certain percentage of your bandwidth for unexpected maintenance is critical.
  • Loaning SI team members out for a sprint is OK, but it should be identified in customer release planning. It's very valuable to have SI team members see how their "product" is being used.
  • The SI PO should ideally be at the executive level (or in frequent contact with them) to arbitrate conflicting product priorities. Deciding to support one game over the other is a company level (strategic) decision and should have the input from the people that run the studio. For example, the CTO should be the PO for the SI team (how's that for an acronym loaded sentence?).
With their own PO and backlog, an SI team can feel like a real team and take ownership of their work.

2 comments:

Darius Kazemi said...

Being on an SI team doing agile was one of the most productive and happy work experiences I've ever had. I was on a metrics team handling requests for two different MMORPGs, and with our own PO and backlog, everything went about as smoothly as could be reasonably expected. If we were unsure what the priority was between one game or another, that's when the PO would step in and declare priorities (one would hope after discussing with the leads on the two games).

Anonymous said...

I am on an SI team, and I totally agree with all the bullet points. The last one is the most important, and should be emphasized. Without somebody high up making the decisions, it can all fall apart.

In our company, there is the SI team, 12 client teams that create content, and 3 platform teams.

What can happen is, the SI team and one client agree on a new feature, but the others don't follow through. With our product, the content needs to be the same across all platforms, so if one platform team doesn't code the feature, it may have to be backed out.

As Clint says, you can avoid this by having somebody high up in the compmany arbitrate.

Another trick we use is to have a temporary cross platform team made up of the platform teams, the SI team, and the content creators. No new feature is coded until all 3 platform teams agree to support it. The temporary team meets once a week. The client teams request new features for the PBLs, and if everybody (the 3 platforms and the SI team) agrees, it goes on each team's PBL for the next sprint.

r