- Pertaining to or based on experience.
- Pertaining to, derived from, or testable by observations made using the physical senses or using instruments which extend the senses.
- (philosophy of science) Verifiable by means of scientific experimentation.
(definition taken from en.wiktionary.org)
In engineering there are two kinds of process control. Defined process control deals with processes which are repeatable and fully understood in detail. Empirical process control deals with processes which are either not fully understood or are naturally very variable.
One of the key insights of an Agile approach to software development is that building software is complex and unpredictable business and so it is best handled using empirical process control.
So what is Empirical Process Control?
To achieve empirical process control you need three things: transparency, inspection and adaptation.
In order to be able to control a complex process, you need transparency – you need to be able to see what’s going on.
Driving a car is a complex control process. When you’re driving you need to be able to see through the windscreen.
When you’re controlling a complex process, like driving a car, it’s not enough to be able see what’s going on. You have to actually look. You can have a nice clear windscreen but if you’re not looking out of it, if you’re not paying attention to what’s going on, then you’re still not going to have a very effective control mechanism in your car.
You need to able to see out of the windscreen (transparency), you need to actually look out of the windscreen, but then you also need to modify what you do in relation to what you see. See an obstacle in front? Slow down. See an empty road? Speed up. See a sharp bend? Slow down and turn the steering wheel.
When you talk about driving in this way, it’s obvious how the pillars of empirical process control – transparency, inspection and adaptation – apply. But how are they achieved in software development?
Let’s take a look at how empirical process control is realised in one of the most popular Agile frameworks: Scrum.
Transparency and inspection: stand-ups, showcases and retrospectives
The basis of transparency in Scrum is the ‘stand-up’. This is short meeting of the team every day. People involved in the project say what they’re going to do today and what they did yesterday. They also highlight any problems which are preventing them from doing what they intend to do.
In Scrum there is a role of product owner. The product owner acts as a single representative for the organisation that wants the software being developed by the development team. At the end of each sprint (a short, fixed period of time for which work is planned, typically two weeks) there’s a meeting called the ‘showcase’ entirely for the benefit of the product owner. In the showcase the team demonstrates working software that its developed in the recent sprint. The showcase makes transparent to the product owner, how the team is progressing.
At the end of each sprint the team runs a ‘retrospective’ where they ask themselves, what went well, what didn’t go so well. They come up with ideas for things they can try to improve the team’s performance. In terms of empirical process, the team is inspecting their performance and another way to think about this is that at the end of each sprint, the team members asks themselves and their passenger – “how’s our driving?”
Adaptation: making changes in response to what you see
Planning in Scrum happens not just once, but frequently: at the beginning of each sprint. This means the product owner can adapt what the team is going to do having looked at working software. If the software is right, the team can carry on going in that direction. If there’s a problem, the product owner can modify what the team should do next. By running retrospectives and acting on their findings, the team is also adapting.
What are your thoughts? Leave a reply below or contact me by email.