This, the fourth and final article in a four part series on Small Teams[1] and SCM, deals with what happens when large teams shrink to the extent that they can now be considered small. There are several situations where this commonly happens – 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.

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:

1. Do the licenses expire?
2. Is there any support if the support contract is not renewed?
3. Is it worth trying to transition to a FOSS CM tool chain?
4. How much administrative overhead is involved in keeping things running with a reduced head count?
5. 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?
6. Is this a terminal condition, or just a temporary one and personnel will be rehired?
7. 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 licenses expire if not renewed? Is so, is the vendor willing to collapse existing licenses and apply the pro-rated return to extending the needed licenses that remain. Irrespective to the answer to the last question, how long do you have to find alternatives and migrate the repositories to them?
• If the current licenses do not expire, but support and upgrades do, pull all of the upgrades as they become available even if you do not have time to apply them. Then you can continue using the tools until they they no longer work within the existing environment (such as being tied to specific systems, requiring specific operating systems levels, etc.). At some point in the future, assuming the organization survives, it will still be necessary to either restore support or change to some other tools and form a new tool chain.
• Are there conditions where license restrictions, such as moving to another server, able to be relaxed by the vendor, even if support has officially expired? If so, try to get written commitment from the vendor now while there is still the luxury of time.

Administration and Support
One of costs associated with all tool chains is the overhead involved in using, administrating and maintaining them. There is also the consideration of how much custom infrastructure has been built around the tools themselves. This, too, forms a part of the tool chain.

On large teams there is a need for extra overhead and extra control in order to maintain communication – especially to allow knowledge to be transferred to the future. This is because the normal turnover rate in large teams may be the same as for small teams, the absolute numbers is larger and information must be organized so that it can survive this. This means that as a team size decreases, this additional overhead will cease to serve a valid purpose (one of the reasons agile teams can be so... agile). This also means that it may be necessary to relax some of the controls and/or dismantle some of this infrastructure to keep the development effort productive.

Converting Tool Chains
There are two ways a tool chain can be converted, one is to use new tools and the other is to change the infrastructure that configures and integrates the tools. In this case, the primary reasons to change the core tools themselves are to save support and license costs, or to save on the time spent administrating them. Regardless, the most likely end result is the same – a transition to FOSS tools.

There are several good articles in past editions of CM Journal on how to select new tools, but in most cases it boils down to finding ones that will meet the actual requirements and this case they also include minimal setup, conversion, administration and integration costs. At this point everyone is generally asking for specifics, so for once I am going to break with tradition and give some. There are many others available than what I am about to recommend, but these are the ones have used and the ones I have had recommended to me.

• Version Control – Subversion, git or Mecurial
• Defect, Issue and Enhancement Tracking – Bugzilla or JIRA (though it is COTS, it is fairly reasonable in terms of initial and maintenance costs)
• Agile Tools – ScrumWorks Basic (the Pro version supports integration, but at a cost), PPTS (Bugzilla), GreenHopper (JIRA, though it is also COTS it is by the makers of JIRA and is fairly reasonable in terms of initial and maintenance costs)
• Build Management – CruiseControl, Hudson

Full Repository Conversion
It is always best to do a full repository conversion whenever possible. If you are doing an archival it is strongly recommended. The problems will come up when there is not a one-to-one mapping between either the (meta)data maintained, or the implementation of core concepts is so different it is hard to map them. Each of the tool sets listed above have repositories that must be migrated, but for the purposes of this article some of the problems in migrating Version Control repositories will be addressed.

There are core concepts such as branching vs. streams, promotion vs. tags vs. snapshots, unique name spaces vs. unique object identifiers, and whether or not directory structures are versioned that have to be addressed. It generally the case that during a downsizing it will be a conversion from a more complex tool to a simpler one. To do that, try to do a logical decomposition of the individual versions of each object. You need to determine if there is a way to even map them to a simpler tool before you lock yourself into that new tool. In the refactoring + branching example below you can see some of the problems.

Unless both tools are able to uniquely identify each of the objects, regardless of their names and locations, it will not be possible to keep track of their movements, name changes, content merges, etc. It is also important to keep the timing of the individual changes (revisions) of each object, so it is not normally possible to simply populate each branch in turn. In other words, the transaction history of the repository must be reproduced or data may be lost. Depending on how large a repository is and how many transactions have occurred, it may take days or weeks to do the brunt of the work, always knowing that there will be a last minute “catch up” just prior to cut over.

“Tip” Repository Conversion
If it is not necessary to keep the past history going forward (and this is especially the case where one is not trying to comply with CMMI levels 4 or above, perform trend analysis, or need many past releases for other purposes), then just keeping the active branches/streams and the tip revisions of all active objects on them is an option. In the figure above, consider (4) and (5) represent current active branch/stream tips. In older generation Version Control tools, it would be enough to just create the branches and check in the tip revisions for each of the files. Later generation tools know that a more transaction-based ordering needs to be performed, though it does not necessarily need to be the same order as originally occurred. For the steps below, (1), (2), (3) and (5) can be considered to be on branch Main and (4) is on branch Branch. Note that superscripts indicate name and/or location changes and subscripts indicate revisions (content changes independent of name or location changes).

Main: Dir_1 and Dir_2 created
Main: Dir_1/File_A₂, Dir_1/File_B₁ and Dir_1/File_C₁ created
--- Branch created  ---
Main: Dir_1/File_B₁ modified, moved to Dir_2 and renamed to B¹₂
Main: Dir_2/File_C₁ modified
Branch: Dir_1/File_A₂, modified, moved to Dir_2 and renamed to A¹₃
Branch: Dir_2/File_C₂ modified to File_C₃
--- Merge started ---
Main Dir_1/File_A₂ merged with Branch Dir_2/File_A¹₃ and renamed to form Main Dir_2/File_A²₄
Main Dir_2/B1₂ modified
Main Dir_2/File_C₂ merged with Branch Dir_2/File_C₃
Main Dir_1/File_D₁ created

Again, tools other than Version Control will have their own problems to be solved, but I hope this example will give some indication as to the level of thought that needs to be given to even “tip” conversions.

Archival
Archival is necessary when either a product has been canceled, or it is necessary to create an escrow of the codebase for legal, regulatory or financial purposes. The main concern is that whatever is archived is retrieval at any future time. This means that extra care needs to be taken to ensure that tool chain obsolescence, including hosting operating systems and hardware, do not affect the ability to retrieve the archived artifacts in a usable form. It may be sufficient to just make Version Control snapshots of each active or support required branch/tip and to generate exhaustive reports and database dumps for all other tools.

One other step needs to be taken – preserve the captured data on media that will not degrade easily. In other words, do not use magnetic media.

Conclusion
One word of warning to Management – during a downsizing it is not uncommon for those who can to find alternate positions early on and not wait to be laid off. If the organization in in a terminal condition, but wishes to archive its current product codebase and intellectual property, it may well be worth paying a bonus to retain those in CM who are able to do the archival. If the organization is not in a terminal condition, then be sure you retain enough people who truly understand CM and the tool chains to keep things running properly. Failure to do this will not result in any immediate problems, but it will be increasingly costly as time passes. This is not a self-serving warning; this is based on years of consulting experience where I was brought in specifically for archival and post-downsizing situations.

References

1. Small Team Essentials: An SCM Perspective (http://www.cmcrossroads.com/cm-journal-articles/12009-small-team-essentials-an-scm-perspective), previously published in the July, 2008 CM Journal.
2. Small Teams and SCM: Small Standalone Teams (http://www.cmcrossroads.com/cm-journal-articles/13077-small-teams-and-scm), previously published in the November, 2009 CM Journal.
3. Small Teams and SCM: Small Teams In a Large Organization (http://www.cmcrossroads.com/cm-journal-articles/13191-small-teams-in-a-large-organization), previously published in the January, 2010 CM Journal.
4. Small Teams and SCM: When Small Teams Grow (http://www.cmcrossroads.com/cm-journal-articles/13493-when-small-teams-grow), previously published in the May, 2010 CM Journal.

[1] We will continue using our definition of a Small Team – 1-10 people, with 3-7 being the norm.

Trackback(0)

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Ryan Pfleger said:

	... Nice Article
	report abuse vote down vote up

December 03, 2010
Votes: +0

Write comment