This, the second in a four part series on small teams and SCM, deals with small teams within a larger organization. There are two categories where this applies – where small teams are the norm and where they are the exception – and both will be covered here.
What is a Small Team within the Framework of a Large Organization?
We will continue to use the practical definition of a Small Team - one consisting of one to ten people, with three to seven being the norm. A large organization, for purposes of this series, is one that is large enough to support multiple independent and/or interdependent Small Teams and have a centrally controlled and administered Development/CM/QA/QC infrastructure. Whether this infrastructure is under the control of IT, CM, Quality or Development makes no difference for the purposes of this article. The key here is not the number of teams, but rather that there is a support organization available to them and that the SCM tools, processes, etc. are managed by them.
What are some of the advantages and disadvantages of Small Teams in this environment? Let's look at the two extremes mentioned above.
When Small Independent Teams are the Exception
In addition to most of the advantages listed last month, there are some additional ones gained by being a part of a larger organization:
- There is generally a support group available as an “emergency” resource – the other teams.
- Unlike Small Teams in small organizations, team members are not locked into a single team forever. The opportunity exists to move from one team to another, either for personal growth or to share skills and expertise.
- There is a support organization that manages the tools, repositories, etc. so this work is removed from what the team has to do, thus increasing productivity.
- Cross-team training is possible using informal reviews and other techniques that can benefit both the “host” team and the participating “guest” team members, as well as improving the overall quality of the resulting code.
- There may be enough resources available to be able to have defects found in existing releases be repaired by a “support team” that is adjunct to the main development team.
- While the concept “code ownership” still exists, the presence of other teams that hopefully have at least an idea of what is going on, means that if something happens to a developer, the team has an easier time replacing them and thus reduces the chance of project failure.
- If the team fails to deliver a product or complete a project, the neither the product nor the organization automatically fails. A large organization has the potential to field another team that may be able to resurrect/complete it or to potentially absorb the cost of the failure.
- If the small team is an exception to business as usual, it may be held to the same constraints and overhead as larger teams are – to the detriment of the project as a whole. This is alluded to in several of the other points below, but it is worth stating on its own. Large Organizations that have already successfully developed products tend to use the same “formula” in subsequent development efforts. In the case of transitioning to Agile development, this often means too much management and too much formalism.
- Since tools, repositories, etc. are managed external to the team, each team has less of an opportunity to select and use “non-conforming” tools.
- Large Organizations tend to be structured in hierarchies and to have an ever increasing number of managers. This means that there is a tendency to