The system being produced will tend to have a structure that mirrors the structure of the group that is producing it, whether or not this was intended. One should take advantage of this fact and then deliberately design the group structure so as to achieve the desired system structure. (Conway's Law)
If Conway's law does really apply, one of the most important things you should do is to build the right teams.
The first crucial question is about the size of the team. SCRUM suggest to build small teams with 5 +/-2 peoples. Amazon.com introduced the "Two pizzas rule" to build their software teams.
One may ask: Why should we build a small team, when a big team has some clear advantages:
- they can include members with more diverse skills, experiences and approaches
- they are not as much at risk to the loss of a key person
- they can provide more opportunities for individuals to specialize in a technology, or in a subset of the application.
These are really impressive properties of large teams, but what about the small ones? Here are some of the advantages of small teams:
- less social loafing
- more chance of constructive interaction
- nobody is going to fade in the background
- harmful over-specialization is less likely to occur
- less time is spent coordinating effort
Without discussing these properties in detail, just move along to the next problem:
The product/project you need to accomplish has a pretty small time budget, and its business domain is too complex to finish it with a small team.
The question is how to build small teams that cooperate on building a complex system?
By building the teams keep "Conway's Law" in mind. Either you build feature teams or component teams.
Feature teams are responsible for an end-to-end delivery of working (tested) features, whereas component teams works on some part of the system, such as on a persistency framework, on business layer or may build some GUI framework.
Organizing a multiteam project into feature teams have many advantages. Since the feature team delivers end-to-end functionality, its members working through all the layers of the architecture, which maximizes the learning about the architecture and design of the product. A feature team includes all skills needed to go from an idea to a running, tested feature and so it ensures that these individuals are communicate at a daily basis.
Component teams, are used to deliver software to another team on the project rather than directly to users. Take care that a component team only builds components as a feature team ask for them. Since in this case the feature team is a kind of product owner, they must prioritize and also review the work of the component team. Guessing about future requirements is dangerous, and might lead to develop unnecessary, or even worth, unusable components.
If you recognize that the team structures impeding the ability to use scrum, that issue should be raised during an end-of-sprint retrospective. You should prefer stable teams over a project, but do not stick on a structure if it does not work! Take care on personal conflicts too. Social issues might reduce the productivity of the team on the short and can lead to quitting of individuals on the long.
