In some of the agile discussion groups I follow, people have been discussing how to scale out an agile product over multiple teams. These discussions are generally very informative and seem to lean in the direction of breaking product teams into feature teams for the product.
But what about when we have more products or components than we have teams, or even people? This is one of the major challenges we have faced at Covenant Eyes. While we have only two main services, we also have quite a few supporting products and services.
Our primary service is Internet accountability for individuals and families. This product has client components for Windows, Mac, Windows Mobile, and iPhone. It also has server and reporting components which are intended to gather information from the clients, and then distribute them as appropriate.
Our second service is filtering, which is available for just our Windows client. The filter requires a server component for analyzing and filtering web content in real time. This brings our number of components up to eight.
We also made the decision early on to allow our customers to register and perform the majority of their account management tasks online. This has four main products: our website, our registration system, our customer facing account management system and our internal account management system. This brings us to twelve total main components or products.
From what I have read, an ideal scrum team consists of about 8 team members, one product owner, and one scrum master. Our entire development team currently consists of 2 product owners, 1 scrum master, and 8 team members.
In short, the challenge is how do we distribute massive amount of products across limited personnel?
To that end, I have observed there are several aspects to consider when dividing team responsibilities:
- Mass or how much code a team has to cover. The more mass a team has to cover, the less effective the team will be.
- Bandwidth, or how many different initiatives you want to have going on at once.
- Focus, or how many other responsibilities the team has which may cause interruptions in a sprint.
In the next few posts, I hope to elaborate on the different ways we have attempted to break our team out to cover our products and services.