Better Software - November 2008 - (Page 47)

The Last Word Metrics that Motivate by Linda Hayes It’s said you can’t manage what you can’t measure. It’s true that you need some type of measurement system to institute a meaningful incentive system for the people you manage, but to select the metrics that encourage the behaviors you need and reward the results you want, you first have to decide what you need and want. When it comes to testing, this is not as easy as it might sound. If you want testers to find bugs, then counting bugs might seem like a simple system for tracking results. Unfortunately, this might encourage testers to focus on the fringes of functionality, engaging in bizarre behavior to uncover obscure defects and ignoring mainstream activities. It also invites derision from developers who view testers as adversaries who waste time trying to make them look bad. You could count tests executed, but this could lead to high volumes of lowvalue tests, consuming time and resources without producing useful results. All tests are not created equal, and this approach might not distinguish basic menu navigation from more complex and critical end-to-end scenarios. A better measurement might be the number of post-release bugs. This has the apparent benefit of putting focus on the issues that are important to users. The downside, though, is that testers rarely get to decide when the software is ready for release, nor do they always get all the resources they need. It may not be fair to hold the testers accountable for the ultimate outcome. So what are the metrics that motivate? Put simply, they are the same metrics on which other managers and departments are measured: performance against plan. a quality product can be take, what resources will be used, and what To select the metrics measured through increased profitability, reduced costs, your assumptions are. or greater market share. Be sure to articulate Don’t make the incentive the business goals for that encourage the all or nothing. This makes it the product on which difficult to compromise when you are working, identify the potential risks behaviors you need and reward conditions are complicated. Don’t make it now or never, of failure, and describe how you plan to avoid the results you want, you first either—be willing to delay some of the reward until all or mitigate them. the results are in. You might To be rewarded for distribute the first tier of the meeting your plan, have to decide what you need bonus when the software is you have to get buy-in. released, the second tier after This is critical. Meet ninety days of usage, and with your users or and want. the third whenever company other business repreperformance is reported. sentatives and review the plan with them. Insist that they understand and approve Work the Plan it; don’t accept perfunctory sign-off. Ask We all know the best-laid plans can open-ended questions such as “What are become obsolete from the time you start, we missing? What is most important to so don’t just follow the plan; schedule you? What is the worst-case scenario?” regular reviews. Be quick to note when Make sure the users grasp how the assumptions aren’t met, such as when plan was designed to meet their goals, the software is delivered late, the test enas well as all the factors that went into vironment is not available, or critical deit. Once you have the plan approved, de- fects are blocking progress. Constantly velop metrics that measure performance refine and update the plan. against it. This should take into acStay flexible and positive. Don’t just count multiple aspects, such as coverage huff that the developers were late or achieved, schedules met, and resource the code is bad; instead, point out that productivity. your assumptions have not been met and that to stay on track the plan may need modification, such as adding resources, Negotiate the Reward Next, propose and negotiate a re- extending the schedule, or reducing covward system for meeting or beating the erage or features. Be just as quick to own your own isplan. The best approach is to align your interests with those of the business. This sues. If you aren’t meeting goals because might take the form of a three-tier bonus of turnover on your team, over-inflated plan: one part based on how well your expectations for automation, or overly team performs, another based on user optimistic estimates of test execution satisfaction, and the other based on how speed, say so, and propose plans for compensating. Track your metrics conwell the company does. The team bonus helps motivate your tinuously, making sure the users and the team to go the extra mile. User satisfac- team know where you stand at all times. tion is a better measure than post-release defects since it tends to weed out the is- Train Your Team sues that aren’t critical. And the value While there are always superstars to the company of a timely delivery of that deserve recognition, it takes an www.StickyMinds.com NOVEMBER 2008 BETTER SOFTWARE Plan to Succeed To be measured against a plan, first you have to have one. A good test plan covers all aspects—what you are going to test and what you aren’t, how long it will 47 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.