In Agile Development feedback cycles play an important role for empirical process control. Feedback cycles are short recurring iterations on time in which a limited amount of work is processed. At the end of each iteration, the teams inspects and adapts their work mode to improve for the next time. This is reflecting Deming’s cycle of PDCA, Plan-Do-Check-Act.
Agile Teams do feedback cycles on various topics, like
* direction of the business requirements
* progress of the product
* maturity of the development process
* technical realizations
* quality of the collaboration dynamics as a team
For example: in Scum, a built-in example for a feedback loop is the feedback on the progress of the product executed by the Sprint Planning (PLAN), where the requirements to be tackled in the next sprint are planned, the implementation during the sprint (DO), the reviewing of the results in the Sprint Review meeting (CHECK) with stakeholders and in the Retrospective defining and deciding on improvements to be done in the next sprint (ACT). This is a closed loop, as all elements of the P-D-C-A-cycle are defined in Scrum.
At the same time with the demo of the next product increment, also the business requirements get feedback: did they change, does the customer/market prefer a different direction, were they right in the first place? These two feedback loops (Product Discovery and Execution) keep each other in balance. That’s called balancing feedback loops.
Let’s have a look at the complex process of building trust in a team. (I definitely will not stress all or even most parts of building a team here….)
That’s what we like to see: as people gain trust (into their team, in the organization, in the development process, in the Scrum framework, in the coach, …), they have more fun at work, they are more willing to cooperate and commit to the team and the work and they are willing to be more trusting. This encourages the behavior of trusting them more, which itself relates into them experiencing more truest, and so on.
This is a positively reinforcing loop of the team’s and the system’s behavior, also called a virtuous cycle.
Unfortunately, reinforcing loops can also lead into negative results, running into more and more negativity each iteration, aka vicious loops. As an example, one might experience resistance to change when introducing Scrum/Agile/anything new. As many people tend to stay in their comfort zone, ideas like “this does not work for us/at our company” might come up. This skeptical view is totally human and valid. If not taken care of, every suboptimal experience (eg. Daily Scrum with everybody rambling on and on about what they did and discussion potential solutions) with the new change might be interpreted as proof that “it does not work for us”. Overcoming hard, convinced, “proofed” opinions against some kind of change becomes harder and harder and a successful implementation less likely.
A typical way to overcome this is to train people about facts and advantages and start to “try it out”, perhaps with a simplified version. Here (small) successful results are essential. John Kotter calls this “generate short-term wins” (step 6 of his “Leading-Change”-process). By that the reinforcing loop gets a spin into the right direction, followed by steps to sustain acceleration of the change, maybe progressing to more or more difficult parts of the change. Eg. for a successful Daily Scrum meeting a good Scrum Master / Agile Coach will train and coach the team, that they focus on the important information valuable to share with the team for meeting the Sprint Goal.