Empirical vs Predictive Control Processes
Scrum is based upon Empirical Process Control and uses empiricism for evidential based decision making to optimise.
Predictive Control
A predictive control process is a process that describes the steps or phases needed to deliver a solution. The assumption is that delivering software is in a simple problem domain and that the ideal process can be derived to provide satisfactory results.
A good example of a predict and control process is the Waterfall Model[2] where a process is presented and described that, if followed correctly, “…the five steps that I feel necessary to transform a risky development process into one that will provide the desired product.”[2]
A predictive control process can be appropriate for well-known and repeatable problem spaces that can be predicted with a high degree of accuracy such as manufacturing processes for example, where a run of 100,000 duplicate items are to be produced that have been done before.
The difficulty is that most software development is more aligned to product development and producing the first of its kind, and so tends to sit in a complex domain that cannot be so easily predicted. Here, the process needs to be adapted to the empirical evidence.
Empirical Evidence
Empiricism in the philosophy of science emphasises the use of evidence gained through experimentation to gain knowledge over the use of innate ideas or traditions.
Scrum could be viewed as using a scientific method where a hypothesis or question is formed, which may relate to the Sprint Goal. An experiment is designed during Sprint Planning, which is then executed during the Sprint. The results of which are validated during the Sprint Review and Retrospective, and then the hypothesis is confirmed, discounted or refined during Product Backlog Refinement.
This approach uses a repeating experimental cycle to refine the end solution towards the actual needs and capabilities rather than those perceived at the outset.
The approach can be open ended and ambiguous to start with, and may need a few cycles to provide something meaningful, however, the cost of experimenting and providing an accurate solution is arguably much cheaper than predefining the solution and then finding out that it is deficient, as with a predict and control process.
An empirical process is great for exploring complex problem spaces to find a solution that is based upon the evidence, suits the needs, and works well to provide something that may not be definable at the beginning.
Empirical Process Control
Scrum is based upon the Empirical Process Control model, which relies upon three pillars: transparency, inspection and adaptation as a form of process feedback control. A key differentiator of Agile is the ability to make good decisions and act on them without any distractions or delays.
Transparency
All information is expected to be transparent and visible for those that are “…responsible for the outcome…”[1] to make observations and derive clear decisions. Clear and explicit standards are also expected so that the information can be understood.
The intention here is to make the data visible in an open and honest way so that it can be objectively inspected and good decisions made. If there is little transparency then it is much more difficult for teams to adapt effectively and appropriately.
Artefacts that improve transparency include the Product Backlog, Sprint Backlog and the Increment, which if done well, show what is done and what is not done and where the adaptation needs to be made.
Inspection
The information relating to a project process should be inspected regularly to detect any variances from the Sprint Goal or unexpected outcomes as soon as possible in order to take appropriate action or course correction.
There are several formal opportunities in Scrum to inspect the data and adapt, and include:
- Sprint Planning to inspect what can be done to meet the Sprint Goal
- Daily Scrum to inspect the progress towards the Sprint Goal
- Sprint Review to inspect the Increment, the “Done” work and what the successive Sprint objective should be
- Sprint Retrospective to inspect the team and their process to produce the work
Adaptation
The process or material being inspected should be adjusted with respect to the feedback to prevent any further deviation. Adaptation is acting on the observations and the decisions made when inspecting, and making course corrections towards the goals.
Common activities for adaptation include:
- Product Backlog Refinement activity to adjust and curate the Product Backlog with what is currently known about the product and the value it provides
- Daily Scrum when the Development Team adapt their approaches as they work towards the Sprint Goal
See Also
References
- Scrum Guide
- Managing the Development of Large Software Systems, Royce W.W., Proceedings IEEE WESCON, August 1970
- Empirical Process Control, accessed 16 August 2017