Pattern: Learning Loop
Building feedback collection into the delivery process closes the loop between engineers and the people who use their products, putting the customer at the center of the product development cycle
A company is working to transform its culture to align with the delivery approach required by cloud native’s distributed architecture of containerized microservices delivered via the cloud.
In This Context
Learning happens in a three-part cycle: goal-setting, execution, and reflection. The first stage is identifying a challenge or problem and devising a likely solution. The second stage is carrying out the plan until it succeeds or fails. The third is studying the result—thinking back over what happened and how it worked out. In avery long delivery process this cycle is of limited use when lessons learned can be applied only months later, when the information is not fresh in the developer’s minds or perhaps no longer relevant.The learning loop is useful in an organizational context only when it is closed(one stage leads directly to the next and the next, then the cycle repeats).Most companies adopting cloud native cite increasing product velocity as their main motive.Tightly coupled Waterfall-approach release cycles may be as long as six months to one year, or even two.
Therefore
Build mechanisms for collecting user feedback and feeding it rapidly back into the delivery cycle, enabling responses to flow back from the customer so the business can make better-informed decisions.In cloud native, organizations can make extremely effective use of this three-part learning cycle as a feedback loop to developers that allows for fast iteration and adaptation to changing market conditions and customer needs. When a team is building its piece of an application and deploying it quickly and frequently to production, the team’s work gets in to users right away. If client feedback is collected at that point, itcan be fed directly into the reflection stage for the team to take into consideration as the loop repeats and the team sets goals for its next work cycle.Use the feedback to create the changes customers are telling you they want.Not collecting feedback decreases the value of cloud native’s shorter time to market.
Consequently
Apply Data-Driven Decision Making to cloud native’s rapid delivery cycle so that the output of the system continually goes back in to improve the system (you can go fast without breaking things).
- Developers capture the momentum of improvements, leading to more improvements.
- Observability is complicated and needs to be carefully engineered to provide the right insights.
- What customers want is not always feasible or cost-effective.
