Imagine a Better Situation

Picture in your mind’s eye the scene where someone asks someone else for an estimate. What do you see?

You probably envision two people facing each other, looking in opposite directions. This sets a scene ripe for confrontation. Or perhaps they don’t make the request in person, so the estimator is receiving a disembodied request. How impersonal and how easy it is to respond without considering the person at the other end.

Now let’s zoom out to the larger picture surrounding estimation. There is a need to make a decision, and an estimate might help inform that decision. Therefore, someone may ask someone else to perform an estimate. That person comes up with an estimate and reports it back. The first person responds in some way to the estimate and presumably makes the decision that required it. This is the basic workflow of estimating for someone else’s needs.

Now let’s imagine this workflow taking place in a way that respects who each person is, what they know and know how to do, and the needs they have. Given the Agile Manifesto’s value, “Customer collaboration over contract negotiation,” it seems natural that organizations adopting agile software development would collaborate with their development teams as peers having different skill sets. Certainly, agile teams will respect the needs of the business paying them to program. Even when those needs are more perceived than real, collaboration asks us to approach others where they are.

Look Together at the Work

What would it take to structure the scene to one with two people side by side, looking in the same direction at the work to be done and the goals to be achieved? When you think of the scene that way, does it change the way you might phrase the request, or phrase the response?

If they’re communicating virtually rather than in person, how can they make contact, person to person, before launching into the request or response? How can they focus the request on a shared goal rather than the estimate itself?

I’ve often noticed that people working on the same project think that what they see is obvious to everyone else on the project. When people on a project start sharing what they’ve seen and heard with each other, they’re usually surprised to learn that someone didn’t know, or didn’t notice, some of the things they did. They may be shocked to learn that they’ve overlooked some things that are obvious to others.

If you don’t have agreement on the basic facts, it’s little wonder that you don’t agree on how to interpret those facts and what significance they may have.

Understanding Others’ Needs

Imagine the situation of a junior executive in a large organization. You’ve got business goals to accomplish, and several large programs in flight toward meeting those goals. You might also be considering a new program, or perhaps starting a pilot project. The work to accomplish these programs and projects is delegated to people who report to people who report to you. How do you know what’s going on? How do you spot potential problems that deserve closer attention? Does it make you nervous that your success or failure is in the hands of scores of people?

Now imagine the position of a technical lead of a project just starting up. You’re considering various technical approaches to the work. You’re wondering who will be available to work on the project. Who can you get with enough experience to fill a couple critical roles? What if the best choice in technology doesn’t match the skills of the development team? How much will the requirements change over the project? What if other teams, on whom you’re dependent, don’t deliver when you need them? And now you’re being asked to give an end date to the project when all you have are questions!

Wherever you work in whatever organization, can you have empathy for these two hypothetical people? Can you sense what the situation looks and feels like to them? Can you do the same for the real people in your organization?

Congruent estimation requires understanding the needs of the other person in order to balance their needs with yours and those of the context.

Communicating Your Needs

Congruent estimation also requires understanding your own needs, and making them accessible to others. You’re not helping yourself or your project if you don’t work to make it clear what you need from the situation.

As people, we have a hard time articulating clearly what we mean. We have a picture in our minds but have not thought clearly enough to put it into words. We use words that are not precise and could be taken to mean several different things. We use relative pronouns with unclear antecedents. We soften our words to sound more polite than the words that we’re thinking. We make assumptions that are not apparent to our audience, but we assume they understand. We use words that are commonly understood by some people, but perhaps not the same way by our audience.

I know that you believe that you understand what you think I said but I am not sure you realize that what you heard is not what I meant. –Anonymous

We have just as much trouble as listeners. Sometimes we don’t hear clearly and hear words other than what was said. Sometimes we assign meaning to the words that are not what was intended. And those meanings tickle our emotions and make us feel things, sometimes strongly. They may remind us of other situations in the past that made us feel that way, and that baggage gets piled onto what we’re hearing. And then we respond based on those feelings, perhaps aggressively, perhaps defensively, perhaps deflecting. It’s a quick and complicated process that has been studied as the Satir Interaction Model. It’s a wonder we ever succeed on a “hot topic” like estimation.

Often, though, the crux of the problem is that we haven’t made the needs behind the request for estimates clear. If we need a rough order of magnitude for planning purposes, but our request is heard as a request for detailed precision predicting the delivery date of a project we barely understand, then there will be frustration, and we’re unlikely to be satisfied with the estimate we receive. If we want to publicize our go-live date of a new service, but ask for a rough guess of when things will be done, there will be public embarrassment when we miss that date. In either case, what we thought we requested and what the hearer thought we requested could easily be different things.