The Power of Positive Feedback
15 June 2017
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
A typical retrospective: The ScrumMaster asks what went well. The team writes things on sticky notes. The ScrumMaster asks about the things that did not go so well and need to be improved. The team writes even more things on sticky notes. Then the ScrumMaster asks the team to dot-vote on the topics they want to explore further. The team distribute their dots almost exclusively on "problems." The rest of the time is dedicated to problems. And another opportunity for learning is successfully wasted.
This way of doing a retrospective is based on a common misunderstanding. Many good books about retrospectives tell us that the classic approach to a retrospective is the following: After setting the stage, we gather facts, generate insights, explore options, and decide on them. Then we close the retrospective. During all this, the team decides which topics will be discussed.
All of this is correct. Nevertheless, it often leads to us struggling for hours with deficits, being frustrated and having the impression that nothing ever gets better. Most of us grew up with our mistakes being criticized to make us improve. A Scrum Team, on the other hand, is not a reformatory but a self-organizing learning community. And self-organized learning is mostly based on positive feedback.
As adults, we start to learn a particular new skill because we have an interest in it. There's something we want to get out of it. After that initial motivation, our success will largely depend on positive feedback. The more we get out of our new skill, the better it works the more we are willing to invest. If all we ever get are failures and criticisms, we will quickly drop the thing and forget we ever wanted it.
Systems thinking tells us a similar thing about intervention in complex systems: Instead of trying to control or stop the undesired tendencies, the systems thinker will amplify those aspects that work well and invite the system to shape itself around them even more.
How can we implement that knowledge in retrospectives? Boris Gloger explicitly stresses the point that the part about "which processes went well?" should be separated from the part about "what could be improved?" The purpose of that separation is to make the strengths of the team visible for themselves, without being clouded by negative aspects and problems. The ScrumMaster can help the team focus on its strengths, identify its sources, and dwell a little on what they so often lightly skip. The focus on the team's strengths allows them to develop future strategies based on those strengths.
Many ScrumMasters bring into the retrospective their own observations, which they offer to the team as possible topics. If the team is unable to identify their strengths, the ScrumMaster can do that and ask the team for confirmation. This way the team can start to develop a culture of positive feedback that enables the team to learn.
Esther Derby and Diana Larsen. Agile Retrospectives: Making Good Teams Great.
Boris Gloger. Scrum: Produkte Zuverlässig und Schnell Entwickeln.
Current rating: 5 (1 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.