- have more progress/status reporting to Management, often including “standardized” metrics, that are not required in smaller organizations.
- Large Organizations tend to mandate how code will be developed, which language or languages will be used (including which third-party components and libraries are allowable), etc. This often constrains small teams to trying to do the work of larger teams when it is not necessary.
- More external-facing documentation is generally required. This is not necessarily a bad thing if the time and skills are allocated to produce it.
- Releases tend to be more formalized with corporate support of both build tools and expertise. If done properly, this is a sort of zero-sum win for the team. They no longer have to build (and often deploy) production releases, but they now have to live with a more formalized build process. Often these production candidate are built using a different mechanism than developer builds, so it is possible for a problem to manifest itself in production that does not appear in the development environment.
- If the scope the small team signed up for increases to the point where they cannot deliver in a timely fashion (with the required level of quality), Larger Organizations have the option to “grow the team” into something more classical in nature (see the next article in this series: When Small Teams Grow ). Note that this could also be considered to be an advantage – at least from the perspective of the organization as whole.
When Small Independent Teams are Normal
- If small teams are business as usual, and if the Large Organization has prior successful experience with small teams, they probably will not be held to the same constraints and overhead as larger teams. As mentioned above, Large Organizations that have already successfully developed products tend to use the same “formula” in subsequent development efforts, but in this case it is an advantage since Management knows what works and what doesn't.
- The support infrastructure, up through and including the release process, should already have available a tailored model geared to small team development.
- Scope creep should be managed better as previous experience will have already determined the dangers to schedule, quality and customer expectations.
- If a new methodology, such as Agile, are tried for the first time, it is just as difficult for Management and the infrastructure support group to adjust to the needs a “different” small team. This may mean starting development before the tools are in place and configured to support this new methodology.
- If a small team is just “following in the footsteps” of previous small teams, then the list of disadvantages is small with one exception. If the earlier team(s) operated in an “heroic” mode, then the new teams may be expected to perform to the same level or be considered as failed.
SCM for the Small Team
In Large Organizations that have a history of fielding small independent teams, Project Management/Status Reporting, Version Control ( VC), Defect, Issue and Enhancement Tracking ( DIET) and Build Management ( BM) are areas that have already been addressed. Where this is not the case, SCM will need to be willing to step up and consider variants to the existing processes and maybe even add the support of new tools just to facilitate the needs of small team(s). Hopefully, the SCM group will be made aware early enough in the planning phase to have solutions ready before they are problems.
At this level, DIET can no longer be performed simply with 3x5 cards, a spread sheet or a simple shared document. Either FOSS