Inspect and Adapt: Close the Loop!

'Inspect and adapt' is a well-worn phrase amongst agile software practitioners. One object of inspection is the software that is delivered periodically - and frequently, if agile principles are applied.

The diagram below shows a simple model of feature delivery. First, a software feature is contrived to address an underlying need. This feature is specified, giving a precise description of the behaviour and properties required. The feature is then developed, and integrated into the overall solution being built. Finally, the feature is inspected.

Inspection may amount to little more than a demonstration to interested parties; it may also entail rigorous verification and validation. Whichever is the case, at this point quality discrepancies¹ may become apparent. We then determine what needs to be fixed, and add this remedial work to our list of things to do. All good and well, so far as it goes, but this seems to be more a case of 'inspect and fix' than 'inspect and adapt'.

What about the source of a given discrepancy: how did it come about in the first place? Can we prevent a similar thing happening again? These questions shift the focus of attention towards our software development system - the organised interaction of people, processes and tools being used to deliver the solution.

Assume a development system that includes a solution stakeholder, an analyst, and a developer. In the event of a discrepancy each can ask in turn:

• Developer: Does the feature do what I intended? Is the feature being used as I expected?
• Analyst: Does the feature do what I envisaged? Are the stakeholder expectations as I understood them?
• Stakeholder: Does the feature provide what I need?

The answers can help locate the cause of the problem. Example: if the developer's answers above are 'yes' to the first question, but 'no' to the second, this suggests an information loss between analyst and developer.

Returning to the simple model of feature delivery, we can see that different issues encountered at inspection may be traced back to different parts of our development system:

With our attention focused on the origin of the issue, we can consider modifying the development system to reduce the chances of similar quality issues arising in future. In effect, we incorporate closed loop control in our development system. Addressing the sources of quality issues moves us into the realm of 'inspect and adapt'.

1. I use the term 'discrepancy' because it is less loaded than 'defect', which is often taken to mean a mistake by the developer, even though the attribution may be premature.