This chapter is from the book
This chapter is from the book
This chapter is from the book
Continuous Improvement
This section has two categories:
- multiteam coordination, such as a Joint Retrospective
- other general experiments
Multiteam Coordination Experiments...
Try...Joint Sprint Retrospectives
An iteration ends with an individual team Sprint Retrospective, where the focus is team-level improvement actions. In large-scale Scrum there is the bigger system to inspect and adapt. For this, experiment with Joint Retrospectives each iteration.
When?—Since the iteration ends with a team retrospective, most of our clients hold this early in the first week of the subsequent iteration—when the issues of the previous iteration and recent team-level retrospectives are still fresh in mind.
)
Who?—In general, one or two representatives from each team. Since ScrumMasters are closely involved in understanding and helping improve the system, they are good candidates. However, avoid ScrumMaster-only meetings; this gives the wrong impression that ScrumMasters are solely responsible for improvement (rather than other team members too), and it increases bias during the workshop.
Scope of teams?—This depends on the scale: If there is only one small 10- or 20-team group at one site, one Joint Retrospective with representatives from all teams suffices. If it is larger and there are requirement areas, then each area is a good scope for a retrospective. Because many issues are site specific, a site-level retrospective is also useful: one in Curitiba, one in Chengdu, and so on. Finally, for larger groups, experiment with a top-level Joint Retrospective (above the site and requirement areas); in this case, it is most often a multisite retrospective.
Where?—Use a big room, with lots of whiteboards since there may be dozens of people in a Joint Retrospective. See the Multisite chapter for tips in that case.
)
How?—As with any retrospective, variety of workshop activities over time is a guiding principle. Broad suggestions:
- Try Open Space Technology [Owen97], World Café [BI05], and Future Search [WJ00] for Joint Retrospectives.
- Apply the diverge-merge pattern—useful in any large workshop.
What?—Too often, a retrospective focuses only on problems. Experiment with sharing what is going well for a site or team, that others may try. This is the yokoten—spread practices laterally—approach used at Toyota. A joint retrospective is also a time to review and change existing coordination working agreements.
Try...Joint Retrospective big improvements in Product Backlog
Major (expensive) improvement ideas are added to the Product Backlog so that they are visible to—and prioritized by—the Product Owner. This is even more important when there are intermediate Joint Retrospectives below the overall product level. For example, suppose there are 20 teams in Curitiba (Brazil) and 20 teams in Chengdu (China). Each sub-group holds its own site-level retrospective and identifies the same major improvement goal. These need to flow into a common list, the backlog, to prevent duplication and so that the Product Owner sees cross-site problems.
And who takes on this work? An existing feature team.
Note—This relates to other suggestions in this and the companion book. If the improvement goal involves common software, this leads to a feature team working on shared infrastructure (see Feature Teams in the companion). If it involves creating common test-automation testware, this leads to a feature team doing test automation (see the Test chapter).
Try...Cross-team working agreements
External-to-team working agreements usually define how teams agree to work together; for instance, holding a joint design workshop. They may or may not be product-wide; a subset of teams that work together frequently can have their own agreement. They are defined or evolved in Joint Retrospectives.
Try...Joint Sprint Reviews
A Joint Retrospective is vital to inspect and adapt the system-level ways of working. Similarly, a Joint Review is pivotal to focus on inspect-and-adapt for the overall product. At one of our large-group clients, the last day of the iteration runs as follows:
- Product-level Joint Review—The overall Product Owner (PO) and supporting PO representatives are in meeting rooms around the world, all linked together with video conferencing and shared desktop technology. There are also representatives from various teams.10 What is presented? A subset of items that are of special or overall interest to the entire product group. What is discussed? Issues relevant to the overall product.
- Single-team Sprint Review or multiteam Joint Reviews—When a supporting PO representative is served by only one team, a standard Sprint Review occurs. When the PO representative is served by several teams or the Area PO is involved, we have seen clients either (1) stagger the Sprint Reviews so that the PO representative or Area PO meets separately with each, and (2) a Joint Review with several teams together.
- Single-team Sprint Retrospectives.
A review bazaar—A Sprint Review involves conversation, not only a demonstration of the product; nevertheless, showing the running system is important. One technique applicable to a Joint Sprint Review is a bazaar [Schatz05], analogous to a science fair: A large room has multiple areas, each staffed by team representatives, where the features developed by a team are shown and discussed. Members of the Product Owner Team and Scrum teams visit areas of interest.
Avoid...Try...Individual team-level Sprint Review
If an individual team has its own separate Sprint Review, there is a danger—one that we have seen in action—that the team focuses on 'their' result instead of the overall product created by all teams together. This leads to a loss of systems focus and an increase in local sub-optimization. Avoid that. However, a Joint Review does not review all items developed during the iteration (since there are so many), and the team that developed a feature might need detailed feedback from their Product Owner. If separate reviews are held, people need to watch out for a loss of product-level focus.
Other Experiments...
Try...Spend money on improving, instead of "adding capacity"
Very large product groups become large because their default response to delivery-speed problems is to hire more people. Avoid that, and in contrast, apply the lean-thinking strategy of removing waste to improve the flow of value—reducing handoffs, WIP, and so forth. Note that the approach is more subtractive than additive. Often, this waste removal does not even incur additional capital investment or operating expense.
)
And yet, spending more money ("increasing cost") can contribute to improving—without using it to hire more people. For example, when I (Craig here) started working at Valtech India, I noticed that people had only one small monitor. Research suggests improvements if people have more than one [Atwood08], so we bought a second monitor for everyone.
Other common—and valuable—examples include hiring expert coaches who mentor people, and classroom education with great teachers.
Try...Lower the waters in the lake
One metaphor for continual improvement—sometimes used in lean thinking—is the lake and rocks. 11
)
How to work toward flow of value to customers and continually improve? Do this by gradually lowering the waters in the lake. The water level symbolizes the amount of inventory, WIP, batch size, handoff, or cycle time. 12 That is, gradually decrease their size. As they grow smaller—as the water level lowers—new rocks hidden below the surface of the water are revealed. These represent the weaknesses and impediments in the system.
For example, perhaps a group first moves from a long two-year sequential life cycle to a four-week timeboxed iterative cycle. Some outstanding weaknesses in the system—the biggest rocks—will become painfully obvious; for instance, lack of automated tests and efficient integration. The group works on these big visible rocks; eventually they shrink in size. Then, as discussed in the "Try...Two-week iterations to break waterfall habits" section on page 394, the cycle time is lowered to two weeks to confront deeper problems.
Especially in large traditional groups there is a massive pile of rocks. The scale of improvement work can seem overwhelming. The strategy behind this metaphor makes the work tractable, while also signifying that kaizen is never finished.
Avoid...Rotating the ScrumMaster role quickly
It takes study and practice to become an effective ScrumMaster—at the very least a year. And a ScrumMaster ought to focus on organizational change—and that requires long-term constancy of purpose.
If the role is rotated quickly within a team, that necessary period of practice is missing and the organizational-improvement focus is missing or diminished. Therefore, do not rotate the position quickly.
On the other hand, a learning self-managing team should not be forever reliant on one person for this skill, and different team members should eventually have the opportunity or challenge to grow as ScrumMaster. Rotate the role—very slowly.
Try...Reduce harm of policies that cannot yet be removed
"We know that performance appraisals and performance-based incentives weaken the system, but we can't do anything about them—they're mandated by HR." We hear variations of this from some people who then want to give up trying to improve the system. But Scrum encourages the art of the possible. With creativity, the harm from various policies can often be reduced. And possibly sometime in the future, eliminated.
For example, Bas used to work in an organization that mandated performance reviews, targets, and bonuses. When he met with people that reported to him, instead of focusing on performance in their 'normal' work, they set targets related to learning, such as reading books and giving presentations. During the next review, they talked about the learning and how it applied at work. One person told Bas that nobody believed it when he told friends that he got a bonus for reading books.
Similarly, if performance-based rewards are mandated, perhaps they can be shifted to team-based goals so that there is a reduction in competition and an increase in cooperation.