This chapter is from the book
This chapter is from the book
This chapter is from the book
Favor Feature Teams
When I first began to consult for a certain California-based game studio, its teams were organized around the specific elements and objects that would exist in the video game it was developing. There was a separate team for each character. There were weapons teams, a vehicle team, and so on. This led to problems, such as weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player.
On more traditional, corporate projects, we see equivalent problems when teams organize around the layers of an application. For example, a typical early-stage mistake for the project whose architecture is shown in Figure 10.4 would be to have four teams: a rich client team, a web client team, a middle-tier team, and a database team. Creating component teams such as these leads to a variety of problems including
- Reduced communication across the layers
- A feeling that design by contract is sufficient
- Ending sprints without a potentially shippable product increment
)
Figure 10.4 A typical three-tier architecture.
If structuring teams around the layers of an architecture is the wrong approach, what's better? Rather than organizing around components, each team on a project can ideally be responsible for end-to-end delivery of working (tested) features. A feature team working on the application shown in Figure 10.4 would, for example, work across all layers of the architecture. It might develop one feature that involves the database layer, the services tier, and the rich client user interface. In the same or next sprint, it would develop a feature going across the web client, services tier, and database tier.
There are many advantages to organizing multiteam projects into feature teams:
- Feature teams are better able to evaluate the impact of design decisions. At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members' learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?).
- Feature teams reduce waste created by hand-offs. Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.
- It ensures that the right people are talking. Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.
- Component teams create risk to the schedule. The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team's work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.
- It keeps the focus on delivering features. It can be tempting for a team to fall back into its pre-Scrum habits. Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum's focus on delivering features in each sprint.
Use Component Teams Sparingly
Although you should strongly favor the use of feature teams, there will be occasions when creating a component team is appropriate. A component team, as I'm using the term here, is a team that develops software to be delivered to another team on the project rather than directly to users. Examples of component teams include a team developing an object-relational mapping layer between the application and the database or a reusable user interface widget team.
It is important that a component team still produce high-quality, tested, potentially shippable code by the end of each sprint. However, the new capabilities created by a component team are usually meaningless on their own. Think back for a moment to the examples I just gave. The object-relational mapping layer developed by one of the component teams is of interest to end users only through the context in which it is used by feature teams. But what about the team developing the reusable user interface widgets such as custom drop-down lists, data entry grids, and so on? These are certainly of interest to end users, right? Yes, but again only within the context of other features. An end user is not interested in a new data entry grid until it is embedded onto a page or screen.
Build Components Only As Feature Teams Ask for Them
Because the work of a component team is delivered to another team, it is those teams who usually act as the product owner for the component team. If your team needs deliverables from my team, then you will act as the product owner to my team. As such you will have all the responsibilities of a good product owner. At the start of a sprint, you will need to help prioritize what I work on. At the end of the sprint you will accept or reject it, providing feedback to me on what has been produced.
It will be hard for you to prioritize my work and provide feedback on it if my team is working far in advance of yours. Because of this, a component team should not develop new capabilities until one or more feature teams is ready for them. When a component team works far in advance of what feature teams need, they resort to guessing at what capabilities are needed next. All too often this results in components or frameworks that are not usable by the feature teams. All new capabilities, including those built by component teams, should be developed within the context of externally visible functionality.
Rob was the senior developer on a component team developing an object-relational mapping layer that would be used by many of the 15 feature teams on the project. Rob's team was initially tasked with choosing between developing this technology in-house or using a commercial or open-source product. Members made the questionable decision to build it themselves. Anxious to prove the correctness of this decision, Rob and team tried aggressively to get ahead of the needs of the feature teams. Rather than working closely with one or more feature teams, Rob's component team made some big guesses about the grand design. For two months (two sprints) members didn't deliver anything to the feature teams. After the third month, when they finally delivered an initial version, it did not meet the needs or expectations of the feature teams.
What Rob's team should have done instead was work very closely with the feature teams and add new capabilities in the context of the features being delivered by the feature teams. This would have forced a much closer collaboration between the component team and the feature team, increasing the chances of delivering what was needed. Rob's team could have, for example, delivered only the ability to write fixed-length text data to the database in the first sprint. Feature teams who received that capability would not have been able to write numeric data, dates, and so on to the database. And they would not have been able to read any data. But, the feature teams could have done one thing—write fixed-length text data—and from that could have provided feedback to Rob and his team on the usability of the component.
Perhaps the best way to ensure that a component team hears the feedback it will need to create useful functionality is to staff the component team temporarily with people from the feature teams. A developer assigned to a component team who knows he will soon be moving back to a feature team will be more likely to make sure the work of the component team will be usable.
Deciding When a Component Team Is Appropriate
Whenever possible, form feature teams rather than component teams. I like to start out with the assumption that all teams on a multiteam project will be feature teams. I'm willing to back away from that assumption, but I only want to do so in the face of evidence that forming one or more component teams will be in the best interest of the product. I suggest considering a component team only when most of the following statements are true:
- The component team will build something that will be used by multiple feature teams. If a component will be used by only one feature team, have that feature team build it. This ensures that the new capability is built within the context of that team's needs and expectations, which makes the implementation more likely to be used. Even when a component team will build something useful to multiple teams, a better strategy is often to have one feature team build the functionality it needs and then have subsequent teams refactor and generalize the functionality as their needs arise.
- Using a component team will reduce the sharing of specialists. On some multiteam projects, some highly specialized disciplines are shared across many teams. Although some sharing of specialists is usually necessary, too much of it can be detrimental as the specialist's time becomes too fragmented. You may want to consider creating a component team if doing so will make more manageable the extent to which specialists are shared across many teams.
- The risk of multiple approaches outweighs the disadvantages of a component team. If we choose to build a shared component or service by having multiple feature teams contribute to the effort, there are two related risks to be aware of. First is the risk that each feature team implements a different solution to the same problem. Second is the risk that the feature teams each build on top of what prior feature teams have done but do so without a cohesive vision. These risks could be great or small, depending on what shared functionality is being built. When the risk of multiple approaches is high, a component team is a valid option.
- It will get people talking who might not talk otherwise. People tend to talk more with those on their team than those outside their team. This is true even on a Scrum project. In fact, it may be especially true on a Scrum project because team members on Scrum projects come to identify so strongly with their teams. You can use this to your advantage by creating teams from people who need to work together but who might not naturally talk to each other. If past experience shows that a project's artificial intelligence programmers do not talk often enough, this can help justify the short-term use of a component team, as long as there are other reasons for doing so.
- You can see an end to the need for the component team. A component team should not linger around forever, like my in-laws after the holidays. The team should develop the functionality it has been pulled together to create and then disband as soon as possible. When first forming a component team, it is not necessary to know when it will disband; however, you should have some idea of either how long it will exist or what will be delivered by the time the team has fulfilled its purpose. Because a component team is a deviation from the ideal of having all feature teams, you should be reluctant to create a component team that looks as though it might exist forever.
While acknowledging the occasional benefits of using a component team, I want to stress again that the vast majority of teams on a large project should be feature teams. Wes Williams and Mike Stout have described what happened at Sabre Airline Solutions when beginning with component teams.
- Stories weren't complete from a user perspective. Teams were working on different features at different times with different acceptance criteria. There was a lot of rework coming back into the system. Teams were blaming each other for incomplete functionality, failing builds, test, etc. In hindsight...the teams should have been structured along functional or feature lines. (2008, 359)
Who Makes These Decisions?
Ideally, the team makes decisions about how it is structured. If the team is to be trusted with solving the problem of how to build the product, it seems appropriate to trust it with the decision about how to structure itself to do so. However, though team members are accustomed to making technical decisions, they usually do not have a lot of experience making team organization decisions. So, initially the team may not be in the best position to design its own structure.
I've introduced Scrum to hundreds of teams. One of the things I've noticed is how frequently someone's initial exposure to Scrum results in an opinion like, "Scrum sounds wonderful for our company, and it will be great for all the other groups but not mine." Architects add, "After we do the up-front architecture, I can really see how this will help the programmers and testers." User experience designers say, "After we've done the up-front usability research, I can really see how this will work for the architects, programmers, and testers." Testers take the initial view, "It will be wonderful to have everyone working so closely together and then handing off to us for a big round of integration testing."
If we ask team members with these common initial mindsets to design the structure of their multiteam project, it shouldn't surprise us when they come back with plans for an architecture team, a programming team, a user experience team, and a test team. Of course I'm generalizing, but the tendency to think this way is so prevalent that it will be tempting to organize that way as well.
Initially, then, it is likely that functional managers, project managers, ScrumMasters, or those driving the transition to Scrum will make the decisions about how to organize the teams. These decision makers should solicit nonbinding input from their teams, especially from team members with past experience with Scrum or other agile methodologies.
What's Right Today May Be Wrong Tomorrow
An important thing to remember when selecting an appropriate team structure is that no team structure is forever. If the current team structure is impeding a team's or project's ability to use Scrum, that issue should be raised during an end-of-sprint retrospective. You don't want to continually change team structures, as team members need time to jell, but if the current structure is clearly wrong, change it.
As team members gain more experience with Scrum, it will be appropriate for them to become more involved in team structure decisions, including which teams are needed, whether each is a feature or component team, and who should be on each team.