Ben Weatherall addresses what happens when large teams shrink to the extent that they are considered small. There are several situations where this commonly happens—for example, when a team has been raided by other teams, when the majority of the work has been accomplished and a large team is no longer needed, or when the corporate situation is such that downsizing occurs.
This is the fourth and final article of a four-part series on Small Teams and SCM that addresses what happens when large teams shrink to the extent that they are considered small. There are several situations where this commonly happens—for example, when a team has been raided by other teams, when the majority of the work has been accomplished and a large team is no longer needed, or when the corporate situation is such that downsizing occurs.
The raided team
When a large team has been raided by one or more other teams within an organization, the infrastructure remains intact but there is a problem with the amount of overhead that remains. In large teams there is a need for additional documentation just to facilitate communications and “team memory.” As a team shrinks, the need for this extra documentation also drops. The need for more formalized structured planning is also reduced. This may cause both joy and consternation as what is physically required (versus contractually required) is reduced, but with everything in place it is hard to just stop doing “business as usual.”
The good news is that the core CM infrastructure can remain in place. This core consists of Version Control, Defect Tracking, Build Management and Release Management. Other things such as heavy duty workflow management and project planning may now be too much unneeded overhead and can either be reduced or alternatives found that do not take as much time to use.
The work is done
When the majority of the work is done on a product either team members will be reassigned to other teams or they will be let go. In the first case, the team will devolve into the same condition as a raided team. In the second case, what happens depends on how large the development side of the organization is. If it is large, then the CM infrastructure will most likely remain in place and again, this will devolve into the same condition as a raided team. If this is not the case, then it behaves like a downsizing.
The problem with downsizing from a CM perspective is that it may not be feasible to maintain the same CM tool chain – especially if it is commercial software. When this happens, there are several things to look at:
- Do the licenses expire?
- Is there any support if the support contract is not renewed?
- Is it worth trying to transition to a FOSS CM tool chain?
- How much administrative overhead is involved in keeping things running with a reduced head count?
- Is there so much infrastructure built around the actual tools in the CM tool chain that it will be unmaintainable with a reduced CM head count?
- Is this a terminal condition, or just a temporary one and personnel will be rehired?
- If it is terminal, what should be done with the repositories and any intellectual property?
Even if you are already using a FOSS-based CM tool chain, several of the same questions are worth asking, especially numbers 4 – 7.
Assuming there will still be some development occurring, what you are trying to do is to scale back without painting yourself into a corner. Let's talk about COTS tool chains first. There are generally technological reasons that a COTS tool chain was put in place in the first place, though not always – sometimes the reasons are political in nature. Regardless, in a downsized environment it is probable that the funds for these tools will also be cut. Things to check with the vendors, if not already known, are:
- Do the current