Being Agile in Practice – Part 2: Stable Teams

Being Agile in Practice – Part 2: Stable Teams - McKenna Agile Consultants

Following on from part one of our practical agile series on healthy backlogs, this is part two, focusing on stable teams.

When it comes to applying agile in practice, you need stable teams who can execute the work that you’ve identified when you put together a clear, well-formulated backlog of work.

A stable team is a cross-functional team that works together over the longer term. They are not quickly put together for one project, and then disbanded to reform around another project.

Committing to this stability is the key to achieving genuine agility and resilience.

Stable Teams are the Foundation of Agility

Without stable teams, maximising the potential benefits of agile becomes incredibly difficult. It’s common for leaders to alter the structure of their teams in response to external factors with people thinking things like; “we need to get more work done, let’s increase the team size” or “this team isn’t performing, let’s get a rockstar specialist to come in and save this”.

Yes, increasing the team size, or adding specialist knowledge can provide short term gains, but the best thing to do is cultivate and invest in long lived, stable teams.

Some of the benefits of having stable teams can include:

  • Predictability
  • Team spirit and sense of belonging
  • Aligned to a clear vision/strategy/product
  • Ownership

4 Tips for Creating and Maintaining Stable Teams

1. Get the right people on the team

You’d be surprised by how many teams we’ve worked with over the years that are unable to deliver a feature from ideation to completion on their own. This is not down to the team doing anything wrong, it is due to the team not being cross functional and not having the right people with the right skills on the team to deliver.

Teams that are not truly cross functional are more likely to encounter delays, have more dependencies and experience integration and quality challenges than teams that are. This often leads to changes in the team structure which disrupts the flow of the team.

A great way to overcome this is to run a team self-selection workshop. Simply get all the people required to deliver value together, set them some constraints and allow them to self-organise. For example, you could set some constraints such as; teams should be no more than 8 people, they must have a Scrum Master and Product Owner, and team members must have all of the skills required to deliver a feature from definition to done.

2. Get the size right

A critical element of building a high performing, stable team is to get the size of the team right. When sizing the team, consider Brooks’s Law which shows that adding people to a late software project will make it later, not save it.

The reason for this is down to the possible lines of communication in the team. A team of 3 people has 3 lines, a team of 7 has 21 lines and a team of 11, 55 lines. This number continues to increase with the more people added, increasing complexity, risk and intra team dynamics.

A good rule of thumb to manage this is to apply the idea of “Two-Pizza” teams from Amazon. With Jeff Bezos describing the underlying principle as “we try to create teams that are no larger than can be fed by two pizzas.”.

3. Invest in the team

Stable teams don’t just magically happen overnight, or even over the course of a sprint or two. Once you’ve set up a cross skilled, empowered, team that is small enough to be nimble and large enough to be effective, you need to look after these teams, support them and invest in them.

This doesn’t just mean providing them with tools, training and coaching, but give them the time and space to move through the stages of forming, norming, storming and performing.

This is easier to do that you think. Some practical ways that you can invest in your teams are:

  • Use capacity allocation – Encourage the team to use capacity allocation (the act of reserving a percentage of capacity to certain activities each sprint) to ensure that they make time for learning or as a guard band
  • Consider leaving a sprint unplanned each quarter for learning, innovation and team building (similar to the Innovation and Planning Iteration in the Scaled Agile Framework)
  • Give the team autonomy to complete their work in their own way

By experimenting with just one of the points above, you’ll be surprised at the impact on the team’s effectiveness and morale!

4. Track the team turnover

Stable teams need to actively created and maintained, with some level of people turnover normal in any kind of team. To ensure that you’re maintaining a level of stability in your teams, track the percentage of team member turnover per team, and if it’s high, dig in and try to understand why. Is it a morale issue? Does leadership keep on moving people? Are we working with an augmentation partner who moves people outside of our control?

What’s Next?

So, you’ve got healthy backlogs containing clear, well-defined and high-quality requirements, and now you have stable teams ready, willing and able to execute on this work, what’s next on your journey to applying agile in practice? You need to be able to get the value delivered early and often!

Read on for the next article in this series of Being Agile in Practice – Deliver Often.

And if you want to delve even further into the topic, or are looking for extra support to put agile into practice in your organisation, get in touch with our team today.

Share: