The lying game — why is it so hard to focus on goals?
Lies, damn lies, and estimates
“You must unlearn what you have learned.” -Yoda from Star Wars
We learn a sublime anti-pattern from an early age, leading us down a slippery slope away from the Agile Manifesto.
Perhaps that is why according to an HBR article published three years ago:
Less than a fifth of firms gave themselves the top rating in achieving the breadth (13 percent), depth (13 percent), or consistency (18 percent) of use needed to unleash its [Agiles] full potential. — Survey Data Shows That Many Companies Are Still Not Truly Agile (brackets added by author)
Two decades after the Agile Manifesto, most companies realize the benefits theoretically but have problems putting them into practice.
I believe one reason is that we are stuck in old patterns. We focus too much on the means and too little on the end goal.
Would you mind allowing me to elaborate more on what I mean?
The system teaches us from first grade in school that delivering output and meeting deadlines is the alpha and omega. In the 20th-century, companies functioned in a complicated or apparent world. In this environment, careful analysis and planning gave you a competitive advantage. Today, we live in a complex and chaotic world. Agile organizations will outcompete companies making detailed analyses and plans. Why? Because they can experiment and identify working patterns more or less in real-time.
Still, we have it in our mother's milk to carefully plan with a flawless analysis to get a good rating. We have been rewarded for this our entire life. We bring this mindset to work.
For me doing estimates is at the center of analysis and planning — so we should eliminate it to break the pattern. Estimates are not relevant.
I am on a quest not to work with estimates, perfection, or analysis paralysis. Somehow this turned me into a repetitive parrot. Or maybe a watchdog — whenever anyone says words such as "commitment," "promises," or "deliverable," the parrot in me squeal, and the dog growls:
-"We should not focus on what to deliver at which time but on which goal we wish to achieve! "
I had hoped the old saying "on time and budget" would die with Agile principles.
We all know we can't give proper estimates or deadlines. Still, we play this stupid game where we want promises, commitments, and plans. Despite everyone knowing it will be wrong.
Everyone plays a lying game, and everyone is fully aware. The problem is that this is a lose-lose game.
The typical scenario is a manager asking how long it will take to complete a feature. Usually, the person required to estimate will resist, knowing that the answer will become a commitment. Eventually, a number will come, let's say two weeks.
Depending on the team's experience, technology, requirements, dependencies, uncertainty, etc., the fluctuation on how long time finishing takes can be 50% to 300%.
The manager then has to report the estimate to someone further up the hierarchy. Knowing that they will have to promise or commit to a deadline, an experienced person will multiply by pi.
Hereafter a few things can happen. One feasible scenario is for sales to freak out and scream that we can't charge the customer so much, saying you will get two weeks. Alternatively, knowing about the pi constant, the weathered manager cuts the estimate to one-third of the suggested time, setting a fixed deadline from today's date.
Sometimes teams even play this game against each other to protect themselves. In this blame game, one player demands a promise from other developers to deliver dependent functionality.
So everyone plays a lying game, and everyone is fully aware. The problem is that this is a lose-lose game.
When things go wrong, we focus on finding better estimation techniques instead of the root problem.
So what are the consequences of this game from an Agile perspective?
Consequences of the lying game
The enormous consequence is that we are on a slippery slope undermining the Agile Manifesto.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
- https://agilemanifesto.org/
Let's look at some of the implications and then the effect:
- We focus on understanding how the estimation process went wrong to understand the late delivery over recognizing the complexity of collaboration between individuals.
- We tend to forget what problem we wish to solve and instead focus on deliverables. For me, a working product is functional and adds value.
- We lose trust. No one believes in the estimates — they are part of a game to make up deadlines. Focusing on "promises" to deliver on time and fixed scope leads us into the usual trap of reducing quality. Also, at the deadline, we risk contract negotiation as the focus will be on whether we deliver promised functionality over solving a problem together.
- We don't want to respond to changes as that risks the plan.
In short, we begin focusing on the output rather than the outcome. When committing to what functionality to deliver, the focus will be on production and delivery on time on budget. Not if you solved the business problem. And that is silly because we all know no one can control the scope in Software development.
What should we do instead?
To understand what we can do, we need to first look at what we usually can control — which is:
- How many persons do we have available and
- For how long
If you can control the two, I claim you have a dream scenario for a manager or a committee — predictability. You will know precisely the cost and time without any fluctuation from the two.
Does this work in reality? It does. Let me give an example.
At a previous place I used to work, we timeboxed all development. Anyone could submit a business case requesting time and people. If prioritized, persons were assigned to work on the case for a fixed time, usually two sprints.
We never promised what we would deliver; we just promised to work as hard as possible on the highest prioritized User Stories. After a sprint or at the end of the timebox, we moved everything Done to production.
Our customers always knew how many persons they had available for how long time. They knew these persons were entirely available and focused on helping them deliver something of value.
Secondly, we should focus on the goal and what problem to solve.
The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. - The Scrum Guide 2020
When focusing on the business problem and goals, what items we deliver are no longer critical. What is important is the value and whether we solved the problem.
How long time will the problem take to solve? We honestly can't say.
We can only promise to inspect and adapt at specific intervals to see how far we have come. We can only promise to deliver new functions as fast as possible. Once provided, we can know the value of a feature. The faster we make features available, the quicker the feedback loops. That minimizes risk and prevents us from going too far down the wrong rabbit hole.
Let me give a practical example. At the beginning of my career, I created an online procurement site for the United Nations. Every day I asked the procurement officers what problem to focus on fixing. I listened, made some changes, and showed them what I had done. Every day, we published some minor improvements. The differences were not very noticeable daily, but the change was immense per month.
For me, the scenario above is also a dream scenario for a manager or a committee. They will know day by day if something helpful is delivered. When we reach a goal, we set new targets or goals. Or, if we cannot prove the business value after a timeboxed period, maybe that is proof the hypothesis was wrong, meaning we should try something else.
To summarize. Some inherent beliefs we bring as luggage make it challenging to implement Agility at full speed. We need to know which fundamental ideas we carry with us, throw them away to break the thought pattern, and embrace the Agile Manifesto in practice.
In my opinion, a critical factor is removing estimates. To paraphrase Yoda:
Estimates are the path to the dark side. Estimates lead to false commitments. False commitments lead to lies. Lies lead to suffering.
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value.- The 2020 Scrum Guide
Do you want to write for Serious Scrum or seriously discuss Scrum?
