Comments on: Stable Agile Teams

By: Roman Pichler

Roman Pichler — Tue, 01 Mar 2022 08:28:03 +0000

In reply to Karsten 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!

By: Karsten Elsholz

Karsten Elsholz — Mon, 28 Feb 2022 18:22:38 +0000

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

By: Roman Pichler

Roman Pichler — Tue, 15 Jun 2021 08:10:26 +0000

In reply to Alicia. 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:

People are given a choice and can influence which product and team they want to join. Telling people to move to another team without at least consulting them is not consistent with the idea of motivated, self-organising teams in my mind.
The changes don't lead to a significant loss of knowledge and a larger drop in productivity. That is, they don't take place too frequently, and individual teams still retain the majority of their members.

Hope this helps!

By: Alicia

Alicia — Mon, 14 Jun 2021 20:14:17 +0000

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?

By: Roman Pichler

Roman Pichler — Mon, 16 Nov 2020 14:30:06 +0000

In reply to Firouzeh Manuchehri.

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!

By: Firouzeh Manuchehri

Firouzeh Manuchehri — Sun, 15 Nov 2020 15:52:32 +0000

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.

By: Roman Pichler

Roman Pichler — Fri, 17 May 2019 12:04:02 +0000

In reply to Purnima.

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!

By: Purnima

Purnima — Fri, 17 May 2019 11:12:09 +0000

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

By: Roman Pichler

Roman Pichler — Tue, 22 Jan 2019 08:31:48 +0000

In reply to Tobias.

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?

By: Tobias

Tobias — Mon, 21 Jan 2019 21:14:12 +0000

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.