This chapter is from the book
This chapter is from the book
This chapter is from the book
Transition
In his report on feature teams in Ericsson [KAL00], Karlsson observed, “Implementing daily build and feature teams in an organization with a strong [traditional] development process, distributed development and a tradition of module [single component] responsibility is not an easy task.” It takes hard work and management commitment.
There are several tactics for transitioning to feature teams:
- reorganize into broad cross-component feature teams
- gradually expand team responsibility
Reorganize into Broad Cross-Component Feature Teams
One change tactic is to reorganize so that, collectively, the new teams have knowledge of most of the system. How? By grouping different specialists from most component areas (Figure 7.11).
A variation is that a new team is formed more narrowly with specialists from the subset of most components typically used in one (customer) requirements area, such as “PDF printing.” This approach exploits the fact that there is a semi-predictable subset of components related to one requirements area. It is simpler to achieve and reduces the learning burden on team members.
When one product at Xerox made the transition to feature teams, it started out by forming larger (eleven- or twelve-member) teams than the recommended Scrum average of seven. The advantage was that a sufficiently broad cross-section of specialists was brought together into feature teams capable of handling most features. The disadvantage was that twelve members is an unwieldy size for creating a single jelled team with common purpose.
)
Figure 7.11 moving to feature teams
Gradually Expand Teams’ Responsibility
For some, reorganizing to full-feature teams is considered too difficult, although in fact the impediments are often mindset and political will. As an alternative, take smaller steps to gradually expand teams’ responsibility from component to “multi-component” teams to true feature teams.
Simplified example: Suppose an organization has four component teams A, B, C, and D. Create two AB teams and two CD teams from the original four groups, slowly broadening the responsibilities of the teams, and increasing cross-component learning. A customer feature will still need to be split across more flexible “multi-component” teams, but things are a little better. Eight months later, the two AB and two CD teams can be reformed into four ABCD teams… and so on.
One Nokia product took this path, and formed AB teams based on the guideline of combining from closely interacting components; that is, they chose A and B components (and thus teams) that directly interacted with each other. Consequently, the original team A and team B developers already had some familiarity with each other’s components, at least in terms of interfaces and responsibilities.