Scrum and other Agile methodologies rely heavily on a set team structure to succeed. In Scrum, you have a team, a ScrumMaster, and a product owner. These teams work on features that are iteratively developed. As explained by Mike Cohn, the teams are commonly called "feature teams." However, quite frequently, project teams are organized around layers or components of a product. These teams are called "component teams" (Cohn, Succeeding with Agile: Software Development Using Scrum,2009). The component teams work on a particular component or layer, and their responsibilities remain within the boundaries of the component or the layer they are tasked to develop. Two or more component teams' deliverables are integrated to make up a feature.
Reasons for component teams
Agile teams should be built around features. This way, a team is responsible for developing end-to-end functionality of a feature. Feature teams control the whole process, and this increases accountability toward delivering a flawless feature.
However, for a gamut of reasons, the projects are regularly organized into component teams. Some of the reasons for having component teams could be:
- The organization is unable to adapt to change.
- Component teams might be building functionality that's usable by multiple products.
- Office politics could prevent feature-wise organization (due to the reporting structure or for any other reason).
- Teams aren't able to learn all the skills needed to develop a full feature.
- The team is unable to change to the newer framework of Agile development.
Cohn (in Succeeding with Agile) and Craig Larman and Bas Vodde (in Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, 2008) discuss these and many other reasons for organizing project teams as component teams.
Implications of component teams
Slicing a project horizontally causes many problems for the overall development and delivery process. The examples of problems arising due to component teams are face-to face-conversations giving way to written communication, dependence on handouts, uneven work in a sprint for component teams at the upper layers, and, eventually, not being able to deliver workable software in an Agile manner. Each of the problems arising out of component teams can be serious enough to cause missed deadlines and poor quality.
However, even given all the problems with component teams and all the great things that feature teams can do, projects still do get organized into component teams. The most compelling reason to stay with component teams is to synergize development effort if a particular component functionality is used by more than one team. Even then, however, all efforts should be made to keep the number of component teams to a minimum.
Regardless of the reasons for having component teams and all the disadvantages associated with them, companies and projects of all flavors regularly work in a component team environment.
Working effectively with component teams
Of course, working in component teams does not mean that all is lost. Component teams are definitely a bad idea, but there are ways to work around the problems. Experience has shown me that there are ways to increase effectiveness, deliver high-quality products, and deliver everything on time. The following list gives the steps needed to succeed in a component team environment:
- A consuming component team (the component team that uses or "consumes" the deliverables of the other component teams) acts as the product owner of the producer team.
- Collaborate, define rules for engagement, and create a definition of done.
- Plan ahead.
- Use continuous integration strategy and automated tests.
- Embrace the Scrum of Scrums concept.
- Inspect and adapt.
The following sections discuss in more detail each of the items mentioned above.
The consuming component team(s) acts as product owner
Mike Cohn, in Succeeding with Agile, suggests that the teams at the upper layer should act as product owner of the lower layers.
As I mentioned earlier, the component teams themselves are Agile. They have their own product owner who prioritizes the "component" backlog. This product owner of the component team should work with representatives of the other teams. Effectively, the team that consumes a component team's deliverables should have a say in defining and prioritizing the backlog for that component team, just like the product owner of a feature team.
Collaborate, define rules for engagement, and create a definition of done
Agile values "individuals and interaction over processes and tools." It is imperative that team members understand how to work with each other. Individuals on different teams should communicate with each other directly, without going through layers of management. They should also work together without the need for unnecessary documentation.
Extreme Programming (XP) relies on rules of engagement to guide the pairs. All component teams that work together should have a brief list of guidelines that direct how members of teams interact with each other. It can be prepared by organizing a meeting between two teams, and the ScrumMaster of one of the teams can facilitate this meeting.
In the places where I have worked, definition of done is well understood within the development teams. It is extremely important to have a well-defined and published list of items that define "done" for each team. The definition of done should also include items that matter to the consuming teams, since they're the ones who are expected to be using the "done" components. When a database team says it's "done," the data access team knows what to expect.
All teams should spend some time during an iteration to groom the product backlog and prepare for future iterations. Similarly, the component teams working with each other should set aside some time to prepare for the future sprints.
In order to understand how to plan ahead, consider the following scenario:
The application team that develops the user interface (Team A) is dependent on composition designs from the screen design team (Team B). In this case, the Team B should stay ahead of the Team A by a sprint. This way, Team B has already reduced some uncertainty from the user stories that will be tackled by Team A.
One big disadvantage of this approach is that it has elements of a mini Waterfall. However, given the situation, this is best that can be done.
This works only if the dependencies between teams are no more than one level deep. If Team A depends on features from Team B, and if any of those features depend on Team C's deliverables, then this approach is not workable. In fact, it exposes a serious flaw in an organizational structure and should be corrected as soon as possible.
Continuous integration strategy and automated tests
One of the principles of the Agile Manifesto says, "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
What this means is that the teams should deliver production-quality software frequently. The delivery involves frequent customer review and using the feedback to enhance the product in an emergent fashion.
For component delivery, the delivery interval should be reduced to hours or minutes instead of weeks or months. In a component team culture, frequent integration of the components should be part of the continuous delivery mechanism. Continuous integration includes frequent code merges, frequent builds, and running automated tests. The teams that consume other components need confidence that they can integrate the lower layers into their system. Continuous integration (or, if you really want to get cutting edge, "continuous delivery" [J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, 2010]) gives the consumer teams that required confidence.
Embrace Scrum of Scrums
Scrum of Scrums should be used for synchronization between teams. Every team should select one or two representatives to attend this meeting. During the meeting, the representatives from the teams update other attendees on progress and the impediments that the teams are facing since the last meeting. One thing to keep in mind is that the purpose of this meeting is different from a daily stand-up. The impediment reporting in Scrum of Scrums should be restricted to those that are related to dependencies between teams or those that impact multiple teams.
Inspect and adapt
Agile development is all about continuous improvement. Multiteam retrospectives should be held to ensure that teams learn to get better at working together, in addition to improving agility within the teams. The teams could use someone from one of the teams or an outside person as the facilitator for the retrospectives. The teams should choose one or two action items from the retrospectives to work on during the upcoming iteration.
The steps mentioned above are intended to help teams mitigate risks associated with the component team environment. However, all efforts should be made to reorganize into feature teams as much and as early as possible. Feature teams are best equipped to deliver end-to-end features.
Obviously, it may not always be possible to get rid of component teams. For those that must work in a component team environment for one reason or another, this article should help provide better interaction between the teams. That, in turn, should drive better quality and on-time and on-budget delivery.