A cultural transformation takes place as a team moves from manual methods to the discipline of using structured processes and tools. Facilitate this change by:

Some developers will balk at using new tools, insisting that they can do better work with their current approach. For instance, programmers who use interactive debuggers to perform unit testing (an inefficient process) may resist using automated testing tools. Some skeptics can be swayed when they see their teammates getting better results with the new tools but others will never accept that there’s a better way. Be alert for recalcitrant team members who sabotage the improvement effort by "proving" that the tools are worthless. Look for allies among the developer ranks, early adopters who are willing to adjust their current approaches to try new tools.

Note

Expecting instantaneous productivity or quality gains as soon as the new tool is installed. Anticipate a learning curve as the team members learn how to apply both the techniques and the tools effectively.

The tool issues become more complicated if you’re working with development teams in multiple locations or companies. As an example, ensure that the source code control system your vendors use is compatible with your own tools. You don’t want to run into major headaches when your vendor delivers files that don’t fit nicely into your own configuration management system.

Educate your managers about the value of investing in tools so they understand the tools aren’t just toys to amuse those technology-drunk software geeks. Obtain their commitment to spend the money you need to license the tools and train the team. Make sure they recognize and accept the short-term productivity hit from the inevitable learning curve. Ask management to set realistic and sensible expectations about how the team will incorporate tools into their routine project activities.

The best chance for successful tool adoption comes if the tool capabilities will attack some source of pain your team is experiencing. If developers spend countless hours on tedious searches for memory leaks or pointer problems, they might be willing to try run-time analyzers that look specifically for these kinds of problems. Begin by identifying the areas where improvements are needed and the problems you hope the tools will solve. Numerous magazines periodically publish tool reviews so you can compare features and select the products that might suit your team. I won’t include specific references to tool resources here because they change rapidly as one vendor acquires another, vendors rename tools, and new products appear.

Incorporating tools into a software organization requires more than dropping a license key on each developer’s desk. Support the new tools with training in the underlying approaches, such as testing concepts or project estimation principles. Don’t rely on tools to teach your developers the fundamental methods, any more than you can learn arithmetic by using a calculator. The individuals who I’ve seen use tools most effectively had a solid understanding of the methods and principles that were implemented in their tools.

As your team pursues the effective use of new software development and management tools, be sure to respect the learning curve. This will likely make initial attempts to use new tools actually take longer than the previous methods did. Encourage the early adopters to share their successes and failures with their colleagues so everyone can learn from each other. Work toward a long-term objective of providing each of your developers with a robust, integrated automation suite that will increase their productivity and the quality of the delivered software.