Photo courtesy of Rawpixel and Unsplash

Stable Agile Teams

Published on 8th September 2010 2 min read

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

Learn More

Post a Comment or Ask a Question


  • Purnima says:

    Nice article. How do you see changing SM after every major release?

    • Thanks for sharing your feedback and question Purnima. Generally speaking, I don’t recommend changing the Scrum Master after every major release. I find it helpful when all members of a Scrum team, product owner, dev team members, and Scrum Master, can work together on a continued basis. This facilitates greater group cohesion and shared knowledge; it makes working together more enjoyable and productive. Hope this helps!

  • Tobias says:

    Hi Roman,

    thanks for the article. In the last section, you underline (literally) that teams should be aligned with products. Is that meant in comparison to “no alignment”, or is that meant in comparison to all other alignment principles? Specifically, we are currently discussing whether it would be a good idea to align our teams along customer groups (given that customer-focus is important in agile), but I couldn’t find much on that so far.

    • Hi Tobias,

      Thank you for sharing your question. My article assumes that you have successfully validated the need for a new or enhanced product and carried out the appropriate product discovery work (including the necessary market and user research). If that’s the case, then yes, I recommend that you organise around products. If, however, you offer bespoke products for specific clients, then it may be more helpful to have teams who severe a a customer group (vertical or domain like travel, publishing, and finance).

      Does this help?

  • Joan says:

    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

    • 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?

  • Howard Jones says:

    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?

    • 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!

  • Nina Rosa Madeira says:

    Great article. Thanks for sharing.

2 Trackbacks

    Warning: call_user_func() expects parameter 1 to be a valid callback, function 'blankslate_custom_pings' not found or invalid function name in /nas/content/live/romanpichler/wp-includes/class-walker-comment.php on line 179

Leave a Reply

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