Many companies operate with a project-based focus. When a new project is authorized, often times a new team is created to work on that project. Frequently the members of this new team may have limited prior experience working with one another. In those cases, we have to spend time and money to get this group of people to gel into a real team. In general, groups need to transition through phases such as forming, storming, norming, and performing, to become highly functional teams.
Paying the high price of team forming isn’t so bad if we do it once and then keep the highly functional team together for future development work. However, in many companies, when a project comes to an end, the team is disbanded too. And, at the start of the next project, a new group is formed and the company has to pay again the team-forming price to convert the new group into a team.
Scrum Requires Teams Not Groups
Effective use of Scrum requires teams, not groups. A team is made up of a diverse, cross-functional collection of collaborating people who are aligned to a common vision and work together to achieve that vision. A group is a collection of people with a common label. Other than sharing the group name, group members don’t share much else.
If a group never gels into a team, Scrum won’t be very effective. One way I can tell a collection of people is a group and not a team is if at the daily scrum meetings, nobody cares about what anyone else is saying because it doesn’t matter to them. The people aren’t a real team (yet or perhaps they will never be) because they are not yet working collaboratively towards meeting the sprint goal. If they were working collaboratively, there would be an interest in what the other people are doing.
The Economics Favor Long-Lived Teams
As a rule, teams should be long-lived. Simply stated, I keep my teams together as long as it is economically sensible to do so. And the economics are very favorable for long-lived teams. Long-lived teams are more productive than newly formed groups. And, team familiarity (team members’ prior shared work experience) can positively impact the efficiency and quality of team output. Improved productivity, efficiency, and quality lead to improved business results. (See Chapter 11 of my Essential Scrum book for more details)
Once we have a well-functioning team, we have a real business asset. Its members know how to work together, and have earned each other’s trust. In addition, the team has amassed important historical information, such as the team’s velocity and shared estimating history. If we disband the team or significantly change its composition, this valuable, team-specific historical information no longer has a context for direct use.
Also, without long-lived teams, planning activities become more difficult. For example, at the portfolio level we need to know what is the WiP (work in process) limit of our organization (basically, how much work can the organization perform at one time). Just knowing how many people of different skills are available (e.g., we have 100 developers, 50 testers, 5 UX people, etc.) makes it quite difficult to know how much work the organization should have in process. On the other hand, knowing how many high-performance agile teams we have provides a unit of capacity we can use to determine an effective WiP limit.
Align the Long-Lived Assets
Far too often organizations put a primary focus on projects and not on teams. Projects are fleeting—they start and they end (and the sooner the better). Products (or business services), on the other hand are long-lived assets. Over the life of a product there could be many projects that are carried out against that product.
Teams should also be viewed as long-lived assets of the organization. In Scrum the unit of capacity is the team. The unit of currency is the team. In fact, one of the core values of the Agile Manifesto is “Individuals and Interactions.” In other words, the team is the valuable asset.
As a rule, I want to align long-lived teams with long-lived products (or services). Not only would we get the benefits of long-lived teams, but also we get the additional benefit that these teams will develop deep expertise in the product(s) that they work on.
Keep Teams Together as Long as Practical
Most organizations would be far better off if they adopted a policy of keeping at least the core of their teams together as long as they can and moving teams from product to product if required. The economics of moving well-formed teams is almost always superior to the economics of moving people.
I’m not saying that you should always and can always keep your teams together for extended periods of time. For example, if we have a team that really hasn’t gelled the way we had hoped, or is otherwise dysfunctional, it is often less disruptive and economically more sensible to disband team or reconstitute the team composition.
In another case, I coached an organization where we knowingly broke up a high performance Scrum team as part of a split-and-seed strategy for broadening the adoption of Scrum within the organization. We didn’t split the team because it completed its work and it was time to reassign people to new teams for the next development effort. Instead, we split it because we believed it was more valuable to form six new Scrum teams, each with a person experienced with Scrum, than to keep the original team together.
Conclusion
A project-based mentality puts the focus on the project and not on the team that does the work. Often a new group is assigned to the project when it starts. The company then invests significant time and money to help the group gel into a real team, and then at the end of the project often disbands the now high-performing team and starts the cycle again. This is not an economically sensible approach. Teams should be viewed as long-lived assets of the company. They should be aligned with the long-lived products or services that the company provides. We should then keep our team together as long as it is economically sensible to do so, and the economics favor long-lived teams.