Retrospectives: Lessons-Learned Sessions by Another Name?
“We already do retrospectives -- we just call them lessons-learned sessions”
22 July 2014
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.
One of the most common comments I receive when coaching or training clients on Scrum is, "We already do retrospectives -- we just call them lessons-learned sessions." While this type of statement is undoubtedly a result of people attempting to make the unfamiliar familiar, it represents a lack of appreciation for how different retrospectives are from the lessons-learned sessions that are hallmarks of traditional approaches to product development.
Most of these lessons-learned sessions are conducted at the end of the project or, at the very most, at the end of a major project phase. The timing of these sessions is problematic, as it often does not allow the team to apply any of their lessons learned to their future work. Because software development is an empirical process, gathering lessons learned at the end of the project does not allow those lessons to be applied to future projects because those projects are different in some meaningful way. Whether it's a different team composition, technology, or domain space, the lessons learned on one project often don't translate to the next one. Retrospectives conducted after each sprint, on the other hand, allow the team to immediately discuss how their process is working and how it can be improved.
Moreover, these lessons-learned sessions do not ask the team to make a commitment to a simple set of process changes. Instead, they generate a long list of potential, unprioritized changes that, unfortunately, rarely get applied. Retrospectives ask the team to focus on and commit to a set of "experiments" whose results can be evaluated, not in some distant future but instead at the end of their next sprint.
Focus and commitment, core to a retrospective, provide an additional benefit. Traditional lessons-learned sessions often erode into another round of the "blame game," with stressed team members, tired after a long project, lashing out at one another in an effort to explain what went wrong. A retrospective, facilitated by a skilled ScrumMaster, allows the team more frequent opportunities to look at their process, relieving the aforementioned stress. Also, the retrospective further reduces stress by allowing the team to immediately change its process in the next sprint. Instead of arguing about how a potential change would benefit an undefined, future effort that may never be executed, the team is able to test out their ideas on real work in the form of their next sprint.
Retrospectives are different from lessons-learned sessions in remarkable ways. Their frequency plus their focus on and commitment to identifying experimental changes to the team's process allow the team to improve in a less stressful, more positive manner. While it is easy to compare them, these benefits make it clear that retrospectives are more than just lessons-learned sessions by another name.
Current rating: 5 (2 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.