Skip to content

‘Managing’​ Stable teams

More and more organizations are adapting to scrum. Managers responsible for ‘managing’ resources get new challenges In general traditional resource management is on defining a new team for a new project and ramping down the team when the project ends. During escalations the best resources are pulled out of the team to fix a crisis or resources are shared between teams to maximize utilization.

Moving to an agile organization requires different managerial approach that focuses on creating stable self organizing teams. In this article I will discuss a what a stable team is, what the benefits are and what manager can do to enable stabile teams.

What is a stable team?

In a 2014 study Rally defined a stability metric to measure the stability of a team. A team is 100% stable if all team member stay on the same team during a quarter. The study showed no team was 100% stable. Out of 4 team members 1 team member would be changed. This also corresponds with my observations. I consider a team to be stable when one team member is change (1 person off boarded and 1 person on boarded) during an increment. An increment varies between 10 to 12 weeks.

Why a stable team?

The longer members stay together as an intact group, the better they do. As unreasonable as this may seem, the research evidence is unambiguous. Whether it is a basketball team or a string quartet, teams that stay together longer play together better. Consider crews flying commercial airplanes. The National Transportation Safety Board found that 73% of the incidents in its database occurred on a crew’s first day of flying together, before people had the chance to learn through experience how best to operate as a team—and 44% of those took place on a crew’s very first flight. Also, a NASA study found that fatigued crews who had a history of working together made about half as many errors as crews composed of rested pilots who had not flown together before (1).

The 2014 study from Rally (2) stabile teams are on average 60 % more productive. Teams with 95 % dedication or more where 2:1 more productive then teams who were 50% or less dedicated. This is in line with lean studies on research sharing. Rally measured also predictability and responsiveness. Stable teams score 40% better predictability and 60 % on responsiveness.

How to do you organise a stable team?

Richard Hickman researched (1) teams and concluded 60 % of the performance of a team is determined with the design of a team. 30 % is determined with the launch of a team and 10 % when the team is on their way. I think finding the right people to create a team is the primary responsibility for management. There is also an example in which people them self sign up for a team. This could be an interesting experiment to try. Facilitating and enabling teams to have a good launch is next responsibility. Providing coaching when a team is on its way is another responsibility.

The most important responsibility is to not intervene directly in teams. In my experience I see managers have a natural tendency/habit to directly react and act and impact the stability of a team. Escalations happen and the best resources are pulled out of the team. Teams are behind schedule and directly the more resources are added to catch up. This actually will slow the team down more.

What is left to manage?

Ultimately stabile self organising teams will require individual team members to manage them self first. Taking real ownership and give commitment will require more self management. Next self organising teams will require less management. So enabling stable self organising teams could lead to less managers. During a presentation on the Agile transition at BASE the IT manager responsible for this transition simply toke up another role because he added no value in his IT manager role. I find this a very courage step.

(1) Collaborative Intelligence – Using Teams to Solve Hard Problems, J. Richard Hackman

(2) The Impact of Lean and Agile Quantified: 2014

Leave a Reply

Your email address will not be published. Required fields are marked *