First Order Agile Scaling

When we talk about scaling agile… we are really talking about how to coordinate the activities of many small teams to do the business of the enterprise. The interesting thing is that we don’t have to go from 6-8 people to thousands in one giant intellectual leap. There are plenty of problems to solve moving from only one team to as few as three or four.

How are we going to make sure that each of our teams are working on the right stuff and in the right order… how are we going to establish context and coordination? This post I want to explore a few models I’ve used over the years to try and solve this problem.

Scrum of Scrums

This seems to be the standard answer for scaling agile projects. Do you have more than one team? Easy… do a Scrum of Scrums. Great… but what does that mean? Who participates? How often do they meet? What are they tasked to do? If you have ever tried to answer this question for a real company… the idea can begin to break down pretty quickly.

The simplest implementation of a Scrum of Scrums involves the ScrumMasters from each of the teams getting together to deal with any cross-functional issues the teams can’t deal with locally. This group meets daily and answers the same type of questions the team members answers during the daily stand-up… what did your team do yesterday… what did your team do today… are there any organizational impediments that will prevent your team from delivering the sprint? This group usually meets sometime after all the other Scrum teams have had their daily stand-up.

This is a pretty useful collaboration tool if the teams are largely independent from each other. Remember…. independent means that they share few dependencies. If the teams do not need to operate in a coordinated fashion, from either a requirements perspective or a technology perspective, this model can work pretty well. It can be used to manage minor dependencies, but the goal of the Scrum of Scrums is primarily to communicate between teams and provide support for other teams that might be struggling to meet their objectives.

Product Owner Team

We’ve talked about the idea of a Product Owner team at the single-team level. We established that the role of the Product Owner was often too big, and an abstraction of too many roles, for a single person to do effectively. This is a pretty common problem in a mid-size organization because there are lots of stakeholders. It is even more common in an organization when you have more than one team working to deliver an integrated product.

In this case, you might want to consider pulling the Product Owner team out of the single team and have them work across several teams at one time. In this scenario, the Product Owner team might have a Chief Product Owner, the Project Manager, the Business Analyst, and UX designers. Just like in the small team scenario, this team is responsible for grooming the backlog for each of the Scrum teams and making sure that there is sufficient information ready for the team to consume during sprint planning.

In this model, each Scrum team would have a proxy for the Product Owner team and likely its own ScrumMaster.

The Product Owner team would be a team of its own with a prioritized backlog and full time team membership although they will likely have responsibilities outside the team as well. The Product Owner team works with each of the proxies and ScrumMasters to make sure that they have sufficient information to act on their behalf. The members of the Product Owner team are available to all the Scrum teams… just not allocated full time like the proxies and ScrumMasters.

This model works best primarily when its requirements that need to be synchronized across Scrum teams. You’d probably use this approach with feature based teams that can work across the entire software stack. We are in effect building a team of folks that are responsible for all the requirements decisions that cannot or should not be made at the individual team level.

Product Owner Team with Architects

This is a variation of the Product Owner team that is really geared more toward Leffingwell’s component team model. Because component teams don’t work across the entire software stack… there are technical decision that will have to be made across teams. Interfaces will have to be defined… software contracts will have to be established… complementary technologies will have to be chosen.

Irregardless of component teams or feature teams… I tend to like this model.

From my point of view… it is always a good idea to have the technical folks collaborate with the requirements folks to make sure that the requirements space and the solutions space are kept in balance. Technical collaboration with the business is built into the very fabric of our small team model but has to be explicitly accounted for when we start scaling technical decision across multiple teams.

Just like the Product Owner team is responsible for the decisions that cannot or should not be made at the team level… adding the Software Architect to the Product Owner team creates accountability for those technical decisions that cannot or should not be made by the team.

And by all means… drive as many technical decisions down to the team as possible. This group of folks should only deal with the decisions that you don’t want made by the team… because they are bigger than the team… because they are primarily strategic business decisions masquerading as technical decisions. I’ll also add that these decisions should not be made in vacuum… they should be made in collaboration with the teams that are actual doing the work.

Integration Teams

If you’ve come this far… you might find yourself in a situation where you need not only requirements context and coordination… and technical context and coordination… you might need a team of folks that can glue it all together once it is built. You need a team that can integrate the components and you need a team of folks that make sure it all works together when you are all done. Not a trivial problem, huh?

Context and Coordination

You’ll notice in these models… the more dependencies you have… the greater the context and coordination costs. And remember… at this scale we are only talking about 3 or 4 or 5 teams.

When you build your organization around small independent teams… where each team has autonomy to do what it needs to do to deliver against it’s objectives… you really just have a special case of ‘small team agile’. Product Owner or Product Owner teams don’t make all that much difference to the enterprise. Your concerns are not making sure that everyone is working on the right stuff in the right order… you are more concerned with making sure that we are communicating and cooperating. This is not a trivial problem… it’s just that the solution is not all that expensive.

When you start introducing dependencies between requirements, you have to make sure that everyone is working together to build the same product. At this point the Product Onwer or Product Owner team discussion becomes much more critical. You need a group of people that are charged with making sure all the teams are working together to build the right features, in the right order, and with the right level of common specification. Your context and coordination costs just went up a notch.

If your organization is so big, or so complicated, that you are really building systems of systems… you have a tremendous amount of dependence and interdependence across the product landscape. Each system may be a product in its own right and has to balance its own priorities against the priorities of the cross component features. Its no longer just that requirements are dependent on each other… your software architecture and technical infrastructure all has to be aware of what’s going on. Your context and coordination costs have just gone through the roof.

Can this still be agile?

It depends on how you define agility. I believe that you can build your organizations around small self-organized agile teams. Where I get hung up is on the single wringable Product Owner making all the decisions. A few posts ago I made the distinction between Product Owners and Product Ownership. We need Product Owners… but more than that… we need organizational Product Ownership. Each team can be independent and agile within the boundaries established by the broader organizational objectives.

Agile organizations build capabilities around small self-managed agile teams. Product Owners and ScrumMasters guide those teams. That DOES NOT mean that these teams get to build whatever the heck they want with no guidance from the larger organizational entity. Product Ownership involves establishing the broader requirements context and coordinating how our small agile teams work together to deliver the business value expected from a larger, more complex enterprises.