Clinton Keith on Shared Infrastructure Teams
Clinton Keith has a new post about managing Shared Infrastructure teams in an agile project environment. According to Keith, a Shared Infrastructure (SI) team is one that "provides low-level support such as engine, audio, online, etc services" that multiple products rely on within an organization.
I've spent the majority of the last 4 or so years involved with or directly managing an SI team, so Keith's post is interesting in that it provides another perspective on a topic that I haven't been able to find much material on. My own practices with SI teams have been learned mostly through trial-and-error, research, and process design of my own.
Two points in particular strike me as most critical:
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.
This couldn't be more important. The purpose of an SI team is to provide features and support for all product teams in an organization, which means it needs to maintain commonality and robustness. The only way to accomplish this is if one voice (i.e. the PO) speaks for the SI team and one set of priorities exist in determining the work required to achieve the SI team vision.
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.
I've fallen into this trap myself of not scheduling enough time for product support, which leads to slipping engine features or fixes to the right while product needs take priority (and they almost always take priority). This has the negative long-term effect of the engine gaining some design bias over time toward the products that require more support. It's not an ideal situation.
Managing an SI team isn't easy, so if you're interested in or involved with this sort of thing, take a peek at Keith's article for a few good pointers.
Filed under: Process
