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 usually 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 an agile 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 and ask your Scrum Master for help if you are unsure which capabilities will be needed.
Don’t forget that an agile development team is cross-functional and typically includes individuals with UX / UI design, architecture, programming, and testing skills. You may also required additional capabilities to create or extend a product, like database administration and configuration management. The following picture shows a sample agile development team.
A great technique to find the right individuals is self-selection: Let people decide if they want to be on the team or not. Consequently, the team members are likely to take full ownership of their work and be motivated to work together, which is a prerequisite for growing a great team and building a successful product.
Minimise Changes to the Team
Once the right people are on board, I find it helpful to minimise any changes to the development team. 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 productively, as the following picture illustrates. 
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 causes the this process to start all over again. As a result, productivity and self-organisation are likely to 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 and it can help minimise cross-team dependencies.
In the picture above, team A is responsible for designing, developing, and testing product A, and team B does the same for product B. Ideally, both teams have full control over their respective product and can test ideas and release new features independently of each other. Note that the organisation has to have a shared definition of what a product is in order to take full advantage of the approach shown in the picture above. To put it differently, if you are not clear what a product is, then you can’t organise around the assets in a consistent and helpful way.
Post a Comment or Ask a Question
15 Comments
Hello Roman,
you said “Every product should be developed by one or more dedicated teams”. I have a problem with the naming product. So, a product could many different expertise need from totally different topics. In our company the management has the aspiration that every developer in a team has at least the base knowledge to fulfill all the requested tasks to the team. But one dev-team (as in our case) could never handle the whole bandwidth of all upcoming tasks in the project backlog easily. The consequence is permanent new synchronization to the unknown topics. In former times we have had more dedicated teams managed by a leader for the faculty (no scrum teams) like hardware-related or remote control. These faculties cover several sub-thematic and the team was in a kind of t-sharp, i.e. at least one expert and more which know to follow easily. Today the construct of faculty team is destroyed. All developers are shuffled together placed in new teams which are changing regarding the upcoming projects. The teams are not stable and the knowledge is built only temporally because after these new topics overlay the just learned things and the team are not stable. Our management said, there is no other way to work but for us developer. That it is unsatisfying and very stressful. So, my question to you is: What do mean if you speak about a product? One developer team has to be so flexible to cover the whole bandwidth of requirements of a project? Or should get expertise in one direction to reach faster values of dedicated topics but not cover all upcoming tasks?
Thank you for response,
K.Elsholz
Hi Karsten,
Thanks for sharing your context and question. I state what I mean by product in my article What is a Digital Product? It sounds like you used to have a mixture of feature and component teams (also called stream-aligned and subsystem teams) in the past. This setup might still make sense when applying agile practices, see my article Are Feature Teams or Component Teams Right for Your Product?
Hope this helps!
Thank you for the article, this is a great read. We are working in an environment with several products and teams and at least once a year, management ‘shakes up’ our teams and moves people around for cross-training purposes. What is your opinion on that approach?
You’re welcome Alicia and thank you for sharing your question. It can be very useful to allow people to work on different teams and products in order to help them grow and develop and to spread knowledge and avoid bottlenecks, as long as the following two criteria are fulfilled:
Hope this helps!
I have enjoyed reading your articles. Your writing is concise and easy to understand. I would like to learn more about “self-organizing” teams and how they function and behave. Have you written about this topic or are there resources you could recommend? Thank you.
Hi Firouzeh, Thank you for your feedback. I am glad that you like my articles. I’ve written more about self-organising teams in the article “Empowering Development Teams.” Hope this helps!
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!
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?
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?
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!
Great article. Thanks for sharing.