This, the third in a four part series on Small Teams[1] and SCM, deals with what happens when small teams grow to the extent that they can no longer be considered small. There are again two categories where this applies – where small teams continue working on the same product/project and where new teams are fielded to take on additional products/projects. I will not be considering the second of these due to space constraints. If there is enough interest, I can address it after the series is completed.

What Can Cause a Small Team to Grow?
Let us deal with the first category and assume that there is initially just one Small Team working on the product. The two most common reasons for growth are:

• The job has grown to the extent that the team can no longer complete the required work in the allowable time frame. If the required functionality is to be included, and assuming that there is no easy way to “work smarter,” the only two choices left are to cancel the project or grow the team.
• Market Opportunity may require an earlier delivery than was originally planned and there is no way to scale back the functionality that must be included enough to meet the new deadline.

So, growth being the preferred solution, there are choices to be made. Some of these are: Should there be multiple Small Teams, each working on a portion of the development, or should a Large Team be used instead? Should outsourcing be used, or should it all be done in-house? Will the current infrastructure support the growth?

Transitioning to Multiple Small Teams
This is something that most development methodologies, including Agile ones, support; but just because they support it does not mean that there is expertise in-house to do it properly. Hopefully the product is designed to be modular so that the teams can work separately without stepping on each other. The goal is to keep as much of the process, procedures, workflows, etc. that people are already experienced in, and add only the additional communications and management to keep things working well. And communications is the key. People need to be able to access the other teams' members as needed to coordinate development activities. Duplication of effort cannot be tolerated.

Of course, the first thing to do is to determine how many teams are actually needed and who should be on which one. If the original team was maxed out in terms of the number of people that could work effectively, then there can be a fair number of original members in each of up to three teams. Effectively, this allows seeding the new teams with experienced personnel who can hopefully mold the new team members into a cohesive whole fairly rapidly. Pick new personnel with personalities that will fit in with the existing people, but don't let this be of too much importance. With multiple teams, the cultural dynamics are going to have to change somewhat anyway. If the original team was fairly small to begin with (say 3 developers, 1 tester and 1 DBA/developer), splitting it up will mean new teams with no one from the original team in them. Even doubling to two teams will mean the tester will most likely end up on the new team and the DBA/developer will end up being a shared resource doing more DBA work than development. This in turn means that you will most likely be hiring 3 or 4 developers and at least 1 tester, then having to decide how to split them into the new teams. And if three or more teams are required, the situation becomes even worse – at least in the short term.

In both cases, the individual team dynamics will change. The way people communicated in the past will need to change. What people were “allowed” to work on will change. And people really don't like change. How to manage this change is not the concern of this article, but being aware of its impact on productivity is. Sort term, going from one team to two will probably result in no more than 30-50% more work being done – and part of that will have to be redone down the road. If the result is three or four teams, the percentage of usable work completed is probably no more than double what it would have been for one team. In both cases this will, this will eventually scale up to where it meets expectations, but not at first.

Impact on SCM
Branching and Merging
When one team is working on a product, branching is normally used only to isolate ongoing development from releases. Only occasionally will there be the need to have two active development branches at the same time. With multiple teams, however, it becomes imperative that a manageable branching strategy be put in place that will allow the teams to isolate their work from each other. The branching strategy should be chosen with merging and integration in mind. Remember that no matter how long it takes to create a branch or populate workspaces based on it, the time spent merging it “upstream” will be much longer. The more the codebase is pathological in nature[2] the more difficult merging and integration will be.

Note that I am keeping the concepts of merging and integration separate. One of the things that Agile methodologies tend to promote is continuous integration where, as features are complete they are merged “upstream” and at least regression tested. These changes can then flow back down to the other teams (when desired) so they are working on the continuously evolving codebase and do not get too out of date. This means there will be intermediate branches where the integration can occur and either be fixed or reverted back to the original branch, based on the tools in use.

Impact of Refactoring
This brings up the concept of refactoring. When elements are renamed, moved or otherwise munged, and when branching is in effect, it becomes essential that the Version Control (VC) tool being used can support merging under these conditions. When there is only one team working, refactoring is generally not as big a problem, but with multiple teams it can become a major pain.

Transitioning to a Large Team
So, what if the team is allowed to just grow instead of being split into multiple small teams? In this case, all of the original players are still present, so knowledge transfer is easier. Overall communications, however, is still severely impacted. People will be absent or perhaps even working remotely. Even if they are all co-located, there are too many to just meet in the hall and it is too expensive to have all of them idle at once for large meetings unless it is absolutely essential. So documentation will become a major part of the new communications strategy, and that includes email. One of the initial goals may be to keep everyone working on the same codebase, but it will soon be discovered that this keeps it in a state that is rarely buildable, much less testable.

Ironically, the tendency will be to have various individuals and small groups work on isolated parts of the requirements – effectively forming multiple ad hoc small teams without the infrastructure that makes Small Teams viable.

Impact on SCM
Branching and Merging
When one large team is working in conjunction, the hope is that the same branching strategy already in place for the original team can continue to be used. The codebase volatility resulting from the larger number of people will make it difficult to isolate individual change requests or features, so there will be no way to release without fixing everything. That, in turn, will mean that there will have to be “bug fix” periods prior to any demo or release candidate build just to get the codebase in a state that is not embarrassing to show outside of the development environment. Even if a Release branch is created and the fixes occur on it, they will have to be merged back into the parent codebase.

So, we are back to the same branching strategies as for multiple Small Teams, but without the discipline and standardized procedures. This can devolve into the “one-branch-per” scenario, where it can be per bug or per feature. Now you end up with having individuals working on multiple branches at the same time, and often checking the wrong code into a branch.

Continuous integration is possible, but only if the team is disciplined and careful. Maintaining a non-pathological codebase also becomes a challenge, so the build infrastructure will have to be robust enough and fine-grained enough to be able to support this model.

Impact of Refactoring
As was previously mentioned, when there is only one team working, refactoring is generally not a big problem – but this is true only for Small Teams. When you have a Large Team, the impact on individuals is greater since they will have to synchronize to the refactored codebase and then fix all of their own code to be compatible. If one has made changes to an element that has been refactored, it may not even be possible to merge the changes together. This is especially true when the refactoring includes splitting functions or classes from one element to form multiple new ones. Even the best VC tools will tend to try to merge only with the parent element, not the ones where the original code was split into.

Is Outsourcing a Viable Option?
One of the other options to creating additional in-house Small Teams is to outsource some or all of the work. This can be a viable option, but only if one of the following criteria are met:

• The outsourced work can be considered to be a Third Party component where, even if the source is controlled and built, it is essentially considered to be “released” to the parent organization from the outsource team.
• The outsourced work is developed under the same policies, etc. that in-house work is. In other words, the outsource team or teams is considered to be just an extension of the the parent organization. In this way, they are essentially just additional new Small Teams with little or no “seed personnel” from the original team.

Regardless of which of these models is chosen, the following additional considerations must be taken into account:

• Testing is not considered to be purely under the control of the outsource team. There must be some in-house testing performed that will probably require additional in-house personnel.
• The delivery schedule for outsourced work must be flexible enough that a slippage will not adversely affect the in-house work schedule. In Agile development, this means that either sprint planning must occur at least two sprints ahead, or the outsourced work can be delivered asynchronously to the in-house development schedule.
• The outsourced work will either have to be developed against documented interface specifications and test drivers, or against existing completed work so the outsource team is not dependent on in-house work.

Keep in mind that ramp-up time for Outsourced Work is generally longer than for additional in-house teams. You should never expect that the amount of successful work per unit time (i.e. work that correctly implements the requirements, is inherently testable, passes both internal and external tests ,and is integrable with in-house work) will exceed 75% of in-house work and may indeed not exceed 50%.

Impact on SCM
The SCM impacts will vary depending on how the outsourced work is received. If it is in the form of source code, then it will have to be factored into the versioned codebase, built and tested according to the policies and practices set up for internal development. That means that the impacts of refactoring will require stringent oversight. If the work is source code, but it it developed using the in-house infrastructure, including SCM tool chains, then only the normal additional work of supporting multiple branches and merges will need to be considered.  If the work is received as true Third Party components such as executables, DLLs, or libraries, then they will need to be versioned at that level and the builds adjusted to accommodate them. Unless this occurs at milestone boundaries, the impact can vary from transparent to severe.

Will the Infrastructure Be Sufficient?
Regardless of which method is chosen, there will be additional administration, communication and bandwidth requirements, both in terms of personnel and technology. There could easily be additional costs that include workspace, servers, workstations, prototypes, network connections and bandwidth, software, licenses and maintenance fees. All of these fall within the scope of “infrastructure scalability.” If any of these present significant obstacles, then they should be addressed up front and used in making the go/no-go decision.

Of course, it may well be possible that there are no problems scaling the infrastructure up to the level that will be needed. I have found, though, that if the infrastructure cannot be scaled to at least 2x the level that is projected, then one has started down a very risky slope indeed.

Summary
When a Small Team needs to grow beyond what is effective for a Small Team to do, then there are only two real choices, add additional teams (in-house, outsourced or both) or transition to a Large Team. Both choices have their pros and cons, so which is picked is a matter of culture and management as much as technical merits. Irrespective of which is chosen, SCM will be affected to some extent, mostly in the areas of branching/merging and build infrastructure. If you are facing this challenge, please send feedback to the article to others can share what you found. If enough feedback is received, I will revisit this topic next year.

In the next article in this series, we will address what happens when Large Teams shrink.

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.

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

[2] Pathological coding is what we used to call “spaghetti code.” It is code that does not follow a simple hierarchical (or other) pattern or is not organized in the form required by the language or language framework. It is very easy to create code of this type and almost impossible to correct it after the fact. An example might be a piece of business logic that is embedded in a UI that takes advantage of a data structure for persistence. When that logic is used in a back-end (think server-side) component, all of a sudden the back-end code requires UI components – even though it does not possess a UI!

Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis supporting a modified Agile-SCRUM development methodology. He uses a combination of AccuRev, CVS, Bugzilla and AnthillPro (as well as custom tools). He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), FWLUG (Fort Worth Linux Uscers Group), NTLUG (North Texas Linux Users Group) and PLUG (Phoenix Linux Users Group).

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment