 |
How to Select the Right Team Development Product |
|---|
|
How to Select the Right Team Development Product |
|---|
Introduction
The objective of this document is to help organizations make an informed team development product evaluation and selection, and have a successful implementation that is hopefully not too painful.
Complementary to this document are a Team Development Overview, and specific product reviews that discuss leading Version Control and Software Configuration Management tools.
Finding the Right Product
How is a development team to go about finding the right product for their needs? Given the fact that SCM provides a critical foundation for all development and maintenance activities, the selection process deserves some thought and time. On the other hand, nobody can afford to get stuck in "analysis paralysis" mode. Rest assured that whatever you choose is not going to be a perfect solution, and will require ongoing adjustments. But if planned properly it will produce valuable benefits in terms of quality and productivity.
The secret to a successful SCM implementation lies in the combination of user acceptance and management support. Leave one of these ingredients behind and you are asking for a painful experience.
Finding the right product is easy. Knowing what you are looking for is the tough part. The discussion below assumes that you are in an organization with 10 or more developers. If you are in a smaller team, some of these steps are going to be greatly streamlined, but should still be performed.
Management Support and User Acceptance
If management support is not there from the beginning, you need to do your homework and present your case in a compelling way leveraging the successes and horror stories of your organization and similar ones. Particularly useful are case studies in the same industry. Network with other professionals and leverage the pool of knowledge in the configuration management discipline. A posting in the newsgroup comp.software.config-mgmt can get you in touch with excellent resources.
After management support is secured, create a small and determined task force with representatives from each key functional area in the team (developers, quality engineers, testers, configuration managers, build meisters, operations, etc.). These individuals must be empowered to make decisions and ensure the buy-in of the group they represent.
Determining Your Requirements
Before you start looking at products, document your requirements. Requirements are not just a laundry list of features (like the one in the Team Development Overview document). Instead, requirements must include:
Selecting a Product
Now you are ready to talk to vendors. You do it earlier, and you end up with one of those strange requirement documents that only one vendor could possibly fulfill. When you see one of them you can always tell which vendor an organization was "influenced" by. On the other hand, when you start talking to vendors be open to their suggestions. Many have a wealth of experience with a large number of installations and their input can be useful, if they really listen to what you want to accomplish, and support you in your goals. In general vendors should be thrilled that you know what you are looking for. It lets them know that you have commitment and will not waste their time, which means that you will get their top notch resources to help you. It also makes it clear to vendors what it's going to take to get your business.
Do a first on-paper screening of products based on your must-have list. Those products that pass the test are candidates for evaluation. Take the time to do hands-on evaluations. No matter how good a product looks on paper, there is no way to be able to tell how it will really behave, until you play with it. Set up a simple case study with your code that quickly gives you an idea of what it would be like to go through a release cycle with each product.
In parallel with your evaluations, check references. Get names in your industry and with similar requirements. Just because you are starting to fall in love with a product doesn't mean that you should short cut your research. Check the vendor, their stability, their support.
Implementing a Product
Before you throw the product you selected to the masses, take the time to strategize your rollout time-line. Make sure you build enough internal know-how to support the effort. And identify the potential risks (project deadlines, system capacity, etc.) to a successful implementation, and how you plan to address them.
Most important, remember that by now your original requirements are probably obsolete, and should not be treated like the bible.
Conclusions
Team development is a very dynamic discipline that affects a wide cross-section of software development functions. When implemented with management support and team buy-in, it can be extremely rewarding, and result in quality and productivity improvements. Otherwise, it can be extremely frustrating, and amplify political squabbling and finger-pointing.
It is important to take the time up front to build a foundation of understanding and communication that will create clear goals and requirements, simplify the tool selection process, and streamline its implementation. If you get external help in this process, make sure that you use it to help you find your answers and make your decisions, and not to make a decision for you.
Team development and developing a team are two sides of the same coin.