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.
- 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!