Coordinating Teams With Backlog Management

Transcription

1 Coordinating Teams With Backlog Management What You ll Learn 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 sprints 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 Sprint, 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. I show this in Figure 1. Copyright, 2012 Net Objectives 1

2 Figure 1: Organization of company with component teams for two different product lines. 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 sprints, 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 sprint 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. Copyright, 2012 Net Objectives 2

3 Figure 2. Teams collaborating together. 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. Figure 3. How work is assigned to the three teams involved. 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. Copyright, 2012 Net Objectives 3

4 Figure 4. Work selected for first sprint. After completing their first sprint, the teams select work for the second sprint. 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 sprint. Figure 5. Work selected for second sprint. Teams finally get to the point where all of the work done for the feature is completed and they can now integrate their work. Copyright, 2012 Net Objectives 4

5 Figure 6. All parts of feature have been done across the teams. 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 sprint. 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 ( consumption ) 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 sprint, 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 sprint. Therefore, instead of giving the teams their backlogs independently, they should be split up in a way that the work done each sprint will deliver a piece of functionality that can be demonstrated to the customer. This is shown in figures 7, 8 and 9. Figure 7. Work selected for first sprint to enable feedback of one slice of functionality. Copyright, 2012 Net Objectives 5

6 Figure 8. Work selected for second sprint to enable feedback of another slice of functionality. Figure 9. Work selected for second sprint to enable feedback of last slice of functionality. 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 Lean-Kanban Distinction: The Macro Team In making decisions on how to develop software, Lean s mantra of optimizing the whole provides essential insights. In this case, instead of focusing on how each team individually works, we must consider the macro-team, that is, the larger team actually building the software. How will it best develop software with the shortest feedback loops possible? for years that Scrum, under the context of Lean flow, is much more effective than Scrum alone. Copyright, 2012 Net Objectives 6

7 Summary 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 sprint wise basis. Copyright, 2012 Net Objectives 7