Most tools that are available to the project manager, requirements analyst, software designer, programmer, or tester belong to one of the following categories:

Most tools save time and reduce errors by automating a portion of your development or management process. Tools that let your team members iterate on designs or accurately repeat tests can lead to higher quality and projects that are more successful. Defect-tracking tools ensure that problem reports do not get lost, and source control tools prevent one programmer’s changes from obliterating another’s. However, the first lesson to keep in mind is:

For example, development groups sometimes believe that because they’re using a tool to track defect reports, they have a defect-tracking process. In reality, a tool supports a process by accelerating certain activities, automating routine tasks, enforcing process rules (such as who is permitted to close a defect report), and keeping track of a myriad of details that can overwhelm humans. The process defines the steps that project participants perform to carry out some activity correctly. Team members must share a common understanding of those steps and of the roles and responsibilities of the process participants.

Note

Expecting a tool to replace the need for a process. The classic example is to acquire a requirements management tool and hope it will somehow help you get better requirements. It probably won’t. It will help you do a better job of managing whatever requirements you store in the tool’s database. It’s a classic case of garbage in, garbage out, though.

I once implemented a new change control system in a Web development group in a large company. First, I wrote a change control process, which the team members reviewed and accepted. We then beta-tested the new process using paper forms for a few weeks while I selected a commercial issue-tracking tool. Feedback from the beta test helped us adjust the process, and then I configured the tool to support the new process. This was the most successful process improvement we introduced into this Web development group.

Introducing tools into a team can be disruptive. New ways of working demand new ways of thinking, and most people aren’t eager to be forced out of their comfort zones. To succeed, the team members must agree on some conventions for using new methods and tools. This transformation requires both culture and technical changes. This brings me to lesson two:

Forming, storming, norming, and performing describe stages through which a new team progresses. These terms also characterize the evolution of a software group that’s trying to apply new approaches. During forming, the team selects a tool. During storming, team members debate how to use the tool, whether it’s a good investment, and how to interpret the rules embodied in the tool or in its underlying methods. If you stop at the storming stage, your team will not reach an improved future state that includes the tool. Storming is part of the learning curve, the cost of investing in new approaches that promise to yield long-term benefits.

Guide your team through the storming stage, relying on the team members’ professionalism and willingness to compromise. It should then enter a norming stage, in which the team members agree on how to apply the tool in their environment. Some individuals won’t always get their way but everyone must be a bit flexible to support the common good of improved team performance. The ultimate goal is performing, at which point the team achieves better results with the new tool than without it.

I once had a manager who understood well how this process worked. He watched the team members debate questions and concepts regarding exactly how we could make the tool work in our environment. Peter just sat back and moderated the "storming" discussions so there wasn’t too much blood on the floor as he let us work through the issues. Eventually we reached sensible agreements that worked well for us. If Peter had truncated the conversation or attempted to dictate "the answer" we would have been less successful and more irritated.

Anytime someone is asked to change the way he works, you can expect to hear the question, "What’s in it for me?" This is a normal human reaction. No one wants to go through a meaningless and unpleasant change exercise just because a colleague got suckered in by an overhyped advertisement or product demo. Sometimes, though, the change doesn’t offer an immediate, obvious benefit for every individual involved. The lesson here is:

Anyone attempting to introduce new software development methods or tools should be able to articulate the overall expected benefits for individuals, the project team, the organization as a whole, the company, and the customers. As an illustration, developers might not perceive the need to use code analyzer tools. After all, it might take them longer to complete their work if they have to run the code through a tool and fix any problems it finds. However, explaining that it costs several times more to fix defects when the system testers find them than to use the tools during coding is a compelling argument. Quality practices that cost one individual more time than his current work methods often have a high return on investment downstream. This benefit might not be obvious to those who fear that the tool is making their jobs harder.

Software tools sometimes are hyped as silver bullets for increasing productivity. Some tools do indeed provide a substantial productivity benefit, as with automated testing tools that can run regression tests far faster and more accurately than a human tester can. However, the benefits from most tools come from improving the quality of the delivered product. Productivity gains come over the long term, as tools help developers prevent defects and find existing defects early and efficiently. Improved initial product quality reduces late-stage and postrelease defect-repair costs. Any action that reduces rework frees up developer time to create more new products instead of rehabilitating flawed ones. Keep lesson four in mind as you explore increased software development automation:

I’ve heard development managers balk at acquiring development tools because they are expensive. "I can’t afford a copy of Tool X for every team member at $2,000 per seat," they protest. However, remember lesson five:

A good example here comes from requirements management tools. Licensing a powerful requirements management tool for a team of 10 developers and quality engineers might cost $20,000. However, you don’t have to go very far wrong on the project’s requirements to waste $20,000 implementing unnecessary functionality or reworking implementations based on poorly understood, ill-communicated, or overlooked requirements. You cannot predict exactly how many errors such tools can help you avoid. Nonetheless, your tool acquisition decisions should consider the potential costs of not using a tool, as well as the size of the check you’ll have to write.

Note

Attempting to economize by not training your team members in how to use the tools properly. Sure, smart developers can figure out how to use new tools, but vendor training can help your team members become more productive more quickly.