Stable Agile Teams

By Roman Pichler, 8th September 2010
Photo courtesy of Rawpixel and Unsplash

It’s not uncommon for me to visit a new client and discover that the agile development teams frequently change, sometimes after every single sprint. Changing the team composition too frequently is undesirable though. Teams need stability to flourish and realise their full potential. This post provides practical tips to help you create stable agile teams.


Get the Right People on Board

Carefully consider who should be on the Scrum development team. Having the right individuals on board is probably the biggest success factor for any development effort–no matter which process is used. Determine the necessary hard and soft skills required. If in doubt, work with the Scrum Master and other people from development.

Don’t forget that an agile development team is cross-functional and typically includes individuals with UX / UI design, architecture, programming, and testing skills, as well as additional capabilities that are required to create or extend a product–like database administration and configuration management–as the following picture shows.

Sample Agile Development Team

I find it helpful when people can decide if they want to work on a product and be part of a specific agile team. This makes it more likely that the team members are motivated and take ownership of their work.


Minimise Changes to the Team

Once you have the right people on board, minimise any changes to the development team within and across major releases. It takes time for a group of individuals to become a true team–a tightly knit unit with members that trust and support each other and that work together well, as the following picture illustrates. Forming, Storming, Norming, Performing

The picture above shows Tuckman’s team building model. According to the model, people in a newly formed team have to get to know each other (forming) and rub shoulders (storming) before they can establish common ways of working (norming) and finally become a productive team (performing).

Changing the team composition makes the this process start all over again. As a result, productivity and self-organisation suffer. If you change a team too often, it may never reach the performing stage and fulfil its true potential.

You should therefore carefully manage changes to the development team. A good time for people to leave and new individuals to join is after the release of a new product version. The majority of the team members, however, should continue to work on the product in order to avoid loss of information, defects, and delays.


Align Teams and Products

Last but not least, align development teams and products. Every product should be developed by one or more dedicated teams, as the picture below shows. This does not only facilitate ownership and learning, but it simplifies the allocation of people and resources. Independent Product Teams: Each Development Team Owns its Product

Summary
Article Name
Stable Agile Teams
Description
Learn why stable Scrum teams are important to create successful product sand what it takes to create them in your organisation.
Author
Pichler Consulting Limited

Learn More

You can learn more about effectively working with agile teams with the following:

Source: https://www.romanpichler.com/blog/stable-teams/


5 comments on “Stable Agile Teams

  1. Joan

    What about development team members opting out of the team? what’s the best way to identify the real reason? surveys and one-on-one coaching hasn’t really worked.. team is only in sprint 7 and lost 3 people already. they move to different roles within the org

    • Roman Pichler

      Hi Joan,

      Thank you for sharing your question. While it’s normal for some team members to move on after a while, a premature exit of several people indicates that there may be an issue that you should address. I recommend talking to the individuals one-on-one. I would also investigate team moral in the next sprint retrospective, and look at how the remaining team members feel about the loss of their teammates. Once you understand the root causes, try to address them. Your Scrum Master should lead the effort to understand why people have left and what can be done to improve the team members’ job satisfaction and decrease fluctuation.

      Does this help?

  2. Howard Jones

    Hello, Our organization is creating stable development teams with the expectation that the team could take on a variety of different products and projects, depending on the latest enterprise priorities. What thoughts do you have about how to apply the PO role, move PO’s in and out of the team with the projects or keep them stable also?

    • Roman Pichler

      Thanks for sharing your question Howard. I prefer to organise teams around products or features so that a team works on one product or one or more features for an extended period of time. Working on different products usually leads to waste–it takes time to get your head round a new design, code base, test cases–or it leads to the creation of sub teams, which reduces synergy and productivity. The only exception I would make are bespoke products, solutions that are developed for a specific client. If you work for an agency, then it may be better that a product owner and team look after a set of clients within a specific vertical rather than one product. Hope this helps!

  3. Nina Rosa Madeira

    Great article. Thanks for sharing.

Leave a Reply

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


RSS Feed

Tags related to this post: