I’m at PNSQC this week. I gave my metrics talk yesterday, and something occurred to me: in traditional projects, we’re used to measuring what’s been done. In agile projects, we measure what’s left to do. I just realized yesterday that the difference in how we measure makes a difference in how people feel about […]
Thanks to Brian Marick, I read Dave Thomas’s Weeding Out Bugs. Much of Bug-Weeding is developer turf. But here’s what managers can do to help: Look at defect counts by module. When you see a module that has more than it’s fair share of defects, start asking questions about what the developers are considering. You’ll
Read Bret Pettichord’s How Did the Blackout Happen? to see how cutting yourself off from data can damage your ability to perform your job.
A colleague emailed me a few days ago, and asked “for a code base with a [given size], what can we expect to see for numbers of defects per KLOC (given the actual industry average or given what the industry believes we should expect). We need some way of gauging whether or not our
In Measuring Productivity #3: Possible Measurements, I made an off-hand comment, “The zeroth measure of productivity is showing up.” I now think showing up is necessary, but not sufficient. I’ve been thinking about what each of us produces individually, and thinking of ways to understand and possibly measure it: How many hours per day do you
I ended up in the hospital last weekend (facial cellulitis – yuck). On my floor, we had people who were not too sick, who needed a few days to recover from an acute problem. Everyone’s prognosis was good, and the average stay on the floor was 3 days. Recovering from an acute illness takes
I’m facilitating a roundtable, Test Management 101, on Stickyminds, and someone just posted a question about how to measure testers to show return on investment: measuring the number of defects they find. Ouch. When you measure developers on the number of lines of code, or testers on the number of defects, or carpenters on