Empirical process control is a technique used when the complexity of activities means a defined process control cannot be employed.
Empirical process control has three key fundamental elements underlying its implementation:
Transparency requires all aspects of the process must be visible to those who are controlling the process and that those aspects represent a true measurement.
Aspects of the process must be frequently inspected to allow for variances in the process to be detected and the person performing the inspection must have the skills to assess what they are inspecting.
Based on the inspection, the inspector will identify that certain aspects are not within acceptable limits and will apply adjustments to the process. It is vital adjustments are applied immediately.
Where do you apply an empirical process?
Empirical approaches are applied to situations where there is complexity in the problem domain and following a prescribed algorithm is no guarantee of results.
The simplest example of empirical process control in practice is a temperature control thermostat found in most homes. It relies on an accurate temperature reading of the room that can be frequently inspected. If the temperate drops below a predefined comfort level, then the temperature of the room is adjusted by applying heating.
Another frequently experienced everyday scenario can be found in many gyms. Each month a fitness trainer will agree a plan for the month with their client containing diet and exercise prescriptions. At the end of the month the client will be weighed and tested. Based on the result a new plan will be created and the cycle repeated.
In software development, the nature of product development is affected by uncertainty in people, requirements and technology. Most software projects tend to be novel and the true need cannot be fully specified up front. An empirical approach allows the team building the product to build a little and to check that it is progressing toward what the customer needs.
How is scrum empirical?
Scrum delivers a transparent, potentially shippable increment (working software) that is frequently inspected at a minimum once per month by the scrum team and stakeholders. Based on a review of the increment the product backlog is adjusted.
Additionally, the performance of the team and processes are also made transparent and are inspected at the same cadence in the sprint retrospective. Continuous improvement is achieved by adjusting how the team works from a communication, process, and quality point of view by planning improvement for the next sprint plan.