Hi guys, in today's post I talk about changes. Nowadays, with this all dynamics of teams and projects, it is REALLY RARE to have a project with the same team from the beginning to the end. In fact, I never even went through that experience. In all the projects I worked on the team size always changed at some point.
This is the scenario! So, what we do? What can we expect? What are the problems that can happen and how can we avoid them?
In traditional software development, with no continuous delivery, the delays due to change the team's size are noted only at the end of the development, or may not even be noticed. However, when working with agile, continuous delivery and timebox (Sprint of 15 days, for instace), there is a greater transparency and the delays are perceptible.
I used the Scrumhalf to see reports with the points achieved by my team in the last 12 months. Some events occurred during this time modifying the size of the team. I decided to use these events as markers, so I could identify 4 different periods in the last 12 months.
Here the data for better viewing:
At the first period the team was formed by 4 members, been working together for over 1 year. The team was stabilized, with experience in the technology and in the Scrum process. During this period we obtained an average of 41 points with a standard deviation of 10.79.
The mark for the exchange period was the entry of a new team member with no experience in the technology and in Scrum. At that point, one of the experienced members of the development team assumed the role of Scrum Master. In this period the team obtained an average of 42 points, with a standard deviation of 13.56. We can say that this was a subtle change, because the team was able to absorb the new member and our average has remained fairly stable.
I must emphasize that, in my view, one of the factors for the success of this transition was to keep the old member as the new Scrum Master. The team could provide the necessary training and assistance for the new member to become familiar with the project with no impacts to the Sprints.
The third period starts with the left of an old and experienced members of the project. To make the situation even worse, in the middle of this period that new member who had recently entered the project also came out. At the same time, there was the arrival of a new person. During this confusing period the team's average dropped to 33 points, with a standard deviation of 11.93. A reduction of 20% compared to the previous periods.
In my opinion, the main reason for the decrease of the points was the left of the experienced developer, since it requires time to people who are coming to get into a good rhythm of work and keep in tune with the team.
The fourth period starts with the entry of 2 new members in the project. As there were recent changes, now the team knows how to deal better with the entry of new members and is able eliminate the common problems quickly, which smoothes the learning. That is the current period of the project work on and, so far, we are having an average of 39 points and a standard deviation of 8.31.
In the graph below we can see the distribution of the points done at each Sprint. The red line represents the number of points and the blue line is a polynomial trendline on these points.
If you've experienced a similar situation in your project, share your experience with us. Till the next post!
