Why Fast Feedback Cycles Matter

When studying software-intensive systems companies, one of the interesting observations is that they all evolve in the same way. In earlier research, we have referred to this as the “Stairway to Heaven”. In the figure below, the speed dimension of the Stairway to Heaven model is shown. This model is a descriptive model based on our research with dozens of companies and it follows a logical sequence of activities. First, starting as a classical company, the organization adopts agile practices. Subsequently, continuous integration is adopted and rolled out in the company. Once continuous integration and test have established a situation where all software is always at production quality, the company will move towards continuous deployment. Finally, it will start to use its deployed products for innovation purposes, for instance through A/B experimentation.

Figure: Speed dimension of the Stairway to Heaven

Although one can easily argue that companies evolve through these levels, the question one should ask is WHY this happens in the first place. Our research has shown that this is because companies benefit from shortening the duration between decision and the feedback on the outcome of the decision. In general, the shorter the feedback cycle, the more accurate the decisions can be as a shorter feedback cycle allows for a more rapid learning loop. In the case of software-intensive systems companies, we have identified six feedback cycles that are sped up when climbing the Stairway to Heaven:

• Development: When adopting agile development practices, the first principle is that the team works in sprints of four weeks or less. This means that at the end of every sprint there will be working software. This leads a development cycle that is much shorter than during waterfall development as all work in progress is wrapped up into complete code every sprint.
• Requirement: The second practice when adopting agile development is that teams conduct sprint planning. This means that for every sprint, there is an opportunity to reschedule requirements and to change the content for the next sprint. This is a fundamental difference from traditional release planning where release content is defined and agreed upon before freezing it until the release of the system.
• Quality assurance: Continuous integration and test allows for much faster feedback on the quality of the system under development as compared to traditional testing approaches. In addition, once the company adopts continuous deployment, internal quality assurance is complemented by quality assurance from the field.
• Governance: Every R&D organization has at least three types of activities, i.e. feature development, defect management and refactoring. Even with the most advanced CI system, there will be defects that slip through and that need to be managed and repaired afterwards. Similarly, the design of the system will erode over time, often referred to as technical debt, and require investment in refactoring to maintain an acceptable design quality. Operating in short cycles allows the R&D organization to dynamically reallocate resources on short notice and for short(er) periods of time.
• Deployment: When adopting continuous deployment, the basic benefit is that our software is rolled out frequently, which provides feedback on the quality of the software. It also provides a solution to the problem where finished features are kept “on the shelf” for far too long without providing benefit for the customer as well as the company that built them. No modern factory would produce goods just to have these sit on the shelf for months at end because of the associated waste, whereas in many software development organizations, that is exactly what happens.
• Value creation: The final cycle is concerned with confirming that the value that we predicted would be delivered by new functionality indeed is created. For instance, a new feature may improve some quality attribute or change user behavior in a desirable way. When using a traditional release model, this feedback becomes available often several quarters or years after the decision to prioritize the development of the feature has been taken. When using continuous deployment, we have access to this feedback in a small number of weeks.

In the table below, we related the stage of the Stairway to Heaven model to the feedback cycles that are shortened at that stage. The key reason why shorter feedback cycles are so important is that companies take opinion-based decisions when the feedback cycles are long as the relation between a decision and its effects is too far separate in time. When feedback cycles are short (such as one sprint), decision processes also become data-driven. In earlier articles, I stressed that for a typical software-intensive company, half of all the features built are waste in that the provided value does not justify the R&D effort that was needed to create the feature. Shorter feedback cycles provide a very powerful solution to reducing that waste.

Table: feedback cycles

Concluding, shorter feedback cycles allow companies to transition from opinion-based to data-driven decision making. That allows allows for a step-function change in the quality of the decisions that are made which, in turn, improves the competitiveness of the company significantly versus competitors that are stuck in traditional ways of working and opinion-based decision making. Climbing the Stairway to Heaven is not a “nice to have” for the R&D organization but rather a critical factor for maintaining the competitiveness of the company.