One dev team shared on multiple products

I had several thoughts as I read this, hope you don't mind the detail. :) 

Are there needs warranting continued efforts to add staff with the skillset of the current small team? If not properly staffed it's logical to understand the team wouldn't be as efficient as you'd like. Therefore, reacting with a re-org sounds premature in the event say 2-3 people are then hired in the quarter and you would need to recreate the teams again. You'd be making decisions that aren't centered around the benefits of the current people/system and potentially introduce more problems than just being understaffed.

Having stable teams and reducing context switching are two different things, both worth striving for. Your situation sounds like a scope issue; it's not a Dev Team issue but rather a PO issue where the word "no" isn't used often enough. You said you have an idea of what you want to get done in a year but with current team size, it's not achievable. So start with identifying what you think will get done in a year with current state and let the PO's exercise agile principle of "Simplicity is essential", and aggressively select the work you will not do.

The exploits should be working with each PO to maximize scope through available capacity and cutting out should do's from the must do's, while also exploiting the hiring process and increasing amount of candidates to review. While the teams grow to optimum size, the over commitment of deliverable scope will still exist. These are behavior-based results and it shouldn't be assumed this will fix itself if teams were properly staffed.

Your teams should be built to succeed via self-organizing and being cross-functional. It's not to say they couldn't switch between products, but really understand what success is because if this approach is used and each product achieves enough value to make external folk happy, the behavior of accepting unstable teams and context-switching will become the norm, and it's likely there will be continued staffing issues.

One of my fondest memories is working with a small, four person team. We broke some Scrum rules. I was both the Scrum Master and the Product Owner. The client representative was technical and hands-on and we had two Development Team members. Our four person team was so efficient that we were producing "Done" increments every few days. This is one of the reasons why to this day I am a proponent of small Scrum Teams.

My opinion is that when you switch Development Team members from one product to the next, you risk losing institutional knowledge and focus when they move. It's difficult to find skilled engineers with the right personality to work on a high-performing Scrum Team. But this is where you would talk to your leadership and HR and see if there is interest in keeping stability and continuing to search for the right staff. Not having the right staff is not an excuse to sacrifice Product quality.

I don't believe in Product "idle time" as you state. There is always room for improvement. If your Product Owner doesn't think there is, ask her/him when was the last time they checked-in with the client or end-user. 

My question now : Can we have a single development team (or max. 2 dev teams) switching from one product to the next regularly throughout the year or is it not recommended ?

There's no rule against a team from working on different products in different Sprints. As to whether it is recommended or not...what do you think the consequences would be, in your situation, for commitment and focus?

Maybe have them work 3 to 4 sprints on a product and then switch to the next.
Can we have products on "idle-time" for a period of time ? If there is no team assigned to a product, who is accountable for operationnal maintenance (i.e. : bug fixing, data quality, ...) ?

The agile manifesto advocates delivering working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. If a team worked 3 to 4 Sprints on a product and then switched to the next, would this allow each product to be serviced with that kind of frequency?

>>My question now : Can we have a single development team (or max. 2 dev teams) switching from one product to the next regularly throughout the year or is it not recommended ?

While there is no such rule, I would not recommend it. It may result in a confused state of mind for the team and will impact their productivity.

I could think of a couple of options:

Option 1 - Consider the 4 PBLs as larger Epics and order them in terms of priority. Let the teams focus and complete the Critical, High and Medium PBIs in an ascending order of the backlogs

Option 2 - Pick any 2 PBLs that are highest priority and split the teams into 2 scrum teams (instead of 4)

The idea is to have a laser focused view on the PBL.

I am sure you would have figured a way out by now. Pls share your ideas for any future reference.

Hi Everyone,

Thank you all for your advices.

Reading these, I feel like the general opinion is more "Better work with (too) small teams than have a well-sized team switching between products."

Indeed, having a team switch from one product to the next would not be ideal for maintaining focus.

And indeed, I agree that we must also re-think our recruitment process.

We will take these into account.

Cheers,