The developers team is composed of 12 people. Several products need to be built, and although these products benefit the same line of business in the company, they are not necessarily related each other. There's a Team Lead with both tech and Scrum experience (he is not part of the 12)

Some products are more complex to deliver, and might require a larger number of people working on it, while others are too simple that could well be done with 2 developers. This means we can have a team of 2 developers, other with 4 and other with 6 during a given time, each of them working in a different product.

With the above example, maybe a 'scrum of scrums' approach would work, with 3 scrum teams, 3 POs etc. Based on your experience, what framework would give best results?

  • "Several products need to be built." Are these products to be released at the same time, or are they on different release schedules? Do they have any interdependencies between them?
    – John Wu
    Jan 13, 2021 at 22:25
  • @JohnWu different schedules and no dependency between them in the vast majority of cases.
    – David
    Jan 14, 2021 at 0:06

2 Answers 2


Before deciding on what to choose, be it Scrum, Kanban, XP, squads, tribes, guilds, clans and what not, it's worth mentioning that your eventual setup will depend a lot on the nature of the projects themselves and on the skills of the people you have.

  • You say projects aren't necessarily related to each other, but then you mention Scrum Of Scrums, which makes more sense when you have multiple teams working on the same product and they need to synchronize, coordinate and plan together. What are the characteristics of these projects? Are they independent? Part of the same product? Related but different products? All of them?
  • You then have 12 people and you mention 3 Scrum teams, with variable number of members. Do you have all the skills needed in each team? Or will someone have to be shared between the teams because they have some particular skill or knowledge?

I've seen this situation before and it feels like driving many cars on multiple lanes at different speeds, but then also having to reach certain points in the road at the same time, or changing the drivers of the cars while driving, and reaching the finish line with a different type of car than the one you started with. Not fun!

You will have issues with dependencies (be it for people skills or for software dependencies) which can turn into blockages or introduce delays if not managed properly. And it will make it also harder to plan if you use sprints, for example, because you need to plan many (possible unrelated things) each sprint, and if projects have different lifetimes you will inevitably change structures of the teams and which will impact predictability and people finding their pace so any estimates or plans you make might be impacted because your yesterday's weather changes all the time.

So my advice (before trying to make something from the above list of approaches fit into your teams, and possibly struggle with making it work for your particular situation), would be to do the analyze I mentioned above regarding the projects and the skills, lay out and visualize the current process you are using, then use principles from Kanban and Lean to keep progress on all lanes. Spend less time on estimating and planning sprints and instead, use daily meetings to get an understanding of priorities, figure out the order in which to do your activities, work on them until your next daily, when you regroup and repeat. This will cause people to naturally group themselves around the work that needs to be done and not necessarily work together because of the boundaries their team membership imposes on them.

This may look like a lack of structure until you figure out the best way to work, and it may certainly take a while until things start running smoothly, so you need management's support (or at least understanding) on this approach.

  • Thanks for answering! To answer your question, in the vast majority of cases these will be totally independent products. Think on customer A who wants a very simple website and customer B who wants a very complex one. Both are similar products, but they are totally unrelated. As for the skills, not all have the same skill, neither the same level of expertise, and all of them will just join the company in March.
    – David
    Jan 13, 2021 at 16:11

Look at this example: Thousands of programmers of Sberbank moved to new office Agile Home.

At Sberbank all the IT/business employees, related to product development for internal and external use are separated into tribes, each tribe fully owns its product concept, strategy of its development, documents and code.

They call this process sbergile.
(Russian resources here).

Why I suppose it is relevant in your case:

  • each team is focused on a particular product;
  • the level of responsibility within the team is equal regardless of the position;
  • the team is self-organizing
  • working product than detailed documentation spec (in accordance with one of four goals of Agile) - it's especially important for Developers (maintaining the balance between 'implementation freedom' and 'described functionality').

Looks like it can be handy, as you've mentioned that products are not tightly coupled. Also this example of transformation can be scalable to smaller teams as in your case.

  • I understand these small teams would be 'tribes'. Something important to note, however, is that some products (e.g. a PowerBI report) are expected to be completed within a 2-weeks sprint, and after that such tribe/team wouldn't exist anymore (maybe the same 2 devs will work on a new project, or they will be joined by other dev(s) to work on something else)
    – David
    Jan 13, 2021 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.