How Do We Compare?

[article]
Summary:

An easy way to gauge progress might be to compare yourself to someone else, but what does that really mean? Johanna Rothman explains why the most valuable comparison is to compare what you’re doing to what you could be doing.

I often receive emails from readers asking questions such as “We have ten developers and two testers. How do we compare to our industry?”; “We have six-week iterations and a two-month hardening iteration at the end of our release. How agile are we?”; “We finish twelve stories in a four-week iteration. How many stories do other people finish?”; or “We fix problems in less than a week post-release. How long does it take other people?”

My question to them is usually this: Why do you care? Is what you are doing working for you? If it is, fine, continue what you are doing. But, if you are worried that what you are doing now is not quite enough for your needs, reconsider what you need. Are you finding defects quickly enough? Would you like to forgo the hardening iteration at the end of your project? Would you like to see more throughput in your project? Would you like to fix problems faster—or not have them at all?

To know how you compare, you have to know what you want to compare yourself to. The real question you should ask is: “How are we doing compared to what we could be doing?”

What Results Do You Want to Achieve?
If you want confirmation that you’re great, here it is: You’re great. If you don’t have a meaningful comparison—and an industry comparison may not be meaningful—then you can stop right now and assume you are great. And, if all you want to do is tell someone how great you are, you can surround yourself with sycophants who will listen.

But, if you want to know that you can be better, here it is: You can be better. Unless you are a robot manufacturing the same thing every day, you have room to improve. Since you are a knowledge worker, you are not doing the same thing every day. So, the real questions are: What results do you want to achieve, and what results does the organization desire or need?

The real question is not how you compare to someone else but how you compare to what you could be. Have you ever looked at your bottlenecks and your concerns? That’s where a quantitative and qualitative assessment of your current state can help you to see where you are and where you might decide to go.

In order to do that, you need to know what’s important to you. For example, let’s address the issue of how long it takes you to fix a defect post-release.

I’ve written about the cost to fix a defect post-release (“What Does It Cost to Fix a Defect” www.stickyminds.com/s.asp?F=S3223_COL_2 or manage.techwell.com/article/what-does-it-cost-fix-defect), but I’ve never discussed the duration of fixing post-release. You can imagine where the cost of fixing a defect post-release is almost irrelevant. Say you are a bank or an insurance company or some other regulated industry—or an oil company fixing a broken well. If you’re a software organization, the cascading effect of the defect is much more expensive than the actual cost of fixing the defect. But, the duration of that defect is what’s keeping you up at night, because it’s not just the time that you have the defect—it’s the bad press that goes along with that defect.

This is a case where if you had one hundred people in development and test, you might even put all of them on finding and fixing the problem. Putting everyone on the case is cheaper than maintaining the cost of the defect for one day.

You can see where a regulated industry might have these problems more often than a non-regulated industry.

But, what about the fact that the defect escaped system test? Or, that the defect escaped integration test or unit test? Do you want to do some root-cause analysis and see where it would have been more reasonable to find the defect, given the way you develop and test your product? I think so, and I think it’s reasonable to seek alternatives. No matter how you look at it, any cascading defect that causes you to lose millions or to not care how many people you assign to fixing it fast is a huge problem. If you might have even one of those, you ought to consider how to eliminate it and significantly reduce the risk of those kinds of defects altogether.

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01