Following up to a discussion I had as an Agile Coach with a team, I painted a simple graph what can be a great food for thought and discussion: what happens if you fiddle with the team size?

In Agile and Scrum utopia teams exists forever and have time and means to improve themselves. They are self-steering so take care of the team as well. In practice, that usually is not the case. Sometimes (in the consultancy project driven world I work in) there are budgets, projects and project managers who guard these. As an Agile coach you’re sometimes caught in the middle when “resources” (they mean: people) are added or removed from teams due to several reasons. To help clarify the effects of this I like to share these thoughts with you.

Startup and sustain periods

When a new team starts (e.g. when a new project starts in the previous mentioned world) a certain “normal” pattern occurs with the team’s velocity. The first 3 or 4 sprints or so, the velocity increases. People get to know each other, the team is getting used to their teammates and the subject matter becomes more known. I call this the startup period. Length may vary depending on the team, the subject matter, the organization, the sprint length, etc.

After that, a period starts I like to call the sustain period. The velocity might go up or down based on the ability to improve, but I like to look at what happens when something is done with the people in the team.

A subject matter change (A)

If the team starts working on something completely different, like a new website, maybe some other technology, a lot of knowledge collected is no longer useful. Maybe another Product Owner gets in place and stakeholders change. This has quite a severe effect on the velocity. Almost like the start of a new team, only the team dynamics stay in place; they know each other and their competences, but a lot of new stuff and new communication lines need to be discovered and installed. This is maybe unavoidable, but one need to realise what the effect is.

A small team change (B)

A small team change can be replacing a team member or adding but not removing a team member (see D and E for that). The good thing here is, that the (usually unwritten) knowledge of the team remains, the new guy learns from the team members and gets introduced into their way of working and communicating. The impact isn’t that big (as long as the team member leaving isn’t the team’s superhero, which a team shouldn’t have, but that’s another subject) but still everything goes down for a bit: velocity, predictability, the average number of stories done, the estimation accuracy and the matter knowledge.

A big team change (C)

A big team change is usually not recommended, you lose the knowledge of the team and it’s like a new team with a few people who know how they did it in the old team. This brings the team back to start and basically back into the startup period. Getting to the sustain period might go a bit more smoothly depending on the knowledge left over in the team.

Up sizing or downsizing (D and E)

When people are added or removed from the team, basics like velocity and number of stories done go up or down accordingly, but predictability, estimation accuracy and matter knowledge go down in both cases. Since there is a new team member or a team member has left, the team needs to restore balance. That influences predictability, because they need to find out how to estimate in the new setting. Maybe a story point devaluates and that does not matter, because a story point in itself has no meaning, but is a means for the team to do their planning. They have to reestablish that. Of course some knowledge leaves with the leaving team member and a new team member needs to acquire that knowledge, so matter knowledge will suffer.

Conclusion

I realise that this is a quite generic approach, but I hope it helps the discussion and the understanding people have when you change a team or the team changes itself (that would be the best variant). For specific teams in specific situations, this all happens (a bit) different, but I think this is a good starting point. So I hope this helps you and please share your experiences with me!