How should development teams be organized? Reduce chatty interfaces.
In Lean Software Development Mary Poppendieck describes the seven wastes of production and their analogy in software development. Three of these are: Motion (software analogy: Finding information), Waiting (Waiting), and Transportation (Handoffs). I see these in many projects that I am involved in, or hear about.
One problem many organizations experience is a divergence of software developed by different teams. This is a serious problem, but many organisations choose the other extreme.
In some projects teams specialize in such ways that many component is maintained by a different team. Each delivered user goal (use case, user story, whatever) is realized by a number of teams responsible for different components of the solution. This involves communicating information between the teams, waiting for the other teams to finish their work, and handing off interfaces or code to different teams. In other words, it incurs waste.
Why is this bad?
- A delay from one of the teams will cause waiting for the other teams
- The software interfaces will risk becoming rigid and inefficient
- The administration effort of the coordination will be expensive
- A delay from on team will upset the project plans for the other teams
- Understanding of user goals have to be communicated to more people, potensially causing misunderstandings
- Testing and correcting defects will be harder, since all possible teams will need to be involved
In conclusion, ideally teams should be organised so that delivering one user goal will involve as few people as possible.