Change is constant, yet people fear change. It is mostly the fear of unknown and loss of comfort zones that makes the perception of a change painful. Though Agile teams are well prepared for change, however, most of them are not comfortable when the change affects the team.
Dean Johnson started a discussion on the Scrum Development group to discuss the pitfalls of removing a team member from a team. This was based on his project experience where a team member was pulled by the VP for a few sprints. According to Dean, the negative consequences included
- This breaks the Team's rhythm,
- It hurts Team Velocity.
- Hurts the "gelling" of Team
Inspite of the stated problems, most responses on the discussion indicated that team changes were inevitable in the current business and market conditions. Teams should strive to minimize the effect of such changes in a constructive way. According to Jack Milunsky,
However, stuff happens, priorities change etc. So this needs to be viewed the broader company context. So what I would do is have a meeting with the team, discuss the impact of the loss of a resource. Move some stuff around that can be moved, de-prioritize what can't be managed anymore and move on.
Chris suggested a few things for the Scrum master to help and facilitate change.
- During the meetings ask everyone on the team about what they liked in their old teams and what would they like to change in the current team.
- Make yourself accessible to answer questions and concerns.
- Have team outings. Take the team out for lunch and ensure that the new members sit besides the old ones.
- As a Scrum Master, make sure you spend some 1 on 1 time with all members of the team to see how they are adapting to the new team dynamic
Alan Dayley suggested that one of the best ways to minimize the change pains is to leave the teams undisturbed till the end of sprint. At the boundary of sprints, additions and deletions from the team are less painful as compared to the start or the middle.
Doing it this way protects the results of the current sprint. It also provides for clear planning of both subsequent sprints
Mark Levison suggested that adding a member to an existing team also needs proper integration. The new team member would need to be trained on the existing codebase, would increase the communication complexity and would disrupt team formations.
Mark suggested a few interesting strategies to minimize change consequences,
- Say no to addition in a team if it is too late in the project.
- Bring on all the new people together to reduce the cost of adding team members incrementally.
- Create a team with a combination of new people and old timers.
- Get new people upto speed by asking them to refactor and write Unit tests, automated acceptance tests.
- Pair them with other developers.
Thus, team changes are inevitable. The key lies in minimizing their effect by adapting to change and moving on. After all, the main motive for Agile teams is to provide maximum business value for the stakeholders. As Gary Brown suggested,
You might not want to hear this, but the folks on this team are not your children. I truly apologize for that perhaps shocking statement. I want to restate this, you and your team only get paid to come to your place of employment everyday to deliver the maximum possible business value. Business value is what they say it is, not what you think it is. Partner with them. Deliver on your promises. Inspect and adapt.