Feb 2019
This article deals with software development in an agile context. What I try to point out is that there are shades of which type of estimation will be helpful for your venture.
You should be familar with Agile.
It is different if you deliver control software for a space craft or developing a new fancy customer driven product. If you press the launch control for your brand new rocket the control software has to be installed, up and running, bug free and you only have one shot. For customer driven product you'll probably need hundreds of shots for one hit.
These two examples are on opposite sides of the same problem. A space craft is completely designed up front and there are few changing parameters. The goal(s) and the parameters for that type of software are not going to change that much (in the meaning of that it doesn't has to suddenly run a bus). This is completely different from customer facing software. Here are requirements changing all the time and often you even don't know what the final product will look like. You often don't have more than a rough idea, a vision.
And there is any kind of software product in between ...
In the end its all about cost.
Sorry for being long, but otherwise it didn't feel complete.
Chapter I: Planning, Details, Changes, Software and Estimation
Chapter II: Stable Requirements
Chapter III: Fixed Deadline and/or Budget
Chapter IV: Long Running Software
Chapter V: Cost of Delay
Chapter VI: Hypothesis Driven Development
Any planning is just an anticipation of the solution and its construction. No matter if you are building a bridge or a software solution.
You actually could build a bridge without a plan. But correcting the mistakes will be a cost intensive undertaking and the results may vary. It is way cheaper to first plan a bridge and then build it. If you consider the life cycle of a bridge, let's say more than 50 years, a planning period of 2 years doesn't really matter.
That's different with software.
A software planned for a 2 years is going to be outdated even before one line of code was written. That might be okay for the space craft which is going to fly in space forever. But is certainly no option for customer facing software. Most software is not meant to last for decades unchanged.
You need the ability to adopt planning to your venture.
No matter if you are building a bridge or creating software. Planning is different to actually building it. There is always uncertainty that your plan will work out perfectly.
Why is that?
Missing information. People often fail to acknowledge that future isn't predictable. Looking back it seems clear what chain of events lead to the current outcome. You only need to know the whole chain of events and voilá the plan works out.
There are two problems with that. Reality is a complex, often chaotic, system where you cannot predict the behavior just by knowing facts about individual parts. You still don't know the behavior of any part, the impact of any decision, in such a system. Even in a moderately complex system there are so many possible conditions that it is practically impossible to gather them all.
So you end up in a model of the reality - an incomplete one. It will be incomplete because it is missing all the details. You could try to gather all information but you'll reach a point where you get stuck in the mass of information and to keep them all up to date.
The map is not the territory.
For most people it is obvious that changing an existing building will cause costs. They have an understanding that enlarging a house will cost more than widen a door. The costs for enlaging a house get higher the higher an existing building is. So they carefully plan the changes and compare the costs of alternatives before starting to rebuild.
The same applies for a building under construction. The more advanced the construction is the more cost intense huge changes will be.
It's the same with software. Depending on your architecture even small changes can give you a headache. This effect has 2 dimensions: how complex your software is and what kind of change you will apply. Because of the intangible nature of software (exept for the developers) its not always obvious what impact a change will have. Even a small change on the interface can often lead to huge structural changes in your software.
The difference between building a house and creating software is that software is dynamic and complex whereas a house is static. Creating software has more to do with a Formula 1 race than with building a house. You plan the whole season, you shift your budget from race to race, you prepare the cars for any race. But when the race happens you can't predict the result because all sort of things can happen. For software this could be missing dependencies, bugs, unknow hardware, unforseen behavior and so on.
One thing is for sure:
There is always change. And you somehow need to deal with it!
To compare software development with building a house will lead you wrong. There are similarities but it's not the same. Software in action is complex because it steadily changes state and is faced with a steadily changing environment. To translate it to buildings this would mean permanent earthquake and moving the rooms instead of elevators.
Software is made of building blocks but these are not comparable with bricks. Because bricks have only limited behavoir whereas blocks of software can be very dynamic. To simplify: Houses can be made of the same bricks building the same flat building the same floor again and again. This is not true for software. There is no repetition of any part (if yes, it is another problem: you violate the DRY principle).
Estimation needs time. Even for software. You need to go through all the details and figure out what impacts changes will have. The more precise the the estimation needs to to be the more time it takes. The more unpredictablity and dependecies you face the less precise your estimation will be.
Software is ment to be changeable. With software the construction can go along with the development. To put it more precisely: for software development it is dangerous to separate architecting and coding.
The agile movement has reacted to that fact with some rituals and processes. And games of course. Whether it is called Estimation or Planning, if it's done with story points, t-shirt sizes or jelly beans doesn't matter. The important part is to regularly dwell upon a few steps ahead in short term cycles. Targeting to a better understanding and share different points of view of your plans. That's what these rituals are about.
Unfortunately this often results in planning marathons to estimate the whole project and make a deadline far in the future.
It's all about waste.
Your map is incomplete, the models are wrong, there is change everywhere and taking the wrong step can cost you a fortune.
You should ask yourself the following questions:
Now you have the metrics for what you really need to estimate and what to measure.
Adopt your processes to reality not vice versa.
This is the comfort zone. Here you can layout a plan when, what and by whom things should be done. You go through the requirements engineering process, let some architects design your solution, predict the deadline and the developers just code it. During the construction you satisfy the stakeholders with some nice demos and powerpoints full of Gantt Diagrams. What you need to measure is just the progress of the development (counting lines of code or, better, stories).
The project goes on until the date of delivery and the final product gets successful delivered. Customers are happy. Stakeholders spend applause. Up to here everything is fine. The money you spent on your estimation was well invested.
But these kind of projects often fail for one reason: there is change.
The most likely result then: Change Management takes over control. While developers are coding the architects create new solutions that make the existing code obsolete. Developers ship an incomplete product just for the sake of the deadline. The customer then is dissatisfied (what surprise). The Ops team are constantly on fire rebooting servers, repairing databases, deleting files from full disks and all kind of that. None of the participants would ever want to be involved in this project again.
The problems with this approach come with the serialization of tasks and their overlapping effects when repeated. While the developers are producing code the change management team prepares all the work for the change. When the developers now start to implement the changes they just have to throw away the work done before. This is waste. The later the project the larger this effect will be and the more waste you'll produce.
Now you have 3 options:
This is called the The iron triangle of planning.
No matter what option you choose, almost all efforts in estimation are waste. All the people figuring out what to build and how produce waste. You only forecast a product which never sees the daylight. The more efforts you spend the worse it gets. No customer will pay for your pile of change management documentation.
The bigger the project the more complicated and error prone is this approach.
As you now have learned about The iron triangle of planning you can circumvent some pitfalls.
You can always make your work visible whatever trade-off you choose. Using a Burndown Chart for example. A Burndown Chart breaks a large project into smaller pieces and makes the state of your project visible at any time. Putting more workload on top of a running project the Breakdown Chart will show you the effects. There still is uncertainty. The higher the workload added is the more imprecisely your chart will be.
To predict new deadlines more precisely some use velocity measurement. I think the term velocity is badly chosen. Because it does not measure the speed, it does measure how good you know your tasks, your software and your dependencies. It can retrospectively show where you got stuck but it is no measurement of future speed. It stays just a guess. That is because you may have done similar things but not exactly the same things. Software development is no assembly belt doing the same thing again and again.
Don't spend too much time to get an exact date out of your developers. Just let them talk about the task at hand and respect errors in your estimates.
Choose wisely: Time, Scope, Budget.
To get better control of especially large and long running software products the concept of milestones was established. It is significantly better than to plan and ship the whole product. The shorter the cycle is the better it works. Delivering features more often will add value to the product earlier which leads to more revenue. This is basically meant with Time to Market.
But there is still a flaw in your estimation. Your project/milestone is assumed to be successful when it's delivered in time and in budget. The customer comes last and may damn your product from the first sight. This can happen at any point in your plan and has the same effects as descibed in "Stable Requirements". Your nice plan can be scrambled in seconds by your customers.
With this approach you focus on doing the things right. But do you know you are doing the right things? With ultra short development cycles you can produce large amounts of waste amazingly fast. It's time to focus on other things instead of development speed now.
Decide: Is time and budget more important than value delivered?
If time to market is critical you want to make sure to deliver the most important things first and as fast as possible. The Cost of Delay approach basically helps you to focus on the next most important thing and get it through the door. Instead of piling up a large amount of assumptions and release them in bundles it ships the thing you believe brings the most value.
This approach really helps in situations of conflicting priorities. In a world full of changes this is daily business. So you need to be fast in making decisions rather than having nice plans reorganized. This piling up does cost money you better spend elsewhere.
You just have bigger Return on Invest earlier when doing it.
The question now is what is the most valuable thing?
Is your most important thing equal to the customer's? Prove it!
If you deliver fast and constant value to your customer you still maybe wondering what the next big thing is. What feature adds big value?
Instead of gut feelings about the customer needs turning to measure the success can drive you to bigger impacts. It is switching from a linear requirements process to a complex hypothesis-driven one. Hypothesis are bundles of options where an unknown number of features really attract customers. You have to find out which ones work and to improve them.
Hypothesis Driven Development depends on A/B Testing done right. This approach requires a completely different skill set than traditional software development approaches. To create a successful business you need to find out what to build first. Building it right comes second. No one cares about good products no one wants.
With A/B Testing the customer decides which features are most valuable. You have to deliver or at least fake a feature and then ask the customer if she finds it useful. The results can't be planned by any chance.
Without planning that approach wouldn't work in reality. But you'll need different tools for estimation and planning. You still need to express to the management what you are going to do. The management wants to know what gets delivered, what does it cost and when it starts earning money. What you can spare out is a detailed product roadmap for the next year or two. The resulting Gantt Diagram will be a lie and wasted time. What you could do is to abstract your hypothesis and to show how much effort should be spent on that at maximum.
"We try to achieve that outcome and will spend a maximum of -amount-of-money-."
This graph is telling you two things about your project:
It's like a transition from effectivness to efficiency.
The Hypothesis Driven Development approach wouldn't be my first choice if I am going to write the control software for a lunar lander. The Waterfall approach I wouldn't use in uncertain environments.
I often miss the flexibility of people/companies to choose the appropriate process before starting a new venture. They often just have "The Process". It always remembers me on Coconut Headphones.
As your projects are changing your processes should follow accordingly.
Are you wondering what to read first?
Chapter I
Chapter II
Chapter III
Chapter IV
Chapter VI
Thank you for reading, I hope you enjoyed.
Sincerely, Maigl
Thanks for reviewing Jens, Susanne, René, Lydia.
