How can a small team of devs maintain many products at the same time?

Question

I work as a software engineer in a team of 5 devs that develop and maintain 4 different projects

• I'm mainly responsible for 2 products:

  • a "trashware" product, and some part of a legacy system.
  • a synchronization solution that sync customers info with a tier-part CRM

• 1 dev and 1 intern work on a financial analysis app

• 1 dev and 1 intern work on HR app that measures accountants productivity

I'm kinda a tech lead & scrum master in the team, but not fully:

• I used to have some dev tasks in the other products. But now I'm more focused on my old ones.

• I help the other devs to take technical decisions. But they can also make their own decisions if they decide so.

• I'm not necessarily involved in all discussions, the product owner (CEO) can directly contact a dev and give him a task or clarify issues.

• The dev can contact a designer to discuss UI and UX.

• I do sprint planning with each sub-team, but sometimes I ask devs to clarify some specs to me. Recently, I ask my colleagues to do sprint planning without me because I have a lot of work in my main products.

• I feel a bit confused because they know details better than me.

• I'm also responsible for presenting and talking about products development states in the management meetings (the CEO can't play this role in these meetings).

I'm the only dev who can work on the 4 products. Other devs work exclusively in one product. They don't know about the other products (especially mines).

Our organization is very flat, it encourages empowerment, and we have a dozen of products (as a service). We don't have real managers i.e only Chief roles, devs, and help desk

It looks like SCRUM doesn't feet our needs, and we are more agile than it ??

I think my team works on many projects at the same time, and recently we don't do code review that much.

Should I ask the manager to alternate and work only on two products instead of 4 during a sprint or a release?

Should we split the team into 3 and redefine responsibilities and roles?

Is there other solutions?

Answer 1

If you have teams that work on one project only, then you could keep them on Scrum iterations. If they can plan things out and do the work without depending too much on external resources (I'm thinking "you" here), then great, let them do so. From what I gather from your question, it seems that this is not the main issue, but the fact that you are a shared resource, with your own projects, and with responsibilities in management meetings.

If you are split into doing your work in four directions, "you" can't really use Scrum.

• You could do as you say. Continue to use Scrum and redefine roles and responsibilities, and reorganizing teams, basically trying to create separate teams for each product, with you taking a "higher" position as a role of manager/consultant/support or watever fits the bill for the support work that you do, or...
• you let the other teams do Scrum on their projects, while for the two projects you handle + extra support, "you" switch to Kanban. This will enable you to visualize better what's happening with everything, get more insight and knowledge, and then be able to make better informed decisions.

Scrum might be the solution, or it might not (e.g. doing Scrum with teams of only two people might be a little bit heavy on the process side, while at the same time too light on all the necessary skills needing to be present in each team without the need for them to ask others for help and support).

Whatever you decide to do, you need to analyze the entire situation and see where the pain points are, and only then decide what to do: keep doing Scrum in all teams, reorganize teams, reorganize roles, use Kanban in all teams, use both Kanban and Scrum, etc.

Answer 2

Should I ask the manager to alternate and work only on two products instead of 4 during a sprint or a release? Yes, is the short answer.

Handling many products at the same time, as a shared resource, is always going to be tricky, regardless of what way of working you apply (e.g. in this case, Scrum).

It sounds like some better visualisation of the large amount of things going on may help you to work out if a re-org is needed, or how to differently manage time. This can be done using a Kanban approach, or whatever information-radiator style suits you.

Depending on how strictly the teams are using Scrum, in theory they shouldn't be working on multiple products anyway, as Scrum isn't built for conflicting priorities in that way - instead, they should be working off one backlog which should be focussed on one product, and each sprint have a goal, etcetc. If they are, a way to organise time is to allocate X amount of stories / story points per product.

The biggest problem with working on multiple things at once is the cost of context switching. Reducing down to working on 2, rather than 4, products will help to reduce that lost time, effort and energy - as you're only having to split between thinking about 2 things than 4!

Reducing down can also help to create a WiP (Work in progress) limit. Often, when there's loads going on, it can be more helpful to slow down and take things on 1 at a time rather than have multiple spinning plates, as then you can focus, knuckle down and get through the work.

Should we split the team into 3 and redefine responsibilities and roles?

It sounds like this would be really useful for both you in you role and also your team members. It will help take some of the things off of your plate so you don't feel like you have to keep checking in, and also empower others to make their own decisions without leaning on you so heavily. There's a lot of resource online for some simple R+R sessions, check out this one or drop me a DM and I can share an easy to use template for you.

Is there other solutions?

I'm wondering if a wider re-org needs to be discussed? As well as R+R from a higher level? e.g. asking the CEO to back off and let the team crack on with their work without being inturrupted. It's hard to focus and get anything done if the boss is always interjecting with "do this next/now/instead"

Depending on how large you are, flat hierarchies can create collaboration and break down barriers, or they can contribute towards anarchy. So if you're a growing org, it might be worth considering implementing some stepping stones. Not to create an "approval must be granted" culture, but to help define R+Rs so you can all focus on your work. It is possible to have both a hierarchy and a super open, honest, collaborative culture, too!

Hope that's helpful!

R-L.