Home CM Journal Articles Small Teams and SCM

Small Teams and SCM

 E-mail
Written by Ben Weatherall   
Monday, 16 November 2009 10:11
nov09smallteams200This is the first of a four part series on Small Teams and SCM. The parts are (1) Small Standalone Teams, (2) Small Teams in a Large Organization, (3) When Small Teams Grow and (4) When Large Teams Shrink. All of these leverage an earlier article, Small Team Essentials: An SCM Perspective, previously published in the July, 2008 CM Journal.

What is a Small Team?
There is no hard and fast definition of a Small Team, but for practical purposes it is from 1 person up to the number that can no longer get together casually for blue sky discussions, hashing out problems, reviewing requirements and design decisions, etc. From past experience, I have found that the typical range is from 1 through 10 with 3-7 being the norm. I have seen as many as 15, but that was a special case. If you find you need to document things because everyone cannot get together, then see the third article in this series – you are no longer “small.” Finally, for the purposes of this first article, you are the only software team in your organization. This means that you have no one to fall back on, no one to go to internally for advice or help. In most cases it also means that you get to do your own tool administration as well.

Advantages of a Small Team
  • Communication is simple, so a great amount of intermediate documentation is unnecessary.
  • In order to get anything done in a reasonable amount of time, things have to be kept simple.
  • Refactoring due to not understanding a function (or misunderstanding it) is minimized.
  • The number of “supported releases” is generally minimal. This keeps support branching (and merging) to a minimum as well.
  • Development builds tend to be done as needed by the developers themselves, so the more formal build infrastructure is unnecessary.
  • Enhancements and defect repair tend to be done at the same time and  in the same codebase, so integration is also kept to a minimum.
  • Each developer trend to work on isolated blocks of work so pathological changes are minimized, though duplication of effort on low-level routines/classes is not.
  • Code “ownership” typically develops. This means that problems can be identified and fixed more rapidly since the learning curve is kept to a minimum.
Disadvantages of a Small Team
  • Too little external-facing documentation generally results. Or at least too little documentation that is understandable by the customers.
  • Very little internal documentation is produced, and what is, only the original developers truly understand.
  • Releases tend to be along the order of, “We’re done, take it,” rather than being formally packaged releases.
  • Code “ownership” means that if something happens to a developer, the team has a hard time replacing them.
  • Small teams are inherently limited in the size of projects they can attempt.
  • It is harder to learn from mistakes since there is often no one else there that can point them out.
  • If the team fails, the product also fails and the team members are generally out looking for work.
A Typical Small Team
In a typical small team, everyone wears multiple hats and everyone plays to their strengths. If someone is good at determining what the product needs to do, then they are the one to do the job. The same goes for overall testing (functional, system, etc.). Most of the time, everyone on the team is a developer – though what parts of the product they work on do tend to shake out and stabilize early on.

Most of the time the development model is one of the iterative ones, including the less formal Agile ones. Methodologies (models) such as SCRUM tend to be avoided since they tend to add unnecessary overhead. It often depends on what prior experience the team members have as to whether they practice Feature Driven Development, Test-First Development, etc. The languages chosen, the IDE(s) used, and even the SCM tools selected also tend to be selected based on team member prior experience.

A small team can work on a single “large” product or several “small” products, but splitting their effort on a daily basis causes more problems than the parallelization of the schedule tends to reflect. Context switching causes overhead for people as well as computers. What happens once a product is “done” needs to be decided early on. Some possible options are:
  • Turn it over to a customer for continued maintenance
  • Continue to maintain and extend it
  • Release it to something like SourceForge and just provide minimal maintenance so a new product can be started
SCM for the Small Team
Version Control (VC) and Defect, Issue and Enhancement Tracking (DIET) are two areas that should be addressed.

DIET can be performed simply with 3x5 cards, a spread sheet or a simple shared document; but there are both FOSS and low-cost commercial tools that can be used with minimal setup and maintenance that provide additional capabilities. DIET tools such as Bugzilla, JIRA (up to 10 users) and MantisBT. How sophisticated a team gets with these tools is largely dependent on the formality of the development effort (contracted development is often follows a more formal pattern) and the desires of the team members themselves. What is required from an SCM perspective is that this function is performed in some way and that the time doing so be kept to a minimum. It is rarely necessary to be as picky in how tracking is done (for example, one issue, one set of changes and nothing else is probably too fine a level of detail, though “implement subsystem X” is probably too coarse a level of detail).

VC, using tools and not just date-stamped filesystem hierarchies, is a must for any long term success. Which one depends on several criteria other than member experience. Some of these criteria are:
  • Will code be refactored. If not, can the team hold to this? If so, how often?
  • Will multiple branches/streams need to be supported? If so, will it be for parallel development or just release-based defect repair?
  • How often will branches/streams need to be created? How long will they remain active? How much activity (changes) will occur on them? Will they need to be merged back into their parent branch/stream? Will the changes on one branch/stream need to be merged/ported/back-ported to other branches/streams?
  • How important is the change history for determining the cause of defects?
Common FOSS and low-cost commercial VC tools include cvs, subversion, git and perforce (2-user only). There are many more, but they are not considered “main stream.” cvs provides a reasonable solution if the codebase has a reasonable number of files and directories and if refactoring is not a concern. It is relatively slow in creating branches and it does not track file/directory renames or moves so merging refactored code is almost impossible. Subversion solves several of these problems, but it too has some problems handling large sets of changes when merging from one branch to another. Git is a distributed tools used by the Linux kernel developers and has finally matured to the point where it bears serious consideration. I have stayed away from Vendor specific tools such as those supplied by Microsoft and others bundled in with their development tools. They are “free,” but the cost when switching to other development tools, or when the vendor starts releasing a “better” tool, is one that often causes major problems down the road.

For both VC and DIET tools, the idea is to set up something that is low maintenance, integrates with the other development tools/IDEs being used and will remain available throughout the products development life. There are other tools that can make small team development easier in the long run, tools that support Requirements Management and sophisticated Build and Release Management efforts, 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 this first article, the advantages and disadvantages of small teams, especially where a team is working alone, have been discussed. The actual SCM requirements for these teams are modest and the tools to satisfy them should be set up to be as self-administering as possible. Integration between the SCM tools, project metrics, data mining, etc. are all nice things to have, but only those that are either very easy to set up or that have a hefty ROI should be considered. Using the classical productivity numbers of a team of 5 developers producing 10 lines of working code per day per person and a working calendar of 250 days, a team produces only12,500 lines of code per year. This means that small teams must work smart so that those 12,500 lines of code satisfy the majority of the requirements (remember the old 80/20 rule?)

In the next article in this series, we will address the differences when there are multiple small teams in a larger organization.

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 Users Group), NTLUG (North Texas Linux Users Group) and PLUG (Phoenix Linux Users Group).

Trackback(0)

Comments (0)add comment

feedSubscribe to this comment's feed

Write comment

You must be logged in to post a comment. Please register if you do not have an account yet.

busy