Small team with diverse tasks and little overlap - which methodology?

Question

I have a small development team working on a variety of areas. Currently we are working in an interesting half-baked variation of Agile SCRUM, but that doesn't seem to make much sense in some respects.

All developers work exclusively from home, which is nice but makes "team" spirit challenging to build.

The team:

• Back end developer - C# - Back end optimizations, APIs
• Back end developer - C# - Back office development for finance
• Front end developer - Angular - Website 1
• Full stack developer - Angular mostly - Website 2
• Support person - SQL + general sw issue resolution - First point of contact for everything
• Business analyst - Project 2
• Product owner - Websites 1 & 2

Though the two C# back end developers could understand each other's tasks, they are lone wolfs by nature and custom, and their tasks are well defined and separate. I'm working to make them interchangeable (but that is a separate management task for me).

The two (later hiring one more to make it 3) Angular developers started to work together on my request, they are becoming interchangeable.

We currently have 4 separate SCRUM sprints, one for each developer, which looks very stupid to me. On the other hand, having 1 sprint might be stupid too, as the two back end developers have <10% tasks where they need to collaborate with someone (front end usually, not each other).

What agile methodologies can you recommend for such teams? I want to stay agile, we need to react to business needs; however some key partners are very hard to work with, hence the need for a BA.

What I looked at:

• SCRUM - some things just don't work in a small team with separate tasks, e.g. how do you do SP Poker when literally only 1 guy understands a whole area? Team velocity for 1 man? etc.
• Kanban - I would miss the sprints and the focus protection they provide
• Scrunban - promising, but I'm not sure if it is a gimmick or real, or if I'm better off just coming up with our own framework
• eXtreme Programming - looks good, but I sense this is more like just a mindset than a proper framework - e.g. we'd still end up using a Kanban board, no? Much like LEAN, there is no "XP board" and "XP events"
• our own version of agile - sounds good, but a bit arrogant - so many knowledge and experience available, why couldn't we just learn from someone else's mistakes?

Also, would you force everyone into one framework, since there is ~10% work when they need each other? And it might be useful in building the team. But it might seem like a waste of time for the two lone C# devs.

UPDATE - context for clarity

We have one product, with heavy backend calculations, two websites (one for everyday customers, one for contracted partners using our APIs - the two frontend developers work on these). One C# developer is working on creating a new back office to be used by our own Finance and Support teams. The other C# guy is developing and maintaining the APIs, and is optimizing the current backend calculations. His work can affect others, as he is touching the foundations of our software.

Our current setup means we have 4 separate SCRUM teams, each with one developer. I see issues with this:

• 1 man is not a team
• Cannot do story point poker; now the devs just estimate a dev time for themselves
• If a developer falls ill, the sprint crumbles. In a proper SCRUM team, if one man cannot finish for any reason, others help out. To me this is one of the main points of SCRUM - we talk about team performance, team expectations etc., not individuals.
• How do you have a sprint review, when 1 sprint = 1 developer?
• Basically we have sprints on paper, but we just have one big continuous flow of tasks that individual developers freely move around if ad-hoc tasks fall in. Which is OK actually in our case, but then why bother with sprint commitments? Why bother with sprints?

As for the AB (XY) problem: I have a few issues, yes. I need to eliminate the huge risk that comes from a lot of knowledge existing exclusively in the head of single developers. I would like to have development standards. I would like for the devs to learn from each other and cooperate more. But these are not the issues I'm asking about here. I have a practical issue of organizing and documenting the development work. The current way has a lot of overhead, a lot of pointless exercises, which leads to developers neglecting them, understandably.

The work we do needs to be more transparent, the priorities need to be clearer. I want to organize our work in a way that makes sense and helps our developers, and doesn't seem like a pointless burden.

But maybe I'm just overthinking this, and if it sort of works, don't fix it?

Thank you for the help and ideas!

Answer 1

Experiment.

Follow these steps:

• Clarify what you value - Is it team morale? Is it productivity? Is it rapidly responding to change? etc.
• Decide how best to measure the things you value
• Try elements of the various agile frameworks and see how they impact on your measures

Avoid anecdotal measurement of success ("this feels like it works well to me"). Instead, focus on concrete measurement of what works and what does not.

our own version of agile - sounds good, but a bit arrogant - so many knowledge and experience available, why couldn't we just learn from someone else's mistakes?

This is a legitimate concern, but really you are the experts in your own domain. You know the way the organisation works, how the team members think and what your products are like. You are best placed to make decisions on the approach to take.

It is definitely worth reading about agile and maybe also posting more focused questions here. But as long as you are using inspect-adapt to make changes to your approach you should do fine.

Answer 2

If the risk that you're trying to mitigate are the knowledge silos that exist in these individuals, then going with a single-team / single-product mindset would help mitigate that risk. Of course, there are trade-offs there - you'll have a slower rate of output as different people cross-train across the system and absences of people will still reduce the overall effectiveness of the team. However, the net gain would be that more people on the team can take on more work when needed.

It seems like you're fortunate in the tech stack being pretty consistent - a C# / .NET framework backend with an Angular frontend. This should allow the back-end developers to collaborate on their work and the front-end and full-stack developer to collaborate on the front-end work, at least initially. From there, you can have the back-end developers collaborate with the front-end developers to learn angular and your front-end developer start to learn C# and the .NET framework. Over time, you'd end up with 4 full-stack developers. They may have different areas of expertise or interests, but they'd be able to take on work from each other.

When it comes to organizing the work, you can order the work by value and consider dependencies. If you practice vertical slicing, the work will extend from your user interfaces through your back-end logic and into your data models, depending on the specific change. The team will have to work together to make the change.

The open questions are around timeboxing and cadences. If continuous flow works better for you, then you don't need to follow Scrum's cadence. Scrum fits all the replenishment and review cadences into a single cadence, but this doesn't necessarily work for all teams. Consider the 7 Kanban cadences. These are things that you're going to have to do, but you can figure out the cadence for each one that works for you. Some may end up being scheduled while others are more ad-hoc. That's up to the team to decide.