In agile software development feedback plays an important role. Many are aware how feedback supports dealing with changing requirements and adjusting the way of working in teams with retrospectives. But there is more that feedback can do in agile. “An effective feedback cycle in Scrum is more than having sprints and doing retrospectives” says Kris Philippaerts.
At the XP Days Benelux 2014 conference Kris presented the multi-level feedback cycle. InfoQ interviewed him about feedback cycles in Scrum, the importance of doing the full PDCA cycle, deploying feedback in dealing with business requirements and the benefits that that teams can get get from feedback in retrospectives.
InfoQ: Can you explain what you mean with feedback cycles in Scrum?
Kris: Feedback cycles in Scrum, or any other empirical process, are short recurring periods of time in which a limited amount of work/information is processed. At the end of each cycle, we stop working and allow ourselves to inspect our work and improve our process for the next cycle. A typical example of a feedback cycle is Deming's quality cycle: Plan-Do-Check-Act (PDCA).
InfoQ: What makes these cycles so important?
Kris: Feedback cycles are at the heart of empirical processes. Empirical processes are opposed to defined processes by the premise that complex projects, such as an IT project, require continuous adaptation based on new learnings of what we do every day. Complex projects are highly unpredictable and thus require a process that embraces this unpredictability.
Feedback loops give you a way to implement your empirical process.
InfoQ: You mentioned that it is important to do the full PDCA cycle, from P to A. Where and why in your opinion do people struggle to do the full cycle?
Kris: While many people understand the concept of feedback loops, the way they implement them is not always very thought through. In Scrum, for example, we see an obvious feedback cycle: the Sprint Planning, the Sprint, the Sprint Review and the Sprint Retrospective are incarnations of the respective steps of a Plan-Do-Check-Act (PDCA) cycle. But in reality this feedback cycle doesn't necessarily cover the full package. On the level of functional and technical requirements, you will probably get away with this cycle. But what about the product vision? What about the long-term planning? What about team dynamics? These aspects are often half covered and have no perfect out-of-the-box feedback cycle installed in Scrum.
InfoQ: Which feedback loops do you recognize in Scrum?
Kris: The amount of feedback loops is specific to each individual context. For Scrum projects, I identified five common feedback cycles:You can probably add some more, but reflecting on these five cycles will probably be a good first step! All of these cycles need to contain all four steps of the PDCA. Ask yourself these questions: when do you actually plan to work on that particular work type, when do you execute the work, when do you reflect on it and when do you take the time to make improvements?
- The long term vision
- Business requirements
- Technical realisation
- Long-term Planning and Budget
- Team Dynamics
InfoQ: One of the feedback loops you mentioned is "Business Requirements". Can you elaborate about this loop?
Kris: The business requirements cycle is the one that is best defined in Scrum. During the Sprint Planning meeting we plan the requirements we want to implement (PLAN) and during the Sprint we implement them (DO). At the end of the Sprint we show our results to the business during the Sprint Review (CHECK) and during the Retrospective we define action points for improvement that are picked up again in the Sprint Planning (ACT). In Scrum, this loop is closed and very solid. Other loops aren't.
InfoQ: In the technical realization and team dynamics loops retrospectives play a role. Can you explain how they are used, and which benefits teams can get from using retrospectives?
Kris: We see that Retrospectives in Scrum are used to improve the team dynamics, the technical standards and some functional topics. This means that Retrospectives are used in (at least) three different feedback cycles as a CHECK phase. On one hand, this shows the immense power and importance of having Retrospectives: there is so much to talk about! On the other hand, that's also the Achilles heel. Many retrospectives fail because the team wants to discuss too many different topics (technical issues, team dynamics, functional topics, ...) and mix them all together. You will need a strong facilitator to keep the team focused on a limited amount of issues.
The results of the retrospective should then also be directed to the correct follow-up (PLAN) step: technical improvements should go to the next planning meeting, functional improvements might need to go to some kind of refinement meeting and team dynamics issues might require a recurrent team building initiative which is not part of standard Scrum.
InfoQ: If people would like to learn more about feedback cycles, could you give them some advice?
Kris: The best advise I can give is to perform the exercise as it is described in my slides. Go over your own process and identify the important feedback loops that apply to your situation. Then, try to identify how you implement every step of the PDCA for each of these feedback cycles. For the blank spots, take initiatives to implement them.