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
Advantages
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.
Disadvantages
- 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 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
Advantages
- 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.
Disadvantages
- 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 or COTS tools should be used. If possible, the same tools used for any larger teams should be leveraged, but this may not be practical. It may be sufficient to use tools such as Bugzilla or JIRA, but there could also be integrated DIET capability in the VC tools used. Since the DIET system will generally be used to generate metrics for both intra-team use and for comparison with other teams, the tool or tools will need to be capable of generating the required numbers and charts with little or no human intervention. If more than one of these tools are used, then it will be necessary to come up with a way of generating common metrics and charts, even if data analysis must external to the tools must be performed – and it will be up to the SCM group to make sure it is available and its use is “transparent” to Development and Quality.
In a similar fashion, VC tools must be able to meet the needs of both small and large teams. It is more important that the number of VC tools in use be kept to a minimum as they are typically configured to restrict undesirable behavior in addition to the normal task of versioning software changes. The same list of requirements as in the last article are applicable with the addition that they should be low overhead. Some VC tools initially acquired by Large Organizations for use with large teams and/or long duration projects often have a performance overhead that is unacceptable to small teams, especially if they are practicing any of the Agile methodologies.
Since Large Organizations typically do not object to paying for seat- or enterprise-licensing, COTS tools, with their inherent vendor support, are often selected. Tools such as AccuRev, ClearCase, CM+, Dimensions or Perforce are often selected as a part of a “solution package” by Management and can be tweaked to support multiple development methodologies. There are also FOSS tools such as subversion and git that can be used, but make sure the cost of dual maintenance and user training are acceptable.
If at all possible, use a “centralized” Build Management tool such as AnthillPro, BuildForge, CruiseControl, ElectricCloud or Hudson. If one is already present, use it. If not, the need to capture “how to build artifacts” knowledge for multiple teams, whether they be small ones or not, becomes essential. It is not uncommon that a small team will “finish” a product's development and then be reassigned to other teams or leave the organization. At some point it will be necessary to “update” the product and it will be difficult, if not impossible, to determine after the fact how to (re)build the product. Using a tool such as one of those listed above will allow both the process and the tool chains to be captured and resurrected as necessary.
Again, for all of these tools, the idea is to set up something that is low maintenance, integrates with other development tools/IDEs being used and will remain available throughout not only this product's development life, but others as well. There are other tools that can make small team development easier in the long run, tools that support Requirements Management, but for most small teams they are only worth it if they have a reasonable Return on Investment (ROI) in terms of either schedule, quality or competitive advantage.
Summary
In general, the need to tailor existing SCM tools should be kept to a minimum and the solutions be implemented is such a way as to be reused in the future. Additional SCM requirements for these teams over and above those already in place are generally modest. As always, the SCM tool chain(s) should be set up to be as self-administering and low maintenance as possible. Specialized integration between the SCM tools, project metrics, data mining, etc. should be kept to a minimum over what is already in place unless a new methodology is to be tried. Whenever considering new tools , integrations or customizations, ROI should be considered.
