There are several questions you have to ask and answer when implementing software configuration management (SCM) for small teams: Is the minimalist approach of SCM congruent with my duties to implement sound SCM? Is there a difference between implementing SCM on small versus large teams? Can I pick and choose the concepts of SCM to implement?
There are several questions you have to ask and answer when implementing software configuration management (SCM) for small teams: Is the minimalist approach of SCM congruent with my duties to implement sound SCM? Is there a difference between implementing SCM on small versus large teams? Can I pick and choose the concepts of SCM (i.e., a cafeteria plan approach), and still stay true to the discipline of SCM?
This is a situation that many of us CM folks are faced with daily. You are asked to implement SCM on a small team or a new effort. Whether this is a new position you have taken or in your current organization, it will eventually happen. You may be told this team will be small so a full-blown SCM implementation won’t be necessary or you may decide this for yourself.
I believe that small teams can benefit from smaller implementations of SCM. I am currently in a situation where we don’t have a CM plan for our organization. Many would argue that you can’t operate without a CM Plan and ask how SCM issues are resolved. A lot of this depends on the maturity of your organization and how receptive they are to doing things without specific instructions or plans to follow.
First and foremost, a strong culture of SCM and knowledge of its importance and necessity is of the utmost importance. Though I believe it is important to have a CM plan for large teams or small teams, it’s not an essential tool for a team to succeed. What is important is that they understand the value of their own CM effort’s in the success of the team.
At my organization we have a CCB that sets priority, yet doesn’t do so with the aid of lead developers and business analysts. However, we are able to get priorities set and work 
on issues that the business deems important; this allows us to prioritize our work days. Not having a CCB has not made our work any more difficult than it would be if there was a full blown CCB.
In small teams the priorities may only be set by one or two individuals in the organization. If that’s the case, a CCB would only be a rubber stamp that adds no value. On small teams this idea is very important value over dogma and right sizing your SCM effort as to not hinder progress.
The two examples above are staples of SCM, yet not having them has not harmed our efforts to implement sound SCM principles. There are many more principles I could discuss here, so I chose just two of them. I believe that what is more important than a piece of paper or a weekly meeting is the ability for a team to see where they have been and see where they need to go based on good version management and good issue management.
Again, the maturity of your organization is paramount here. This actually may be more important than what you implement as it pertains to SCM. If your organization is mature enough you can skip some of the formalities and implement only what is needed and not extra things that will hinder progress. For example, if your team understands the importance of sound version management, manages its defects and issues consistently, baselines its code for releases, and has good release management practices, then what good does having a four-hour weekly CCB meeting really accomplish? How would a CM Plan benefit this same group?
I am sure many are declaring me an apostasy to the very SCM Principles that I say I support, I say not so fast. As long as I am able to achieve the following configuration identification, configuration control, configuration status accounting and configuration audits I should be fine shouldn’t I?
There is a caveat to my prior statements about scaling back your SCM implementation. If you are asked to implement a pilot that will be spread throughout an organization this creates a different situation and a different approach. In the case where I would be implementing SCM as a pilot to prove it works, I would have a CM plan, a formal CCB, and many of the bells and whistles necessary to scale the implementation to a broader audience. It is also dependent on what you describe a small team to be. Are we talking about a small team in a large organization or a small team in a small organization? Then you have to define what a small team is in number of people that will vary on what your organization deems a small team to be, it may be six people in one company and sixty in another.
There are many factors that should drive how you implement SCM in a small team so no one factor such as team size can be used, with one exception the toolset you purchase to help with your implementation. For a small team implementation you may want to go with freeware and skip the pricier and higher end tools. Of course this depends on future scalability plans.
Now the answer to the question “What would you implement in a small team or organization?” From an SCM perspective, you need strong version management. This will be the lifeline on which all other things depend. Without an CM plan, the rule needs to be that everything should be kept and versioned. You need to make sure that defects are tracked and managed. No spreadsheets or email are used for this; you need a tool to accomplish it.
In addition, if the issue is not entered in a ticketing system, it never happened. Builds should be performed by someone other than the developers who wrote the code, period. If you allow developers to do the user acceptance builds or production build, you create a huge risk of patches and fixes that are not versioned when entering the system. A strong release management ideology has to permeate the group. For example, limit access to production databases and code, deployments should be a cursory action not a full scale disaster should someone sneak in some fix that others aren’t aware of.
Implementing SCM in small teams is essentially an exercise in doing the right things to allow you to what is necessary to carry out the four activities of CM: configuration identification, configuration control, configuration status accounting, and configuration audits. Those pieces of the puzzle are dependent on many factors such as the organizations maturity and the SCM direction of the organization.
Picking and choosing the SCM concepts that will allow you to stay true to the field, and not jeopardize the four activities of CM, will ultimately deem whether your efforts are successful. Knowing which ones to choose, and in the right dosage, is dependent on many factors that must be determined before you start to implement SCM in your small team.
