Recommended framework to organize a 12-developers team that will work on different products

Question

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?

Answer 1

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.

Answer 2

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.