deployment process. However, I can jump in and help with production support and systems administration. I’m also a pretty good testing resource. Members of a small team often have to back up each other and perform whatever task is necessary. This is great for everyone, because learning every role will help you understand the whole system that is being developed.
Large development teams often are divided into separate functions, commonly called silos. This makes sense because large teams need to specialize by establishing shared services that support everyone in the organization, but it can also lead to serious problems. I have seen many large teams in which each specialized group knew their own domain but knew next to nothing about what the other teams were doing on a daily basis. Silos make for inefficient troubleshooting, because each specialist knows very little about what the others do. You usually don't run into this problem in a small team because its members often wear many hats and better understand the big picture.
Many small teams exist within a larger enterprise organization. I have seen small teams maintain their identity quite well, even while existing within a larger context. The key is to have a way to communicate and represent your team to the larger organization, providing transparency and enabling governance that is essential for larger organizations. In agile, you have a representative of your team participate in a Scrum of Scrums where members of different teams meet to share information across different (scrum) teams. I know of one company that grew so quickly it literally did not have enough seats and desks to cover all of its employees. One manager took his team to the disaster recovery site and worked out of that location. Although the manager traveled back and forth between the disaster recovery site and the main building, in every other way the team operated like a small team.
Small teams can be highly effective if they understand what needs to be done while maximizing the synergy of working within the small team structure. Each team member needs to understand his role and how he can help with whatever tasks need to be completed at any time. CM best practices are essential for small teams to perform effective source code management and automated build, release, and deployment. You may find that some of your own best work is done when you are a member of a small team. Make sure that you drop me a line and share your own experiences with implementing CM in a small team!
References
1. Clint Bowers, Eduardo Salas, and Florian Jentsch. Creating High-Tech Teams: Practical Guidance on Work Performance and Technology (American Psychological Association, 2006).
Pages
About the author
Technical Editor of CM Crossroads and author of Configuration Management Best Practices: Practical Methods that Work in the Real World, Bob Aiello is a consultant and software engineer specializing in software process improvement, including software configuration and release management. He has more than twenty-five years of experience as a technical manager at top New York City financial services firms, where he held company-wide responsibility for configuration management. He is vice chair of the IEEE 828 Standards Working Group on CM Planning and a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. Contact Bob at Bob.Aiello@ieee.org, via Linkedin linkedin.com/in/BobAiello, or visit cmbestpractices.com.
