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?
At first blush, the approach does make sense. How did we figure this out? 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 is done 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 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. So at least this is a short-term confirmation that change has a negative impact on average. This is useful information for planning purposes. The message is “don’t assume that when you make a change to the team that you’ll see an immediate improvement.” In some ways this is validation of Brooke’s Law.
However this is not the end of the discussion. 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:
Before we run the analysis we need to make predictions:
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:
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.
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: