Photo by Ryan Graybill on Unsplash

What is an Agile Retrospective

Agile Scrum uses retrospectives to enable continuous improvement. Agile leverages the team’s wisdom to improve the project - especially with delivery efficiency and product quality. The standard form of an agile retrospective is a 60 minute team meeting at the end of a sprint, after the sprint review and demo. All team members are invited to this meeting, the Product Owner can optionally attend.

The Scrum Master typically facilitates this retrospective, but any team member can voluteer to facilitate. The team gets together and reflects on the previous sprint. How did it go? Was the sprint commitment achieved? Could more have been done? Were there a lot of issues or blockers?

There are many workshop type exercises that can be run to inspire creative thinking, but a standard exercise is to have each team member reflect on the previous sprint and identify what is going well, and what needs improvement.

Each sprint can be viewed as an experiment. At the end of a sprint, the experiment is evaluated. The team as a whole learns from it. (Cohn, p. 283)

The objective of the retrospective is to decide on one or two improvements to make for the next sprint. These might be team norms or working agreements that the team agrees to uphold, or a change to the definition of done.

Lessons Learned

If you’ve worked on a waterfall project you’ve likely participated in a Lessons Learned meeting or exercise at the end of the project.

The knowledge gained during a project which shows how project events were addressed or should be addressed in the future with the purpose or improving future performance (PMI, p. 544)

In my opinion ,the traditional *Lessons Learned * meeting is a great idea, executed poorly. It makes many false assumptions. The one that strikes me is the idea that future projects will leverage lessons from previous projects. This is never the case. Projects are very different from one another, and this makes many of the lessons irrelevant.

The other assumption is that the lessons learned will be stored in a repository that future projects draw upon to help with planning and issues that arise during execution. I have never seen a Project Management Office (PMO) with a useful lessons learned repository that helps projects learn from each other. Project Managers also seem to want to run projects their way, so even if a great data source existed, it would likely not be used.

Agile Retrospectives vs Lessons Learned

The objective of the Lessons Learned meeting and the Agile Restrospective are the same. The big benefit of Agile Retrospectives is that they occur after every sprint. Throughout the project. For example, if a sprint is 2 weeks long, the lessons learned are being discovered and addressed 2 weeks into the project. The findings are also highly relevant because they are coming from the project itself.

Problems are more easily solved when addressed early. If there are issues in team dynamics, I go through an exercise of outlining what team members expect from one another. I find that allowing the team to vent about problems helps team members adjust to how to work with one another and to set expectations.

Some time should be focused on the activities and behaviors that are working well for the team. Make sure the team doesn’t lose sight of practices that are helpful. Lessons Learned meetings rarely identify the positives in projects, but strengths are much easier to build on than weaknesses are to fix.

Tips for Retrospectives

As facilitator of the retrospective keep in mind that its purpose to is improve work processes, not to try to change people. If there a personality conflicts, the retrospective is not the place to deal with them. Keep the focus on team expectations, and the process the team is using to get the work done.

Photo by Headway on Unsplash

In software projects there is always a tension between development and quality assurance. You may want to focus in on the hand-off of dev work to QA. Encourage testers to share their test cases with dev. QA is a success when testers can’t find bugs.

Sometimes testers measure their value by how many defects they find. This is not successful QA. Encourage developers to be part of QA as well, what practices can developers use to ensure their work is high quality before testers review it?

The early sprints are good chances to run focused retrospectives that will make a huge difference to the long term health of the project. Don’t be afraid of taking on the tough issues. Be unwavering in your commitment to resolve them.

There are numerous engaging activities that help stimulate ideas in retrospectives. Each activity is worthy of its own post. Some that come to mind are:

• Went Well, To Improve
• Start, Stop, Continue
• Sailboat Retrospective
• Mad, Sad, Glad
• 4 Ls (Liked, Learned, Lacked, Longed For)
• SWOT Analysis

Summary

The Agile Retrospective is so valuable that I would use it if I was running a waterfall project. Every 2 weeks I would gather the project members and reflect on the project. I would hold a Lessons Learned throughout the project and address issues.

Agile Retrospectives are about achieving continuous improvement. Agile Scrum and Lean manufacturing (Toyota Production System) hold this principle. This quotation from The Toyota Way sums up the spirit of the Agile Retrospective:

The Toyota Way can be briefly summarized through the two pillars that support it: “Continuous Improvement” and “Respect for People.”

More important than the actual improvements that individuals contribute, the true value of continuous improvement is in creating an atmosphere of continuous learning, and an environment that not only accepts, but actually embraces change. (Liker, p. 9)

Sources Cited

Project Management Body of Knowledge, Fifth Edition, Project Management Institute Succeeding with Agile, Software Development Using Scrum, Mike Cohn, Addison Wesley 2010 The Toyota Way, 14 Management Principles from the World’s Greatest Manufacturer, Jeffery K. Liker, McGraw-Hill, 2004