Scrum suggests having self-organizing cross-functional teams. In the prior chapter we saw how violating this rule of cross-functional teams can cause problems. But sometimes large applications require specialization at the component level, making true cross-functionality impossible. The same difficulties we saw earlier show up, but in a different manner and may not always be recognized. One method that has been attempted to coordinate different component teams in Scrum, is called Scrum-of-Scrums. Unfortunately, there is not much experience in this approach working well. In this chapter, I’ll propose another method – that of coordinating the backlogs of the teams involved – to lower the amount of coordination needed while achieving quicker feedback loops. This also helps create the sense of a larger team, one which all members of the smaller teams involved can relate to.

Patterns of challenge

Teams complete iterations relatively well, but are not able to deliver in a timely manner. This occurs then each team is working on some component of a feature well, but does not coordinate well with the other teams that are needed to complete the business capability that this component is a part of.

When product size prevents true cross-functional teams

There are often valid reasons to have teams building components for other teams. For example, there may be a component team that builds modules for different applications of a company. Unfortunately, a side effect of this is that true cross-functionality is lost. When this situation occurs, what is the best method to avoid the delays that occur when cross-functional teams are not present?

Building by iteration, integrating at feature level

Let’s look at the situation where we have a hundred or so developers organized around two or more product lines which we’ll call Product Line A and Product Line B. Each of these applications has their own component team that develops shared methods. There is also a component team that works across applications (Figure 1).

In many ways this is just a larger scale example of the earlier problem discussed in The Value of Cross-Functional Teams. One solution would be to create cross-functional teams that had folks from each application, the component team(s) for the application and the component team(s) that ran across applications (in reality there was more than one team for each of the type of components being built). If this is possible, I would recommend it. But what if it weren’t? How would you do the work?

This is a situation I’ve seen many times. Unfortunately, there is a symptom that often occurs with this type of team structure. This is that teams can often write and test code within their iterations, but that actually getting something out the door takes much longer. I remember working with a client that had very good expertise with Scrum telling me that all of their teams finished writing and testing their stories each iteration but that actually delivering something took a couple of months. These two statements did not really jibe with each other so we did a little Value Stream Mapping to see what was happening.

The teams involved represented a cross-section of teams – all together working to develop a set of functionality. I illustrate the teams as grayed out in Figure 2.

Let’s look at a representation of the value stream of the work these teams do. Figure 3 shows how the work of a feature is spread out across these teams. Each team gets a backlog consisting of their part of the feature.

The teams now take these backlogs and work at their own discretion. This typically means they are not well coordinated as shown in Figures 4, 5 and 6.

After completing their first iteration, the teams select work for the second iteration. Notice that while the work from the first work may be completed, because each team did not coordinate with the other teams in which work they took off the product backlog, they were unable to do any significant integration after the first iteration.

Teams finally get to the point where all of the work done for the feature is completed and they can now integrate their work.

Of course, now we have to integrate the combined pieces. The challenge is that it’s been several weeks that we’ve been working on these different parts of the system and integration will take longer than if had been doing it on a continual basis. It’s also not possible to show functionality until this point so our feedback loop is much longer than the length of the iteration.

Building and integrating across the feature level

The question arises how to solve this challenge. Lean flow tells us not only do we want to have the time from start (“conception”) to completion (“realization of value”) as soon as possible, but to have as few delays as possible along the way. This means quick feedback loops along the entire value stream. Clearly it is better to get feedback to show the customer as soon as possible. Scrum as well implies this. If we are supposed to deliver working software at the end of every iteration, even though it’s not possible for each team to do so, it is clear that the team of teams should be delivering working software every iteration.

Therefore, instead of giving the teams their backlogs independently, they should be split up in a way that the work done each iteration will deliver a piece of functionality that can be demonstrated to the customer. This is shown in figures 7, 8 and 9.

The improved feedback cycles that this method provides enables demonstration of the software at a much quicker pace and lowers the amount of integration work required. This also allows all of the teams a greater vision of what they are building.

A new distinction arises: The Macro-Team

At the first client at which I suggested this, one person said that all I was doing was creating a bigger team. I think he’s right. That is, instead of three teams that have to work together, we now have one larger team working together. The insights provided to do this, however, come from understanding Lean flow. It was clear that building software that wasn’t able to be demonstrated was the problem. The missing piece was focusing on how to shorten the feedback loops and the optimization across the teams involved. This underscores my observations for years that Scrum, under the context of Lean flow, is much more effective than Scrum alone.

Summary: A pattern of success

Software development should be guided by two things: the customer and getting feedback without delay across the entire value stream (within the context of adding business value, of course). When work is split across multiple teams, it is important that a larger team be kept in mind. By providing the work in a coordinated way to this macro-team, the coordination required by the components of the team is reduced. This larger team is the smallest team that can deliver value to the customer. The product backlog for this larger team should be managed so value is delivered, or at least demonstrated, on a iteration-wise basis.