- Thinking about Adoption & Improvement
- Early Days: Team & Management Changes
- Early Days: Breaking Barriers & Habits
- Early Days: Gatherings
- Coaching & Community
- Continuous Improvement
- Conclusion
- Recommended Readings
This chapter is from the book
This chapter is from the book
This chapter is from the book
Early Days: Team & Management Changes
Try...Transition from component to feature teams gradually
Over the years that we have been involved in the transition to feature teams from component teams (in large groups involving hundreds of people), we have seen several strategies—and not always smooth. In Feature Teams in the companion book we shared two:
- big-bang reorganization
- gradual expansion of component teams' responsibility
The first strategy can work better than one might expect, but not many organizations want to take that plunge because the change is big and they consider it risky. Plus, it is a challenge in a 20-year-old multisite product group with 100 long-established component teams. The second strategy does not work that well, because it creates both the drawbacks of feature and component teams.
Another strategy we have experimented with (not described in the companion book) is the gradual introduction of feature teams, applied only to the most important new customer features.
For instance, take the most important new feature, item-1. Form one new cross-component and cross-functional feature team, Team Red (Figure 11.1), by extracting only a few members out of existing component and single-function teams (such as analysis and testing). The old teams remain, slightly smaller, and Team Red is born: starting life by working on item-1. In this way, new high-value work benefits from the speed and simplicity of feature teams, while change impact is softened.
)
Figure 11.1 a gradual transition from component to feature teams, focusing on the most important features
- Note!—Team Red is not a temporary project group formed only for the purpose of feature-M. We are not suggesting the traditional practice of resource management with resource pools for short-term work groups. Rather, Team Red is a new stable team that will stay together for years; feature-M is but the first of many features they will eventually do.
-
Disadvantages—This approach also has drawbacks. The first, broadly, is conflicts caused by having two 'competing' organizations in place at the same time...
- feature teams change code that component teams own
- the analysis and architecture groups lose 'control' over deciding how to implement a feature, and the test group over the testing The second drawback is that this approach is slow—not a major problem for big product groups that are around for a long time!
Avoid...Waiting for the organization chart
Official agreement on changes to the organization chart for a reorganization to cross-component and cross-functional teams can take a long time—especially in long-established large groups. In the groups we work with, the successful strategy is to not wait for that, but to immediately and informally create new cross-functional Scrum teams by dispersing the old teams. The existing line managers (say, a test manager) then have people 'reporting' to them from multiple teams. Usually, after some months, the organization chart catches up.
What about the prior line managers, such as the test-group line manager? They may become line managers of several new cross-functional cross-component Scrum teams.8
Avoid...In-line 'ScrumMaster' line- or project managers
Before adopting agile development, most groups had project managers or line managers. In some, during early days of agile adoption, rather than supporting the emergence of self-managing teams (the 11th agile principle) with a real ScrumMaster, the managers relabel themselves ScrumMasters of their in-line teams—often to meet a top-down target to do Scrum. Avoid that, since a ScrumMaster is not the team's line or project manager and has no authority over the team they serve; there would be a conflict between having authority and no authority.
On the other hand, some line managers can serve as excellent real ScrumMasters—they may have the right skills and servant-oriented character, they may have some influence in the organization, and this role increases their focus on improving the system. How to resolve? In some groups at Xerox, for example, a line manager of team-A offers to serve as a ScrumMaster for out-of-line team-B; team-B decides on the offer. The two points are (1) it is an out-of-line team, and (2) ScrumMasters are chosen by the team, not imposed.