Scrum is an Empirical software development management system
Although the Scrum Guide does not contain that term. Emperical processes by definition contain these elements:
- Visibility
- Inspection
- Adaptation
These attributes did not start with Scrum, they are control system terms
Let's look at a non-software development empirical process control system
We want to design a process control for a hot water system for an industrial process. We have chosen two simple attributes - the level of the hot water feed tank - so we need a pumping system to keep the water level at the desired level. This in turn keeps the head pressure at the desired level for the users of the hot water. The temperature of the water when it arrives at the point of need. This type of closed loop control system is seen on many towns across the US, where Water Towers are used to produce the water pressure at the desired - usually 65 PSI - for the residents, by pumping the ground water to a height of the tank then releasing it on demand for the residents. Let's ignore the temperature aspects for the moment and just focus on keeping the tank full
We would like to model this system before we build it to avoid spending our customers money more than once. There are two simple ways of modeling the system.
- An empirical method of step testing the process - for the water tank example an empirical model between the controlled and manipulated variables can be developed by collecting and analyzing process data gathered under controlled open loop conditions by stepping through the manipulated variables.
- An analytical methods using material and energy balances - for the water tank example an analytical model can be built using the Mass In and the Mass Out.
The empirical model looks like this.
The water tank level is held constant by equalizing the water flow out and the water flow in. The flow out is changed nm a step wise manner and the level response is observed. A series of step wise changes are made and the response is observed. As the level changes - and acts like an integrating or ramp process - the average time delay and gain (in percent of level change per percent of water added) can be calculated to produce.
The analytical model looks like this.
What Does All This Mean for Sofware Estimating?
Managing software development is a Control System. We have a steering target - the tank level - in the form of needed capabilities, a planned delivery date, and a planned budget for the delivery of the needed capabilities at the needed time. If you have no planned budget, planned delivery date, or needed capabilities, you have an open loop control system - just keep spending till the money runs out or the customer tells you to stop. No need for a control system, no need to estimate, just code, someone else will look after the business side of your spending.
But let's also pretend for a moment that those providing the money have a fiduciary obligation to know something about how much it will cost to produce the needed capabilities (Value) and some need to know when those Capabilities will be ready for use, so they can start earning back their investment. This is standard Business 101 time phased Return on Investment. And let's pretend that the development of the software is not a deterministic system. That there are uncertainties in the system. Uncertainties from lots of sources, some you can control and some you can't.
Then what does a model of the control system look like? It can be empirical or analytical, or a combination of both.
It needs to be both for some simple reasons:
- Using empirical data in the water tank control system relies on the physics of the system. Pump water to the top, it builds head pressure to be used to remove water from the tank when the valve is opened. The laws of physics don't change over time from this system.
- Using empirical data for managing the development of software - empirical data alone - makes the assumption - A BIG ASS ASSUMPTION - that the future is like the past. Like the water tank example.
This of course is NEVER true in software development. If it were true developing software would be a mechanical process, done by machines. And it's not.
So while empirical data is useful, it's not the only thing needed to manage the project so you can show up at or near the time needed, when at or near the planned cost, and at or near the needed capabilities, so the business can fulfill its business model.
An analytical model is also needed, fed by empirical data.
Both are needed, full understanding that the future is never like the past - and analytical modeling must include the probabilistic aspects of the future - possibly derived from the past.
So when we hear - Scrum is an empirical process, (it is true) but think a bit more on what that means. When we hear #NoEstimates is an empirical process - which it's not because it's open loop, with no steering target (a set point in the control systems paradigm), and no consideration for the probabilistic aspects of writing code for money - someone else's money.
Ask a simple question - if you use the word empirical - do you have a notion of the control system model in which that empirical data is used? Or is the term empirical data just a word used without any meaning to the problem at had.
That problem at hand is how to forecast (estimate in the future) in the presence of uncertainty about things meaningful to the business paying for the software. This means cost, schedule, and technical outcomes.
How can that be done using empirical data and NOT call that estimating?
It can't!
For some software focused background of control systems see this simple starting point
