How to tell your manager you can’t estimate

In software, management wishes to have reliability, predictability, and numbers. How do you tell them they can't have it. How do you help them pick the red or blue pill?


Fredrik Carleson

a year ago | 6 min read

Creating software is complex, challenging, and full of variation. You seldom build the same product, using the same tools and technology, several times.

Why can't we admit that we can't predict or know when a product will be ready? Why is this hard for above-average, intelligent managers to register? Why do estimates become commitments?

I believe one reason is the pressure from C-level executives fostered in Taylorism, demanding fixed scope and time. Managers must learn new tricks. We must help our managers. In the Matrix, Nemo is asked which pill to take, red or blue, to see how far down the rabbit hole it goes.

Don't ask managers which pill to take. They will likely take the wrong one. Manage upwards. Help them pick the right pill!

Using DevTalk won't help. We need to speak the same language. Stories and analogies help. Take chess for example.

How long does a game of chess take?

As always, it depends…If you have a skilled person playing against a beginner, it will probably be over in a short period. If you use a chess clock, you can timebox the maximum amount of time.

However, the only way to predict how long the game will take is to replay a historical game, making precisely the same moves, waiting exactly the same time for each move. Then you can add the total number to get the total time the game will take. You can meassure the total time once the game has been played.

Prediction works great for conveyor belts, where workers do the same repeatable specialized actions every time. It doesn't work for chess, where each move changes the possible outcomes.

Ok, I admit, the approach would also work great if you repeatedly played the same Chess game over and over. You would then be using a Tayloristic factory approach to "Minimize variation," "Take away the unknown," and "automate the moves." Using this approach you could even hire unskilled who don't need to understand chess as they will only have to repeat the same specialized actions. Imagine the C-executives proclaiming:

"The workers will be easy to replace, and we can pay less. Hurray. You manager, go implement!".

I am ranting off course, but strangely enough, frequently, upper management believes this is how software is "manufactured." Perhaps the word "software engineering" is misleading?

To engineer something takes time and requires experimentation. Once engineered, what is engineered works predictably, however.

Software is a discovery process every time. We will not build the same product the same way again. Precisely as a chess game doesn't play out the same way every time, chess has too many parameters, changing the game after each move. The chessboard is engineered, however, and will be the same.

The progression of software is a discovery process where you act and react constantly.

But my boss wants reliability, predictability, and numbers!

Now, management wishes to have reliability, predictability, and numbers. They want to know that all the money they spend gives a return on investment.

How do you do this?

The development of software is trial and error, often empirical. Based on what you learn as you progress. You do not know how the market or end-user will appreciate your product until they try it. In other words, you can't make proper predictions. You don't have reliability. Anything complex enough is not predictable. A conveyor belt is predictable. Unfortunately, a conveyor belt doesn't buy your software.

An excellent approach to minimize uncertainty is to deliver something useful for the end-user as fast as possible. Let end users try it to see if it is valuable for them or not. You use the successful Aristoteles approach, "The scientific method."

1. Tell your boss that the scientific method has been a proven concept for thousands of years. It is what took us out of the medieval ages. This is what Einstein used. And it is built into Scrum. Amazing!

Illustration from Robert T Hanlon

You try and try and see what works, and then you use what works. The shorter the cycles are, the faster you fail, the quicker you will find what works. I love the quote from Ken Schwaber:

CEO: "What do you do?""Ken: "I help deliver software in 30 days!"CEO: "What, so you mean I don't have to wait for 12 months to get something I don't' want?"Ken: "That's right. I will give you something you don't want in 30 days!"

Also, remember Thomas Edison's quote.

"I didn't fail. I just found 2,000 ways not to make a lightbulb; I only needed to find one way to make it work."

Understand where your boss comes from

I sometimes believe that management lives in Plato's cave chained to a wall watching shadows of the real world (not literally, in their beliefs). They believe that the shadows of the wall are the real world. If only they could understand and interpret what is happening. Making sense of all the buzz around them.

Management is trying to make decisions stuck in their idea world, interpreting shadows from actual events

Often the belief is that if you just analyze and think everything through, you will discover the true world. Using deduction and logic. To deduce some premises from incomplete information and form a logical conclusion. Wow, what a glorious way to make significant decisions.

In reality, the approach results in a big fat fail. Come on! You only see the shadows reflected on a cave wall. How can you make responsible, timely decisions based on that? To make things clear, I have lived in that cave.

My take is that management should stop making decisions and instead provide vision, goals and strategy.

Let the persons doing the work, having the best information take the choices at the last responsible time. In the military, they stopped letting commanders make decisions for big cohorts in the medieval ages…

2. Tell your boss that in military history, the victor has always been the side with the best information, the side who can decide at the last responsible moment—the side which can adapt to the situation. Even Zun Tzu mentions this in his five factors. Guess what? That is also built into Scrum! Amazing!

Simon Wardley's Strategy Cycle

But my boss wants to see figures and numbers.

To keep the management happy, you must produce something of value without spending too much time or money on it. The ideal is cheap to create and sustain but can generate lots of money. In Scrum, we have talked about chicken and pigs. Managers talk about cows. Cash-cows. Managers love KPIs and numbers. That gives them something to show to their managers, indicating progress. Don't misunderstand me. The intention behind KPIs and financial follow-ups comes from good intentions. It is just that these methods usually have harmful side effects. Politics, gamification, pressure, and many other psychological effects come into play.

What the manager really wants is predictability. Then the manager can plan, make a strategy from the vision, and avoid pressure from his manager or C-executives. This is psychological safety to them!

We need to help the manager manage upward.

3. Tell your manager: In Scrum, we can statistically and reliably see our velocity based upon historical data. From this data, we can predict how many small, medium, and large stories we can deliver every two weeks, four weeks, or per quarter with pretty good accuracy. You can see how we are doing every day as you pass by our office on the walls! You can have these numbers. No more Gantt charts with baselines, critical lines, coordination, and hundreds of revisions. And you know what? It is built into Scrum! Now, what we want to have from you is an assurance that what we make is of value!

Personally, I am against measuring velocity or estimates. It doesn't say anything about value or outcome. But I see it as a necessary evil. Until management can see the light, they might be blinded, taking their first steps out of the cave.

There is a lot of wisdom in Scrum. Scrum has much management loves built-in. Many managers have read theories about flow, cows, and lean at university.

We need to help management relate to what is good practice to ideas that they know and can understand. We need to translate Scrum into their domain. 

David Pereira  commented when reading :

"Management could work closer to engineering to define how much time is worth investing to solve a problem. Then, the Scrum Team searches for a solution within this time frame. Totally open-ended is also dangerous. But collaboration helps to solve this issue."

Take away

Don't ask managers which pill to take. They will likely take the wrong one. Manage upwards. Help them pick the right pill!

Help managers understand what Scrum is about. Tell them stories they can relate to. Learn your manager's language and challenges so you can tell the story of Scrum in words she can understand. Explain how Scrum can address challenges and contribute to your manager's goals. Ask your manager to share her own goals with you.

Talk to your manager about what you do and why. Build relationships, transparency, and trust. Remember, managers can't read thoughts. Let the manager know what she can do for you to support Scrum. Make them your ambassadors.

Help them out of the cave so they can practice Gemba and make the right decisions. You will make them look good, and they will love you for it.


Created by

Fredrik Carleson

Fredrik Carleson, an agilist, philosopher-hobbyist, tabletop player, and software nerd, has helped deliver software for private companies, governments, and United Nations for the last twenty years in Europe and South-East Asia. Since childhood, his interest in games and philosophy, combined with various ways to deliver software, has begun to converge coherent thoughts of how it all fits together. Fredrik believes methods and frameworks come and go, but good ideas are eternal; we just change the names.







Related Articles