Hans Samios' Personal Lean-Agile Knowledge Base

... absolutely #noabsolutes ...

User Tools

Site Tools

Trace:
what_is_the_effect_of_changing_team_members_on_velocity

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
blog:what_is_the_effect_of_changing_team_members_on_velocity [2016/06/15 10:09] – ↷ Page name changed from blog:what_is_the_effective_changing_team_members_on_velocity to blog:what_is_the_effect_of_changing_team_members_on_velocity hpsamioswhat_is_the_effect_of_changing_team_members_on_velocity [2021/06/09 13:36] (current) – Added more recent analysis results hans
Line 1: Line 1:
-====== What Is The Effective Changing Team Members on Velocity? ======+====== What Is The Effect of Changing Team Members on Velocity? ======
  
 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. 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.
Line 5: Line 5:
 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? 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 [[http://www.mountaingoatsoftware.com/blog/predicting-velocity-when-teams-change-frequently|Mike Cohn’s excellent blog]] on the approach we used).+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 [[http://www.mountaingoatsoftware.com/blog/predicting-velocity-when-teams-change-frequently|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 [[http://en.wikipedia.org/wiki/Brooks's_law|Brooke’s Law]].+====== How Should We Plan Our Team's Ability to Deliver as We Change Team Structure? ======
  
-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:+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 [[http://en.wikipedia.org/wiki/Brooks's_law|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. 
 + 
 +====== What Are the Situations Where Changes to Team Structure Makes Sense? ====== 
 + 
 +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   * High-churn teams: do not have consistent team members for 6 sprints in a row for their life
Line 23: Line 33:
 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. 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.
  
-{{:blog:effect_of_churn_on_team.png?500 |}}+{{ effect_of_churn_on_team.png?500 |}}
  
 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: 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:
Line 34: Line 44:
 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. 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.
  
-{{:blog:tvi_recovery.png?500 |}}+{{ tvi_recovery.png?500 |}}
  
 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. 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.
Line 44: Line 54:
 In summary: 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.   * 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.   * Subtracting a person from a team (again judicious) will recover velocity on average within 3 sprints.
Line 58: Line 69:
   * Wayne Morgan on specific people changes we have seen and the results from those changes.   * Wayne Morgan on specific people changes we have seen and the results from those changes.
  
-{{tag>BlogEntry team FAQ velocity performance}}+====== Want to Know More? ====== 
 + 
 +  * [[:what_kinds_of_problems_do_you_see_when_agile_teams_churn_team_members_a_lot|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|How Do We Reduce the Effect of Team Churn on Our Ability to Deliver Value?]] 
 + 
 + 
 +{{tag>BlogEntry team FAQ velocity performance structure organization}}
  
-~~LINKBACK~~ 
-~~DISCUSSION~~ 
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/what_is_the_effect_of_changing_team_members_on_velocity.1466010579.txt.gz · Last modified: 2020/06/02 14:32 (external edit)