Small Teams require a different level of process than big teams – or do they? Is there really any difference between implementing SCM for small teams versus big teams? I have implemented SCM for some pretty large teams with 30+ plus developers in large organizations of 700+ developers. I have also worked on very small teams with just 2 or 3 developers. I like working on small teams because I usually get to do more - from the release management to testing to helping to debug the code. In some cases, I have found it very difficult to implement SCM in smaller teams, where there can be some pretty difficult challenges. You should never underestimate the difficulties you may encounter including resistance to change that you can encounter when you are working with a smaller team. Read on if you would like to be prepared for the challenges ahead in implementing SCM essentials for small teams.

Report from the Trenches
In this article I am going to relate some of my own personal experiences. I want to acknowledge that this is not a very scientific approach. In my training in Industrial Psychology, I learned to study group behavior in controlled lab conditions. Those studies have yielded a great deal of information and the lessons learned form the basis for how I approach software process improvement. But sometimes the lessons learned working from the trenches are just as valid and helpful for effective implementation of software configuration and release management best practices. For this article, my observations about working in small teams are based upon my own personal experiences.

Small teams have their own culture
In small teams, it's pretty common for everyone to play multiple roles. It's been my own experience that working in smaller teams has a different feel than larger teams where there are usually well defined roles and responsibilities. Smaller teams develop their own culture and behavior. Everyone has to rely upon each other (even more than on larger teams) and there is often a stronger group culture than in larger teams.

Where did the peer pressure go?
In larger groups, I usually "work" the crowd. I always look for the teams that want help with implementing SCM best practices. Then once they are a success, I can leverage their support to win over the other groups. This means that I can avoid trying to spend all of my efforts on teams that really don't want any SCM help. Then once their peers are successful, the same resisters come breaking down my doors to implement SCM. In a small group, I can't use my favorite "peer pressure" tool.

Are Smaller Teams More Agile?
It is often true that smaller teams adapt and embrace agility much more quickly and enthusiastically. That means that I can setup continuous integration and promote other agile practices. Now I have also seen agility embraced in larger organizations but team size does often affect their willingness to embrace agility.

But who handles the release?
I have often joined existing small teams because they suddenly started having problems with their build and deployments. A good disasters occurred and suddenly they decided that they needed a build and deploy expert. The problem is that everyone on the team was accustomed to building and releasing their code without any controls. Sometimes, it even worked. Now here I am coming in and teaching them SCM best practices and stepping up to handle the releases. Even after the recent memory of a few disasters this is always a tough sell. Developers appreciate the help, but they often like to bypass the controls too. I hear them say, "well I used to handle the releases myself. Why do we need a build process?" My other favorite line is – this process is just too complicated to automate – you need someone who really knows what they are doing.

Compliance with Sarbanes-Oxley
Large or small, many organizations acknowledge the need for compliance with Federal laws - including section 404 of the Sarbanes-Oxley act of 2002. This may also be a tough sell as smaller teams often "fly under the radar" and don't believe that they have to worry about SOX and compliance. In most cases they are wrong. But, again, in large organizations you may encounter less resistance because they hear about the other teams that are getting audited and suddenly they want to implement SCM best practices immediately.

Beware of adding one more person
The most interesting phenomenon is watching the team that runs great when they have 7 people and then completely falls apart when they add one or two more people. I have seen this happen many times with very successful teams. These teams do great when they are small and communication is easy. Adding just one more person can actually significantly change the communications dynamic dramatically.

CM's role on small teams
Solid and dependable software configuration and release management practices are needed on all software development teams whether large or small. But CM practitioners need to be aware of the various challenges that they confront in any environment in order to successfully implement SCM in any team regardless of size.

Conclusion
Small teams or large teams you need to decide how much process will help you get the job done. Most large teams are actually teams of teams and each of them may have their own interesting culture and characteristics. You need to match your process to the requirements of the organization that you are working with. Remember also that small teams can make great systems that accomplish a great deal. Make sure that you drop me a line and let me know about your experiences with working with small (and large) teams!

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Software Engineer specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment