Handling Team Changes

Posted by Vikas Hazrati on Jun 08, 2010

Sections

Process & Practices

Topics

Team Collaboration ,

Distributed Team ,

Collaboration ,

Teamwork ,

Best Practices ,

Agile ,

Programming

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.

1. Back to top

   XebiaLabs, Deployment automation

   by XebiaLabs XebiaLabs

   Completely agree – team changes are inevitable, but, as you say, with Agile, teams can feel a bit more comfortable. What’s also important, however, is to recognize transitions among various teams that work together, not just changes within one team. For instance, when the development teams switch to Agile, operations teams need to follow suit to embrace the transition and ensure there are no kinks. What ways might you suggest bridging the gap between development and operations? www.xebialabs.com

   Reply

• Older >