Thursday, July 17, 2014

Sprint Retrospective vs Lessons Learned (a generalization).

Whenever I make a post of this nature, I get a bit nervous. The reason is that some of the information presented is based on generalization.

I expect that some readers will use some "concepts" from the Agile Retrospective during facilitation of Project Management Lessons Learned.  As Project Managers learn more about Agile Values and Principles and working in smaller increments, the distinction will become less obvious. 

The chart below is as a comparison only. For those that are looking for a starting point, I hope this will get you started in your discussions.

Sprint Retrospective -  At the end of each Sprint, the Scrum Team meets for the Sprint Retrospective. The purpose is to review how things went with respect to the process, the relationships among people, and the tools. The team identifies what went well and not so well, and identifies potential improvements. They come up with a plan for improving things in the future. All Scrum meetings are time-boxed. The recommended time box for the Sprint Retrospective is one hour per week of Sprint duration.

The Scrum Team improves its own process, always remaining within the Scrum framework.

Source: The Agile Atlas

Project Management Lessons Learned [Output/Input]. The learning gained from the process of performing the project. Lessons learned may be identified at any point. Also considered a project record, to be included in the lessons learned knowledge base.

Source: PMBOK, PMI (Project Management Institute)

Sprint Retrospective (for the team) Project Management Lessons Learned (for the company)
Focused on the Team and their Environment (and organization) moving toward Agile Values and Principles

Focused on "project" learning. Not geared toward improved agility

Immediate in nature

Historical in nature

Team based learning

Project based learning

Intended to remove impediments through immediate action if possible

A "project record" designed to document processes and procedures to repeat actions in future projects

Intended for the team to improve, and ask for help with system or environmental changes

For the Organization or Leaders to decide how to avoid problems in the future

Radiate information related to impediments and improvements needed

Record information with the intent of using that information in future projects

Focus on being SAFE (generally private, especially at first)

Emphasis on reporting and diagnosis vs. "being safe". (generally public)
May be simply to solve inter-team member problems

Not designed for improving team relationships

Celebration of Success

Celebration of Success

Celebration of Learning (known to some as failure)

Build processes to avoid future failure

At the end of EVERY Sprint (cycle)

Typically at the end of a project before the team is split up

Continuous improvement culture

Batch based improvement culture

Designed to "play the game"

Focused on "keeping score"

Focused on building team member trust

Focused on avoiding future failures

Focused on building organizational trust

Focus on future controls

Supports the concept of allowing the team to "self-direct"

Focus on changing controls for future projects

Provides "we need" type information... People focused

Provides "Company will change" type information... Process focused

The chart is presented in such a way as to show the difference of "intent", not to be prescriptive about application or to imply one is correct or not.   However, with the intent of moving toward an agile culture, intent is important to consider. 

An example;

From a Retrospective.  "The team is continually struggling with getting access to the Production Unix Box.  Please fix this for us so we can work more effectively in the next Sprint".

From a Lessons Learned. "The team struggled with Unix System Access which effected their performance."

A Sprint Retrospective is focused on allowing the team to "play the game" and not about "keeping score".

"Status" comes from an observation of the results of the retrospective and how they were handled in the organization.

An example might be "Has this problem stopped hindering the team?").  This focuses the organization on removing impediments to team growth and self-organization instead of creating procedures to be followed.

It is expected that what worked for one team might not work for another. Therefore, it's best to solve a teams impediments "in the moment" and learn from how the organization changes to solve them.

If you would like to keep reading about Sprint Retrospective concepts, check out the following post....  agile42 - Retrospectives that Rock

Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.

Mike Caspar
Passionate About Agile


Sprint Retrospective -

PMBOK, PMI (Project Management Institute)
Project Management Lessons Learned -
agile42 -