Get certified - Transform your world of work today


Retrospectives: Lessons-Learned Sessions by Another Name?

“We already do retrospectives -- we just call them lessons-learned sessions”

22 July 2014

Michael Stuedemann

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.

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.

Article Rating

Current rating: 5 (2 ratings)


Marcelo Lopez, Jr, CSP,CSM,CSPO,REP, 7/22/2014 2:37:02 PM
Michael: Very nice article. Very nice. With my teams, I like to inject "lessons learned" as a "4th" to our form of the "3" in standups, because learning is something I feel we should be doing every day, and so I drop in that little tidbit into their thought patterns.

It, in many ways, has helped us prepare for retro's. Also, briefly talking/thinking about "lessons learned" in smaller chunks has, in fact, stunted (I won't say eradicated) some "blameshiftmanship" (I know, that's not a word, someone on our team just invented it one day.) that had occurred in the past.

It is indeed remarkable how retro's evolve when you make small adjustments to focus on conversations about improving ourselves as a group, and building better understanding between team members.
Tim Baffa, CSM, 7/24/2014 4:27:54 PM
Good article.

Even the title "Lessons Learned" implies negativity and seems to facilitate a laundry list of everything that negatively impacted the project with little discussion around remedies.

Retrospectives are great because of their frequency (feedback loop), the emphasis on team building, and what can be tried to improve from sprint to sprint.
Anonymous, 7/25/2014 2:17:25 PM
Great points Mike! Thanks for highlighting additional ways in which Scrum is different from traditional ways of doing work!
Sandeep Lad, CSP,CSM, 10/13/2014 10:56:24 AM
Wonderful article Mike. Very thought provoking. One point I would want to highlight is that frequently traditional projects do not even do the Lessons Learned sessions, because by the time the project is 'over' the project team is already exhausted and is ready to move on to the next venture and see no value for themselves in conducting a lessons learned session. Often the organization has to expend additional time and energy to assemble the project team together to perform the lessons learned session and 'update organizational artifacts'.
Michael Stuedemann, CST,CSP,CSM,CSPO,REP, 10/29/2014 9:32:59 AM
All - Thank you for the feedback and the comments. I especially like Marcelo's comment above regarding ensuring that we don't just limit our discussion of how we can improve as Scrum Teams to the Retrospective ceremony, but constantly and continually focus on how we can deliver more value to our customers.

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.



Newsletter Sign-Up