4

A business has five discrete streams of business requirements to be implemented in software. There is a team of ten developers.

A "naiive" organisational solution is to split the team into five "teams" of two (one per requirements stream). But I feel this compromises the integrity of the team (making teamwork more difficult, causing silo effects, making communication harder etc).

Has anyone any insight into how best organise a developer team like this to deliver against multiple requirement streams? Is it workable to have fewer development teams than there are requirements streams?

Improve this question

2 Answers 2

Reset to default
3

I would suggest two teams. 10 is really too many for a single team (too wide a knowledge spread will slow you down and a single team leader should not focus on 5 streams at once), but 5 on each should work comfortably and you can flex to 4:6 if pressures are heavy on one team.

You are absolutely correct that 5 teams is a naive view. If you lose even one person from a stream, you're in trouble; lose them both and you're going to struggle to survive.

It's fairly easy to have multiple streams going through one team. I would recommend a combination of Scrum and Kanban, but in the simplest case you just need a prioritised backlog of work and make it so that anyone on the team, on finishing one job, moves onto the next highest priority job, whatever the stream.

It's ok (in fact, inevitable) to have domain experts such that, if I pick up a job from stream 1 and I've zero knowledge of it, I can go to them for help. But it's important that I ultimately do the work and thus learn at least a little about all streams.

Code reviews also help spread that knowledge, as well as keeping your codebase at a high level of quality.

Improve this answer
2
  • This is exactly what I believe. It's comforting to hear an impartial voice with the same opinion.
    – 52d6c6af
    Aug 21, 2011 at 10:59
  • ...although I am eager to hear alternative opinions!
    – 52d6c6af
    Aug 21, 2011 at 11:12
0

IMHO, one way of team forming could be:

  1. Divide the developers such that each developer team don't get more than two concurrent projects (because more than that, dramatically decreases efficiency). For example, if you have 8 developers and 5 projects at hand, make 3 teams, 2 team with 3 developers each with 2 projects and one team with 2 developers with one project. Development won't need much coordination between teams if you really have different streams. However, if streams are much like each other, then as @pdf said, simply make two teams and divide projects between them.
  2. Designers and testers doesn't need to be dedicated to one specific team. You can make a working pipeline. For example, testers and designers could function in a cross-team manner, that is, they can be ordered to design or test, without belonging to any specific team.
Improve this answer
2
  • Point 2: That depends if you are delivering early and often or if developers work in an iterative way then throw a finished product over the wall to QA. If the former then QA should be part of the development team in every sense - location, standups, everything.
    – pdr
    Aug 21, 2011 at 13:04
  • @pdr, the problem is that 10 people (including developers, designers, testers, and project managers) are too few for 5 concurrent projects. Such a team may only have one designer or one tester. In that case, there is no work around it. :)
    – Saeed Neamati
    Aug 21, 2011 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.