A team ships a feature, then hears that customers find it unhelpful. The next step is not simply to write more code: it is to use that reaction to decide what to change. Continuous improvement keeps this cycle moving for both the product and the way the team builds it. section 1.2.4 section 11.4.1
Keep the loop small enough to act on:
- Develop a change, deliver it, discuss the result with customers, and design the next change. section 1.1
- Let an automated pipeline verify the code. If a quality check fails or the code does not compile, fix it and run the cycle again. section 1.2.1
- Periodically examine the process itself. Use metrics and evaluations to identify a problem, then design an improvement rather than changing an arbitrary step. section 11.4.1
Improve the path to delivery
Suppose builds are slow and handing code off for deployment takes time. Track build and delivery time, review how the pipeline verifies, tests, and deploys, then adjust the process where the evidence points. After delivery, customer reactions—and problems such as an application failing to start—provide another reason to revise the product or its checks. section 11.4.1 section 1.2.4
The develop–deliver–discuss–design cycle shows why delivery is not the finish line: discussion informs the next design. section 1.1
The operational habit is to close each loop. Automate routine checks for fast developer feedback, ship something customers can use, and make time to inspect whether the workflow itself could be better. section 1.2.1 section 11.4.1
