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