Lessons Learned and Retrospective

In order to maintain continuous improvement on your project it is important to take a moment to pause and reflect. Two key components of this reflection process are Lessons Learned and Retrospectives.

These practices help teams learn from their experiences, celebrate their successes, and address any issues that might have popped up along the way.

Lessons Learned and Retrospectives serve different purposes and operate at different levels. So, let’s dive into what these concepts entail, how they differ, and why they are important.

Lessons Learned

Lessons Learned refers to the knowledge gained from experiences during a project. It encompasses what went well, what didn’t, and the insights that can be applied to future projects. The primary purpose is to document these experiences to prevent the same mistakes and replicate successes. It is usually conducted at every significant milestone on your project.

Lessons Learned Repository is a centralized database for storing the lessons learned from a specific project. For example, after completing a mobile application project, the software development team identified several issues and successes. They documented lessons learned, such as:

1) Issue: Unclear requirements led to rework and delays.

Lesson Learned: Implement a requirements-gathering workshop with stakeholders at the start of the project to clarify expectations.

2) Issue: Late-stage user testing revealed major usability issues.

Lesson Learned: Conduct user testing at multiple stages throughout the development cycle to catch issues earlier.

3) Issue: Communication breakdowns between developers and designers.

Lesson Learned: Schedule regular cross-team check-ins to ensure alignment and facilitate collaboration.

Lessons Learned Register is a broader organizational tool that collects and organizes lessons learned across multiple projects. It serves as an organizational knowledge base.

Retrospectives

Retrospectives are reflective meetings held at the end of a project phase or iteration, particularly in Agile methodologies. The goal is to evaluate the team's performance, discuss what worked, what didn’t, and identify areas for improvement.

Differences Between Lessons Learned and Retrospectives

While both processes aim to improve future project outcomes, they differ in scope and focus.

• Lessons Learned is often a more formal, comprehensive review that can be documented and referred to for future projects. It typically results in a Lessons Learned Repository for a single project, capturing insights that can be shared and used in upcoming initiatives.
• Retrospectives, on the other hand, are generally more informal and focus on immediate past experiences within a specific time frame, such as a sprint in Agile. The outcomes of retrospectives typically lead to immediate action items for improvement in the next cycle.

When to Conduct Lessons Learned and Retrospectives

Both Lessons Learned and Retrospectives should be conducted as part of the closing activities for a project or phase. This ensures that all insights and experiences are captured while they are still fresh in the team's minds.

For Agile teams, retrospectives are typically held at the end of each sprint, allowing for timely reflection and adjustment to processes before moving on to the next iteration.

Conducting Lessons Learned

Lessons learned can be gathered using the following steps:

1. Gather the project team and relevant documents to ensure all perspectives and information are included.
2. Reflect on project experiences, discussing successes, challenges, and unexpected outcomes.
3. Write down the insights gained, focusing on specific events, actions, and results.
4. Look for common themes and prioritize lessons based on their impact on the project.
5. Develop actionable plans based on the insights to improve future projects.
6. Disseminate the documented lessons learned to relevant stakeholders and teams for broader organizational learning.

Example of Lessons Learned

Scenario: A software development team has just completed a project to develop a mobile application. During the project, they encountered several challenges and successes.

• The team experienced significant delays due to unclear requirements from stakeholders. They found that integrating user feedback early in the development process greatly improved the app’s usability.
• Document Lessons Learned:

1) Unclear requirements led to rework and delays.

Lesson Learned: Implement a requirements-gathering workshop with stakeholders at the start of the project to clarify expectations.

2) Late-stage user testing revealed major usability issues.

Lesson Learned: Conduct user testing at multiple stages throughout the development cycle to catch issues earlier.

3) Communication breakdowns between developers and designers.

Lesson Learned: Schedule regular cross-team check-ins to ensure alignment and facilitate collaboration.

These lessons learned are documented in the repository for future reference.

Conducting Retrospectives

Retrospectives can be conducted using the following steps:

1. Plan regular retrospective meetings, typically at the end of each sprint or project phase.
2. Collect data from the team regarding their experiences during the sprint or project phase.
3. Discuss what worked well and what didn’t, encouraging open dialogue.
4. Develop improvement items that the team can implement in the next cycle.
5. Designate team members to take ownership of each action item, setting clear timelines for completion.
6. Track the progress of action items in subsequent meetings to ensure accountability and implementation.
7. Create a mechanism for ongoing feedback to refine processes continuously and adapt based on team input.

Example of a Retrospective

Scenario: At the end of a two-week sprint in an Agile development team, the team conducts a retrospective to evaluate their performance.

• The retrospective is scheduled for the last day of the sprint, inviting all team members.
• Team members reflect on the sprint, sharing their thoughts on what went well and what could be improved.
• Identify Strengths and Weaknesses:

Strengths: Effective collaboration between developers led to quicker problem-solving. The team met all sprint goals on time.

Weaknesses: The team faced interruptions from stakeholders asking for changes mid-sprint. Some team members felt overwhelmed by the workload.

• Action Items:

1) Establish a “no change” policy during sprints unless critical to the project to minimize interruptions.

2) Reevaluate the workload distribution among team members to ensure a balanced workload.

• Assign Responsibilities:

Action Item: Implement the “no change” policy during sprints.

Owner: Project Manager

Timeline: Next sprint planning session

• During the next sprint, the team will check on the implementation of the policy and workload balance.

Create an anonymous feedback mechanism for team members to share their thoughts on the changes implemented.

Thanks, Olha