When an organization transforms to a Scrum / Agile one of the key things we change is the way we determine who does work. Previously we would have mangers decide which people would do what work. If projects were large we’d build extensive systems to track the allocation of “full time equivalents (FTE)” to projects. In other words we brought people (or in fact parts of people) to work. With Scrum the unit of execution is not an FTE but a team (software = team). With Scrum the idea is that we want a team to work together for a period of time as, when they do this they become more than the sum of their parts and produce more value. To allow this to happen we change the “resourcing” problem so that we bring work to the team instead of forming groups of people around work.

This is a big change for an organization that has grown up with traditional project management. It is a total change in the way management thinks about software development and a difference for the people doing the work as well. Many times there is still a tendency for management to want to tinker with teams to deal with perceived work issues they are having negatively impacting productivity. To management this makes sense in that most managers can report results where, in the past a change in personal had the desired result. To help make the Scrum transition we establish a prohibition against making changes to teams so that people don’t revert to “old behavior” in the face of pressure. But is this really the best approach?

We decided to see what the data tells us. Scrum Masters track data so they can have (data-backed) discussions with team members about what teams need to do to improve, especially for retrospectives. Part of what is tracked is the actual velocity of the team (how much work the Team is able to do in a Sprint) and the number of team members that are on the team in that Sprint. Collecting this data allows us to understand the relationship between changes in team size and velocity (see Mike Cohn’s excellent blog on the approach we used).

Our first analysis against one set of velocity data across 65 Teams showed that the overall impact of adding or subtracting a person from a team was a reduction in velocity by about 21% for the next three sprints on average.

Adding or subtracting a person from a Team will reduce the capability of the Team to deliver by 21% for the next 3 Sprints on average.

This is a confirmation that change has a negative impact on average and is useful information for planning purposes. The message is “typically making changes to Team structure will reduce the capability of the Team to deliver” In some ways this is validation of Brooke’s Law.

Note: I recently re-ran this analysis at another organization using a 99 Team data set and the result stood: adding or subtracting a person from a Team results in a reduction in Team velocity of 24% for the next 3 Sprints on average for this analysis.

The question that results from this analysis is “does the velocity of the team recover” and “what conditions allow this to happen”? If we assume that team becomes a “norm-ing” team after 6 sprints on average (this is accepted knowledge within the Scrum / Agile community) we can understand the impact changes we have on teams by looking at:

• High-churn teams: do not have consistent team members for 6 sprints in a row for their life
• Low-churn teams: had at least one stretch of consistent team members for 6 sprints in a row during their life, one or two changes of a year
• No-churn teams: consistent team members for their entire life of the team

Before we run the analysis we need to make predictions:

• No-churn teams should result in the most improvement (we used “targeted value increase” or TVI as an indicator of this – see Scott Downey videos on metrics), followed by medium-churn teams, then high-churn teams.
• High-churn teams will result in increased / decreased velocity based on increasing / decreasing number of team members. This is because teams have not jelled so the total ability is simply the sum of the parts.
• Low-churn teams will result in decreased velocity for some part of the next 6 sprints no matter if you add or subtract team members (impact on team dynamics, return to velocity should be within 6 months).

Starting with prediction number 1, we find that our prediction does not pan out. Looking at the chart below we see that the most increase was with low churn was in fact higher than the no churn team, whereas, as expected they both had more increase than the high churn team.

We need to dig a little deeper to understand what is happening here. Interviews with the management involved in these changes revealed that there are differences in what happens based on who is being added or subtracted from the team, that there is a place for judicious change:

• Removing a toxic / ineffective member of the team. The rest of the team is seen to “break free.” We have seen examples of a particular person on the team being very negative about the work so that it brings down the rest of the team. We have seen examples where a team member is seen as ineffective by the other team members so the team feels that person is not pulling their weight. In both cases, removing that person allowed the team to improve.
• Adding a specific skill set to a team, to overcome something which is impeding delivery. We have seen cases where we need to overcome a problem with the initial formation of the team in that the team was not able to support the kind of work it was being asked to do because of lack of technical skills. Adding people with the appropriate skill set to the team allows the team to improve. Obvious, right? Not so obviously, we have seen changes by addressing the more non-technical skills. For example, replacing a Scrum Master who is “going through the motions” with a person who has a strong sense of Scrum practice and can inspire a team to more effective behaviors resulting in improved team performance.
• Changing the dynamics of the team. The best example of this is changing a team that has remote people on it, to teams that are co-located. In our case we had a number of teams that were 50 / 50 US and India based. They were set up as the Indian people were typically new hires and so needed extensive mentoring to get them started. Over time, the Indian parts of the team were increasingly able to complete work without US assistance. By splitting the teams based on geographical lines we improved the output of both halves, since there was a lot less communication overhead.
• Fresh blood. Sometimes the addition of a team member results in an infusion of new ideas to the team resulting in an overall pickup. Perhaps the ideas come from the other team the new team member worked on. Perhaps its just the enthusiasm generated when a new person is brought in (“management must think we are doing important work as they gave us this new person”). Irrespective there seems to be a positive result just based on being new to the team.

Turning to the second prediction, that if you add or subtract a person from a high churn team, you basically have a similar increase or decrease in velocity going forward (since teams members have not jelled so the total ability of the team is simply the sum of the parts.) This prediction basically pans out. Subtract one team member reduces the velocity for high churn teams, while adding a team member increases the velocity.

Note that I would ignore the results for the “-2” and “2”, “3” as the number of teams that actually went through this level of change are 3 or less in each case (versus more than 20 for the “-1” and “1”) case.

The final prediction that low churn teams will result in decreased velocity for the next 6 sprints only partially holds. If you take away a person it will take the team about 5 sprints to recover. Interestingly, if you increase a low churn team by 1, you will see an increase in velocity starting with the 3rd sprint. This seems to back the idea up that low churn teams have changes that are the result of judicious adjustment and so in general the effect is positive.

One final point before the summary. If the new team member joins a team and doesn't understand the basic process of the team you can expect longer adaptation times. Although I have no data to back this up, one reason we are able to do “judicious changes” is that every single person in our organization has gone through 2-3 day Scrum training, which talks about both principles and practices and aims at getting teams started using Scrum the very next day. This means at one level it is easy for people to move around teams as they have a common language (based on Scrum and Agile), a common set of artifacts (backlogs, definition of done), a common set of ceremonies (Sprint Planning, Sprint Review, Sprint Retrospective) and common roles (Scrum Master, Product Owner). Every team has different work, different culture, and different processes, but this basic Scrum practice is constant and allows for easier assimilation.

In summary:

• Adding or subtracting a person from a Team will reduce the capability of the Team to deliver by 21% for the next 3 Sprints on average.
• Making a judicious addition to the team will increase the velocity of the team on average, the effect will be seen pretty quickly and the team has the potential to increase its velocity a lot (more than the sum of its parts) providing it happens no more than once every 6 sprints.
• Subtracting a person from a team (again judicious) will recover velocity on average within 3 sprints.
• High churn teams should be avoided.
• We might want to look at changing things up with no churn teams to freshen things up.

Most of the analysis here is done using averages on good sized populations. As we worked these issues we found that while this might offer insight and guidelines for the general case, there are always exceptions to the rule. To determine what makes sense you should probably look at the velocity / membership information for the teams you are working with to determine whether there is an indication that something might need to be addressed. The next step is to the work with the team to understand what is really happening. In other words, the data is just that – data – and no decisions should be made simply using the data alone.

My thanks to the following people for input into this:

• Scrum Masters, for collecting the data to support the analysis
• Bob Schatz for discussion on how “who gets changed” is an important consideration
• Scott Duncan for discussion on how the predications were expected to turn out
• Wayne Morgan on specific people changes we have seen and the results from those changes.

• What Kinds of Problems Do You See When Agile Teams Churn Team Members a Lot?
• How Do We Reduce the Effect of Team Churn on Our Ability to Deliver Value?