Key learnings from “Software Estimation Without Guessing” by George Dinwiddie
I don’t think that I’m far from the truth when I say that most people hate estimations. Taking it one step further, in all companies, every second person in the room may find them useless. But in reality, we still do it. We sit down with anger. Clinch our wrists. Swear quietly. And based on our gut feeling, fear or having a good or bad day, we reveal our magic number. The number. The number that will follow us for the few upcoming sprints. The number that we will regret was ever mentioned.
I was tempted to read George Dinwiddie’s book mostly because of Liz Keogh's recommendation and the trust that I have in the Pragmatic Programmers publishing house.
And I was not disappointed. “Software Estimation Without Guessing” was not a quick read for me, but it was worth giving it some of my time. It didn’t try to convince me either way: TO ESTIMATE OR NOT TO ESTIMATE. The author took the craft of estimation a step further. He addresses both the technical and sociological aspects of it. For tech people, it may be a great source of ideas, warnings, and questions that they may need to answer for themselves or for others. For non-tech folks, who are engaged in building software, it may open a door to Narnia and bring a more useful perspective on their work. I think that reading it carefully may help to build a better understanding of reality for software teams.
As the author says (almost at the end of the book):
It’s highly unlikely that your primary goal is to meet your estimate. Meeting the estimate is a tactic toward achieving some higher goals, such as business prosperity or making the clients so happy that they bring you in for future project management jobs.
This goes nicely with the famous quotation from Eisenhower:
Plans are worthless, but planning is everything.
Without too many spoilers, let's check the top takeaways!
#1 The art of asking “why” without asking “why”
Understanding the context helps to facilitate conversations and plan the work. However, it is not so easy to ask “why”. As the author advises: Don’t ask them “why”. Can you imagine what response you’ll get if you ask your VP "why do you want this estimate?" "Because I’m the VP and I need it!" So be careful here. You can very easily trigger someone’s defensives or get yourself into trouble. Instead of asking “why” try to formulate your questions with “what”. Be curious about the outcome. Try to ask:
- What will change with this estimate?
- What decision depends on this estimate?
- If you have this information, what will that do for you? If we don’t meet this target date, what will happen?
- If necessary to meet this target date, what can we defer to do later?
#2 Earn your “E”
When reality doesn’t match our expectations, in many cases, we start the “blame game”. Which in many teams that miss their sprints means to defend themselves and shift blame to THEM. In the meantime, all resources are pulled off to meet the sprint goal. And in the end, everyone is so tired and so angry, that it is just easier to sweep it under the rug, rather than talk about it.
So what if, instead of pushing everyone to their limits, we try to identify the underlying problem first? It could help teams to learn from it and make the next sprint more likely to succeed. Or maybe spend a day or a half-day on retrospective? Of course, they may not catch up with your desired deadline, but they will increase your chances for future success.
#3 Asking for the bad news
Personally, I’m still working on that. I think that building a safe and trusty work environment takes time. I loved the way George Dinwiddie articulated the importance of practicing and encouraging everyone to share bad news without fear. So based on what I read and thought about it, I would recommend you stop for a second and think about the last time you heard the bad news. How did you react? How often do people share worse news with you? How do you ask them for bad news?
Having complete information may save the project and a lot of money. But it won’t happen in places where employees are afraid to be honest. Try to build the culture, where people feel good about themselves when they share bad news. Cherish their courage. Show the values that come out of it.
#4 Rule of Three
It’s the first time that I came across the Rule of Three.
Virginia Satir said:
One option is a trap. Two options is a dilemma. Three options is a choice.
And Jerry Weinberg often phrased this as
If you haven’t thought of a third option, you haven’t thought enough, yet.
So as a simple but powerful take away for everyone: I would love to encourage you to use your brain more often and don’t close yourself on limited and well-known options.
Whenever you tackle any problem, don’t just look for one solution, try to ask yourself questions or find someone who would be happy to do that.
When it comes to estimations, gathering as much information as possible is useful. With more detailed knowledge, you can think of many more solutions.
#5 Value shown in the currency of conversation
There were many pages in the book, where George emphasized the importance of having the right conversation, rather than striving to get the right magic number. One of them made me laugh. Mostly because it’s so common in our Tech World.
Business:
Bring me a rock.
Development:
Here is your rock.
Business:
No, not that rock. Bring me a different rock.
Sounds familiar? Doesn't it?
The moral of this super short story is the importance of establishing and maintaining the relationship with those who pay for building the software and those who craft it. As in each chapter, the author comes with help and shares useful questions and observations with us.
We have to be aware that the lack of complete information, chaos, too many proxies or multiple sources of truth will slow us down. So when we sit down to think about how long it will take to build Product X, we should also consider the quality of our interactions with different teams, stakeholders, users.
#6 Yes, I know… but...
Following patterns of our irrationality, we can admit that we have a tendency to fool ourselves in very predictable ways. Especially when it comes to estimations. It was a surprise for me to read about bias in the book about estimation, but it was definitely a great chapter. Following the author, we could learn about the most common bias:
Sunk Cost Fallacy
Also known as "throwing good money after bad." It refers to holding onto something, e.g. strategy because we already invested in it. So instead of cutting it off when we can and reducing the waste, we prefer to follow the tracks.
Anchoring Bias
The initial information becomes your referring point for the future. The first actions that you take will be the indicator for your next steps as you start relying on them, as you already tried them and have some experience.
Confirmation Bias
We look for the confirmation of our hypothesis or concerns. Once we notice any data that could prove it, we treat it as a source of truth.
Precision Bias
We’re more likely to choose an option that has more detailed information. We seek proof to make decisions. Getting them makes our decision-making process easier. Even though sometimes more data may mess up the clarity,
Numeracy Bias
Numbers have to be true. Charts have to be real. The scientist calculated that. Owww it is true. We are more likely to choose an option that has some numbers behind it. The number gives us the illusion of measurement and trust. Especially, if we have limited knowledge in a particular area.
To learn more read George's book?? "Software Estimation Without Guessing" and/or listen to our podcast?? :