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.

Subscribe to Leading Agile Subscribe to Leading Agile

Scrum Gathering Agile Architecture Talk

One more post about the Scrum Gathering last week and then we'll get back to our discussion of the Agile Product Owner. I've got at least three or four or ten things left to say on that topic, but like I said last time... things are just nuts right now.

The first day of the gathering... the first session of the day... was hosted by Jim Coplien and Jeff Sutherland. The talk was called 'Not Your Grandfather's Architecture'. That talk was one of the first times I have heard someone make the case for intentional upfront architecture on an agile project. Prior to that talk... most of the agile architecture discussion seemed to be driven by Scott Ambler and Dean Leffingewell. It was cool to hear another side... especially being presented at a Scrum Gathering.

My primary takeaway from the talk centered around a few comments made by Jim Coplien. Jim compared architecture to DNA and design to the expression of individual genes. He was making the point that function emerges... not form. Jim stated that the tradtional Western notion that form follows function was just not true.

Jim encouraged the audience not to play stupid, to build on what you know. If there are key decision that need to be made and you know the answer... don't pretend you don't. Jeff Sutherland reinforced that point by talking about how PatientKeeper spends months doing analysis and prototypes before scrum teams start building out features. Both speakers drove home the point that the mind of the end user needs to be embedded in the software and teams need to focus on useable software... not just working software as the Manifesto tells us.

So... I personally agreed with much of what Jim and Jeff had to say and found it refreshing that this point of view was being discussed at the gathering. My experience has taught me that in any moderately complex organization, certain key decisions must be made up front regarding the software architecture... so this talk particularly resonated.

Last post I mentioned (in reference to one of my #scrumgathering tweets) how I felt about this whole agile architecture debate. One of the downsides of thinking out loud... and in public... is that sometimes you have to *actually* defend your point of view. Dave Nicollete called me on this whole architecture thing a few days ago... and now I owe him a response.

Here is Dave's comment to my last Scrum Gathering post:

"... in the many discussions and debates about agile methods and architecture, people just assume everyone knows whether they are talking about enterprise architecture or solution architecture. Often, when you scratch below the surface of an argument on this topic, you find one person was thinking of enterprise architecture and the other was thinking of solution architecture. Which of these do you think doesn't lend itself to an emergent approach, and why?" - Dave Nicolette

Here is my take on the software architecture thing in a little more detail. I tend to talk about architecture and design on three levels: enterprise architecture, software architecture, and detailed design. I have found these three levels useful to explain a few key concepts:

Enterprise Architecture represents the key decisions around the business platforms and technologies the organization is willing to support. Wikipedia quotes a formal definition of Enterprise Architecture from the MIT Center for Information Systems Research as "the organizing logic for business process and IT infrastructure reflecting the integration and standardization requirements of the firms operating model".

Software Architecture is the set of high level design decisions the organization makes when choosing what components will be used to create the software product and how those components will interact with each other and the outside world. Going back to Wikipedia, the software architecture of a program (or a computing system) is the "structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them".

Detailed Design is pretty much everything else underneath the software architecture. Detailed design is the sum total of all the other decisions, most of the decisions actually, about how the software will actually be constructed behind those higher level external interfaces.

Jim Coplien made the comment that you cannot refactor across class hierarchies. I am not a hard core technical guy but I think what Jim is saying is that Enterprise Architecture decisions need to be intentional... Software Architecture decisions need to be intentional... we inspect and adapt and refactor our way through the details behind the class hierarchies. In reality, these higher level decisions are really business decisions expressed in technology rather than technology decisions in and of themselves.

There is a fine line between the right level of up front planning and too much up front planning. It can be a slippery slope. As a project manager I simply want the team to understand what I call the 'big block architecture', what changes are going to be made in each of the blocks, and what the lines between the blocks mean. It is amazing to me how often teams cannot explain this basic level of information to me early in the project. Not understanding this has wreaked havoc on every moderately complex project I have ever worked on.

Okay... so there it is. There were lots of other cool points made throughout the talk but I think I've gone on long enough. Next post... we'll get back to the Product Owner stuff.

Subscribe to this blog Subscribe to Leading Agile