Have you ever left an estimation session asking yourself "what happened?"
I mean, really, you went in with the best of intentions. Perhaps you had numbers, or at least comparable experiences, to justify the hard details.
And then you walked out committed to something that you couldn't possibly do.
You thought you were doing test estimation, but it turns out, you were doing test
negotiation.
This is no huge surprise. On technical teams, the management, customer, marketing, sales, and liason-like people are, well, people-people. Negotiation is a huge percentage of what they do.
Technical folks, on the other hand, often arrive in technology because the people stuff is hard, messy, and, well, we aren't particularly good at it.
There are lots and lots of ways to do negotiation, and I won't pretend to make you an expert with one blog post. In fact, I recommend investing some time in the negotiation literature; books like
Getting to Yes,
The Seven Habits of Highly Successful People, and the
McGraw-Hill 36-hour Negotiating Course may have a place on your bookshelf, yes, cliches and all. Today I will list a few tips that I've found helpful, and how they apply to software testing.
1) Negotiating is about creating options.
Of course we can test it in ten minutes; we can do a
crappy job testing it in test minutes! We could do a
slightly less crappy job in twenty minutes. In an hour, we could do this; in two hours, this other option over here. Now, Mr. Boss man, we would like four hours, to do all this. Without doing all this, we don't really know what happens if you push
those buttons.
Sure, we can hit hit two hours; what should we
not do? (Alternatively, what should we do first?)
Do you see what's happening here?
Instead of binary "I have to do more with less" thinking, we instead offer our customers a
choice.
When people have choices, they tend to feel in control -- and a whole lot of the weird social behavior we see in software is people trying to gain or hold onto a sense of control.
2) Nothing is free.
When we give our estimates, one common response is the mild look of disappointment, the comment that "can't we do a little better than that?" or "we were hoping for more like (0.70*your estimate). As nice people, our tendency is to either give in, get optimistic, or "think about it" with the hope of finding a way -- which usually involves both giving in and getting optimistic.
It's not a genuine way to collaborate. Our estimate should be how long it should take to really do things during the business day. There should be no facebook time to cut, no slack time to remove. Perhaps, for a week or two, we might work through lunch or stay late, netting perhaps a 5% or 10% productivity gain, but these things tend to wash out after two weeks, and they certainly won't get us to 30% off.
No, to hit the date, we'll have to cut something. That's okay, because negotiating is creating options.
In some cases, we have conditioned people to push for concessions. The first time we refuse to concede, things may get weird -- so create options.
3) If you're wrong, it's better to be off by a small amount.
We still need to estimate with Agile methods; the difference is that our estimates are in minutes, hours, perhaps a day or two. If I am 100% late on a 'project' that should take an hour, well, that makes me
perhaps an hour late.
When I compare that to the thirty-day test cycles we had toward the beginning of my career ... well ... my head hurts.
Okay, it was a hardening cycle. Sort of. If memory serves, we were late, and had sixty days planned for testing, so we cut thirty days out to write more code.
Of course, the reality was that we were late because the problem domain was harder than we originally believed, so the test cycle should have had more time allotted. And, of course, it did, because we shipped about a month late, then spent the next two months on maintenance fixes.
Which brings me to my fourth point.
4) People who 'win' at manipulative test negotiation actually lose.
it's a funny thing. If you sell a car, and negotiate a ridiculously high price, you can probably get your money from the bank and go home satisfied. (For some definition of satisfied.) It's also possible that both sides can honor the agreement, and even be happy.
With software development, not so much. The VP of Marketing gets you to agree to test a component that evening and release in the morning, but you find bugs, and the devs don't have time to fix them, and you
just can't ship -- or you ship broken.
Neither of these options is working for me.
The problem with paying too little, as John Ruskin so aptly put it, is that you run the risk that what you bought isn't capable of doing what you paid for it to do. If you've ever bought a pair of dollar-store sunglasses, you probably know what I mean -- if you made it out of the parking lot with them, you were luckier than some.
Finally ...
5) If you find negotiation and conflict are hard, go practice!
I recommend trying to buy a used car. I know some folks in the dating literature recommend trying to pick up a phone number from a stranger you find attractive. (They argue that even if you are in a relationship, you can throw the phone number away.)
I've never done that (it's kind of
ewww) but I can understand the intent. I have, however, tried some zany and outlandish things, like Hawaiian shirt day, or (client_name)Camp, where we all bring in cots and sleeping bags and crash at the office one night.
When that failed, it became "let's watch the princess bride 'till 9:00PM."
Or anything. You can negotiate who will take out the trash, or do the dishes, or change the baby's diaper. You can learn to create options, to deal with conflict, and to do it well, with integrity.
It turns out we do stuff like this every day -- if you are dealing with a jerk at work, the upside is you are learning to deal with stress and conflict.
Like most skills, it can be done better or worse, with reflection and intention
or in a sort of panicked reaction. We also can get better at it over time.
No get out there and hang out with that jerk! It's good for you!
Or something. :-)