Feedback Loops

HSD is a balance between pragmatic lean governance, lightweight iterative and continuous processes with proven organizational patterns and is indicative not prescriptive. HSD is a balance between pragmatic lean governance, lightweight iterative and continuous processes with proven organizational patterns and is indicative not prescriptive. HSD is evidence based, using feedback wherever possible to improve quality. For this reason, quality assurance and verification is expected to be built into every activity. We strongly recommend, phased, iterative, agile or continuous delivery models as these approaches build corrective feedback activity into delivery methods.as these approaches build corrective feedback activity into delivery methods.

Simple iterative feedback loops

HSD is not a simple linear development process and the H-Model is iterative at a number of different levels. At the lowest level, team based development processes are iterative providing the smallest (and fastest) feedback cycle. These feedback cycles are good for correcting product development, but cannot directly change strategy by themselves, they must be connected to higher level feedback cycles.

The biggest, and normally slowest, feedback cycle in an organisation is around its strategy. Strategic goals are often measures in years, and so the impact of strategic choices and therefore the opportunity for feedback to change what an organisation is doing may be slow. However, the ability for organisations to change is limited by this strategic feedback cycle and the quality of its situational awareness.

These various feedback cycles feed each other, both upwards towards strategy, and downwards towards delivery. One-way influence is dysfunctional, and no longer a feedback loop. Such models can be considered top-down design with constantly changing direction, or simply upward reporting stacks. Well intentioned attempts to achieve feedback loops outside of team based iteration often fall back into one of these dysfunctional models undermining iteration at other levels of the business.

A team that is sprinting well but out of alignment with strategic direction is pointless. Changes in strategic direction that don’t affect what delivery teams are doing are equally pointless.

Large predictive organisation iterative cycles

Complex organisations, based on the Hybrid Dynamic Model, will have top level feedback cycles pulling on a variety of lower level feedback cycles that look a lot like combinations of the “Simple” and “Large” stacks described above under a single strategic context.

Complex organisation, hybrid dynamic feedback cycles

Inside the iterative/continuous delivery feedback loops are even smaller and quicker feedback loops around Personal Builds and Team Builds, not to mention development practices such as Test Driven Development and Pair/Mob Programming that move feedback even earlier in the delivery process.

At each layer of the H-Model moving upwards, feedback is typically slower as more work has to be done before higher levels of integration activities and examination deliver higher levels of completeness (based on a set of Definitions of Done). However, feedback loops are critical to ensure that the business is going in the right direction and delivering business value. The most effective form of feedback is embodied by the Go-See practice.

Feedback improves quality and efficiency. Feedback ensures that the right systems are being built. We recommend that feedback is built in to every activity. Customers must be actively engaged both in requirements decomposition and elaboration (on the left hand of the H-Model), as well as in verification and acceptance activity (on the right hand of the H-Model). Team based feedback can be encouraged via team Retrospectives, the Go See practice and the Bubble Up practice - all described in the Metrics and Reporting View.

Smaller feedback cycles find issues earlier and reduce the amount of potentially wasted work, so we recommend short iterations (or continuous flow) at delivery level with customer involvement throughout. As described in the Requirements View, we do not consider requirements derived in isolation from customers to be true requirements.