e-Talk Radio: Hendrickson, Elisabeth, 15 February 2001

Rebroadcast 29 March 2001

a distance on the wall or whiteboard. Number three, everyone at the meeting gets three votes. Four, each person may cast his or her votes in any combination, one at a time, or multiple votes, for a particularly important requirement. And number five, tally the votes up, and now the requirements are now prioritized. I think it is very interesting to use three votes, because I think in most cases people would say, "You get one vote, and by the way it better be the same as my vote."

ELISABETH: Well, that's a way to ensure that the selection process is dictated rather than ensuring that it meets the business requirement.

CAROL: How does it work when you have...when you use these three votes. Are people...that's got to be a new concept.

ELISABETH: Actually, I find it...it was several years ago and now I don't find that it is. And so I don't know if that means that more and more people are using this style of multi-voting, or if that means that I am just in a different, you know, it just happens that the organizations that I have been working with have used this before.

CAROL: Have you only been working in Florida lately?

ELISABETH: No, I've been working primarily in California.

CAROL: Okay. That's a joke to do with our voting process down here.

ELISABETH: Oh...I'm being dense, I'm sorry.

CAROL: Because, you know, if we don't vote the way that we wanted to the first time, we might get a second chance or...

ELISABETH: That's right...

CAROL: Or maybe a third chance.

ELISABETH: And dimple your ballot.

CAROL: We're not going there. I know that Chad Everett is still pretty upset that he wasn't counted twice. But, once you've got these priorities and you've actually stepped through this, your last step that you advise is to evaluate the final list.

ELISABETH: Right. And that's where you actually bring it in, hands on, and make sure it is going to work in your environment.

CAROL: Now, what would you say if a vendor...and I have encountered these, if a vendor will not let you evaluate a tool, they insist on an investment.


CAROL: And you have to essentially pay for the tool before you are actually allowed to see it. I know that when I was in development advising one of my clients, they wanted to look at the types of reports that were produced by a particular tool. And the tool vendor said, "You can't find out what the reports are unless you sign nondisclosure, and you can't use that in your comparisons."

ELISABETH: What do you mean you can't use that in your comparisons?

CAROL: Well, they would not allow the list of their reports to be published, even internally. So, it...


CAROL: It is kind of a dysfunctional situation.

ELISABETH: Well, and you know that tells you something about how your relationship with that vendor is going to be later.

CAROL: That's a good point. And we'll be back to finalize everything and sum up after these short messages. I'm Carol Dekkers, and we've spending the last good portion of an hour talking to Elisabeth Hendrickson about how to evaluate tools. She has come up with a very good step-wise process. Number one, we went through, "Defining Initial Requirements." Number two, we walked through, "Investigating Options." Number three, "Refining Those Requirements." And, as you said, "Sometimes there is only one tool that meets the needs, so you don't even have to do step four and five in that case.

About the author

Elisabeth Hendrickson's picture Elisabeth Hendrickson

The founder and president of Quality Tree Software, Inc., Elisabeth Hendrickson wrote her first line of code in 1980. Moments later, she found her first bug. Since then Elisabeth has held positions as a tester, developer, manager, and quality engineering director in companies ranging from small startups to multi-national enterprises. A member of the agile community since 2003, Elisabeth has served on the board of directors of the Agile Alliance and is a co-organizer of the Agile Alliance Functional Testing Tools program. She now splits her time between teaching, speaking, writing, and working on agile teams with test-infected programmers who value her obsession with testing. Elisabeth blogs at testobsessed.com and can be found on Twitter as @testobsessed.

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