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!