Changing the Composition of Agile Teams
Organization prefer to establish and nurture stable teams, as reported earlier this year in the InfoQ news developing stable teams, and dealing with dysfunctions. But sometimes there are reasons why the composition of a team or of teams needs to be changed. If changes in team composition are needed, how can they be done?
In the blog post teams, Pawel Brodzinski explains why it takes time for a team to form, and what the effect can be when you change team composition:
Tuckman’s Group Development Model, sometimes known as Forming, Storming, Norming, Performing, tells us that we need to go through, sometime painful, stages before our performance hits the decent levels. (…) Rebuilding a team is always treated as a huge risk and worse performance is usually expected over the course of the process.
Pawel mentions 2 reasons the team composition could be changed: Bringing newcomers in a team to keep the team fresh, and helping teams that are not doing well. Changing the team composition for these reasons should be done with care as Pawel describes:
Every person joining the team brings fresh blood. It is an occasion to use experience, knowledge and perspective of a newcomer to challenge the way things are done. (…) This is a reason why you should to add new people to a team from time to time. But before your rush to flood your great teams with truckload of newcomers remember that if you water the team down too much you will be back to the square one. You could disband the team immediately and form it again either way.
From a high-level organizational perspective, in short term it would be worth protecting your top-class team. However, in a long term it would be a way better choice to spread this culture over to other teams. But again, before you rush to disband your rock-star team and spread people all over the organization, remember that it isn’t magic which change teams immediately but more a catalyst which may, but may not, help spreading best practices and healthy culture across the company. Apply it in small doses or profits won’t be worth the cost.
In the blog post does your agile team have a bad apple, Edwin Dando explains how one misbehaving team member can create team-wide dysfunction and breakdown. He mentions his conclusions based on research done by Will Felps, Terence R. Mitchell and Eliza Byington on negative group members and dysfunctional groups:
In groups with a bad apple, other team members begin to take on the bad apple’s characteristics. When the confederate acted out one of the three personalities [depressive pessimist, jerk or slacker], the other team members acted the same way. When the bad apple was a jerk, other team members would begin acting like jerks. When he was a slacker, they began to slack, too.
Even worse, team members didn’t just act this way to him. They acted this way towards all other team members. In other words, one person's bad behavior has a ripple on effect propagating that type of behavior throughout the team.
This is an immensely important discovery. One bad apple can cause rot in the entire cart by altering the behavior of everyone.
Based on these conclusions, actions are needed when a team contains a bad apple:
We simply cannot tolerate this sort of behaviour. It ruins entire teams which in turns returns entire products. Don’t tolerate it. Ultimately, there are only three options:
- Nothing – live with it. Clearly not a good option.
- Preventative action – as a team define an agreement on what sorts of behaviours would make our team powerful and what we can count on from each other. (…)
- Reject them out of the team, for the sake of the Team. Is this hard? Yes – it is very difficult but nobody said this way easy. (…)
Len Lagestee wrote a blog post it only takes one (handling a bad team member) in which he gives some suggestions what you can when you have to let someone go or move a person off a team:
Define and communicate your values and principles. (…) Values will drive your decisions.
Be prepared. Bring your human resource department up to speed with the cultural and collaborative expectations for working in an Agile environment. (…)
Have a plan. This could be as simple as how you will start coaching an individual when the first issue is identified. (…)
Give them a chance. With values established, human resources, and a plan in place, give them every chance to change. Timebox the amount of time you will give them but give them every opportunity to improve.
Take action. Once your timebox expires and if problems persist, be definitive. Your people are watching how the situation is being handled.
Vin D’Amico wrote a blog post about don’t let your team become complacent and predictable in which he gives a reason to change the team composition by bringing in new team members:
Introducing new members to a team breeds new ideas and encourages innovation. New people bring new experiences, new perspectives, and new energies. The newbies are not bound by established norms and historical decisions. They are free to question everything and accept nothing.
He provides several suggestion for changing team composition:
- If your company has many software development teams, try moving personnel around from team to team.
- If your company is small, try rotating responsibilities among team members to promote cross-disciplinary skills.
- Hire new people from outside your industry and with varied backgrounds.
- Include non-technical people on the development team as analysts and testers.
- Get everyone out into the field from time to time so they can observe how real business users work.
Did you change the composition of your teams?