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?