Multiple products supported by small development team

Question

I manage a team with seven developers with more than ten products and 20 integrations between products. I took over the team a year ago, and we have worked hard to spread knowledge across the team. A year ago, every developer was basically a silo for several products and integrations, making us very vulnerable. This has improved much, and we are in a much better place today. This has been handled organically and ad hoc through co-developing and pair programming.

Recently, some developers have suggested a more structured approach to ensuring all our products and integrations are well known in the team. They want every developer to have a specific range of responsibilities regarding systems they can be asked to make changes to. So development in system X can only be done by developer x, y, or z - and not by the developer a, b, or c.

First I thought this was a great idea - everybody should not know everything. But giving it more thought, I can also see some downsides to this approach. It becomes significantly harder to plan sprints and make sure work is divided evenly with these restrictions. We could end in a situation where developers have nothing to do at the end of a sprint, whereas others are overburdened. This does not feel like a team taking responsibility for a sprint. Also, we can be forced to but less valuable work in the sprint to make sure there is work for everyone.

Are there any best practices or experiences you can share regarding having a flexible team without too much vulnerability? For example, is it realistic to ask developers to work in many products if there is an exact language and framework, common code practice, well-documented code, well-tested code, and good review processes? Or do we have to assign certain developers to certain products?

Answer 1

Of course, scrum is just a framework that you can customize according to your needs, but as far as I experienced, it doesn't work for a team with multiple projects. For this kind of scenario, kanban is a better approach.

Besides, learning a project is learning a specific historical era; it can not be achieved by only reading. A developer should read the code and the documentation, talk to the previous developers/business stakeholders, practice solving problems with some real issues. And this takes time. If you multiply this with multiple products and keep the turnover rate of the developers, you will see that it will not be feasible to achieve what you have in mind.

What I would recommend could be preparing a runbook for each project and doing pair programming sessions with a navigator & driver model and try to achieve to have at least 2 developers mastering a product and optionally others to know at an introductory level which at least help them to build and debug it. Here's my article about this approach.

Answer 2

It seems like you and the team's efforts over the past year have broken down knowledge silos (via co-development and pair programming). If so, developers have T-shaped expertise; broad understanding of most products/integrations and deep historical expertise associated with a specific product as well as their technical skillset. If moving forward, I would follow a phased responsibility group approach:

Community rules: The definitions associated with each responsibility group would need to be communally defined. They should not be too narrow so that responsibility would rarely align with a DEV member at time of Sprint (think OR's not AND's). Initial ideas are either languages/frameworks, historical expertise with specific products, or process roles (e.g. Quality Assurance), however you and the team know best. The definition of the responsibility groups as well as DEV team self-assignment should be documented and available in a team accessible location.

Code review: A person within the responsibility group reviews pull request before merger. This comes into effect regardless of whether the person/pair is within the responsibility group. Especially when code is submitted by a person within the responsibility group, review by another person within the responsibility group ensures that technical expertise is distributed (peer-to-peer learning on technical area).

If the team is enjoying the process of contributing within their expertise area (responsibility groups), all DEV members are contributing to the code reviews in a balanced manner (if not review responsibility groups), and they still want to take it a step further then I would introduce an experimentation timeframe and capacity planning trump card.

Experimentation timeframe: This is an experiment with an end date, not a forever process change. The experiment duration should be long enough to see whether the process change of capacity allocation based on responsibility group has the positive impact the team is looking for (improve workplace joy due to skill fit/reduce risk of burnout, increase velocity, etc.). A pre-defined end date provides an opportunity for reflection and decision point (continue or stop). If the team agrees upfront on success metrics this makes review much smoother.

Capacity planning trump card: If code review is occurring in a balanced manner, then generally capacity planning across sprints should also work out. At sprint planning, emphasis would be on aligning with the community rules. However, if capacity (in concordance with responsibility group allocation) does not match sprint workload, then sprint completion trumps responsibility group assignments. Under capacity team members, according to responsibility groups, fill the gaps. Sprint to sprint, the same DEV members should not be forced out of their responsibility group. If so, the community rules need to be reviewed.

Answer 3

I don’t think Kanban is the real solution. I have used Kanban for production issues and scrum for standard development.

So basically, the question is making a team A and team B and splitting the responsibilities across, the answer really lies around the complexity of the products and amount of work these generate. Cross training is very good but there is always a limit and you as a manager being best aware of situation have to do a judgment call or some AB testing. Changes and variations do avoid burnouts in my experience.

You could also ask questions like being under resource? Or maybe the products outdated and time to replace or rebuild?

I wish I had the silver bullet I could suggest but really it’s down to you and your team at the end, so my advice is avoid burnouts, change and embrace the change, think outside of the box, may be retire some product, do a team rotation like 3 months in team a and others 3 in team b, start some rebuilds so team stays motivated and learns new things , other could be hire additional developer remote are more cost effective.