No matter the Agile Methodology used, there’s always an emphasis on learning from past projects and improving the ways that we work.
In this blog we’ll cover:
- Understand the difference between “Lessons Identified”, “Lessons Learned”, and “Lessons Implemented”, and how each stage contributes to continuous improvement in Agile projects.
- Learn common challenges teams face when moving from lessons identified to lessons learned and from lessons learned to lessons implemented.
- Discover effective strategies and tools for analysing root causes, agreeing on actions, and ensuring lessons are shared and implemented across teams.
- Gain insights into real-world examples and best practices from Nimble’s experience, highlighting how to successfully implement lessons to achieve better project outcomes.
Let’s get going.
No matter the Agile Methodology used, there’s always an emphasis on learning from past projects and improving the ways that we work.
To always be improving, tools and meetings like Retrospectives and Post-Mortems are often used to review what was achieved, what went well, what didn’t go so well, and how processes can be improved. These tools are helpful to identify potential lessons, but this is where they often fall short of driving actual improvements.
Lessons Identified aren’t always Learned, and Lessons Learned aren’t always Implemented.
At Nimble, we understand the value of teams and organisations successfully achieving lessons learned, and lessons implemented, as well as some of the challenges that teams face in getting past lessons identified.
Using the Correct Language
Let’s dive into the nuances that differentiate these concepts, explore the significance of each in the lifecycle of a project, and provide guidance on how to ensure that lessons identified become lessons learned, which in turn become lessons implemented.
Understanding and applying these distinctions can enhance an organisation’s ability to adapt, innovate, and excel.
Lessons Identified
Lessons Identified are insights gained during or after a project, highlighting what went well and what did not. This step is crucial for capturing observations and initial reflections on project performance and outcomes. Lessons identified might also include the identification of potential areas of improvements.
- Focus: Recognising what happened, including successes, challenges, and mistakes.
- Action: Identifying potential areas for improvement based on the observed events.
- State: Passive observation and analysis.
Lessons Learned
Lessons Learned represents a deeper level of understanding of the lesson identified. It involves understanding why these lessons are beneficial, creating a plan of action, and committing to change. Sharing these lessons facilitates learning throughout the organisation.
- Focus: Understanding the why behind the events and extracting actionable insights.
- Action: Introducing changes based on the extracted insights to avoid similar issues in the future.
- State: Active application of knowledge gained from past experiences.
Lessons Implemented
Lessons Implemented take lessons learned one step further. Where lessons learned cover the introduction of changes, lessons implemented include accountability and responsibility for the continued implementation of those changes. This often requires ownership from someone in the team.
- Focus: Ensuring that lessons don’t need to be relearned with the next project.
- Action: Owning the promise of change.
- State: Active use of the process across projects.
Summary of Using the Correct Language
| Feature | Lessons Identified | Lessons Learned | Lessons Implemented |
| Focus | What happened | Why it happened and how to improve | Keeping on top of the improvements |
| Action | Identify potential improvements | Introduce changes | Own the changes |
| State | Passive observation | Active application | Active use |
| Example | “Communication breakdowns occurred.” | “Improved communication plan implemented to prevent delays.” | “Scrum Master is responsible for following the communication plan.” |
| Summary | Recommendation based on experience | Promise of change in personal or organisational behaviour | Ownership, accountability, and responsibility for the change |
Moving from Identified to Learned
The biggest mistake that teams can make is not identifying any lessons. This can happen through skipping retrospectives between sprints or post-mortems between projects, often saying that they don’t have time for it. Or just not taking a deep enough look at the topics that are discussed in those meetings.
“It takes one of the core Scrum values to enable the identification of lessons. Courage. You need to have the courage to be able to speak up, and we need to foster that by building psychological safety in the workplace.” Dan Kastelik
If teams aren’t taking time for these important meetings to reflect on what has happened, they are doomed to repeat the same mistakes. Assuming they are taking the time to identify lessons, the main challenges teams often face in moving from lessons identified to lessons learned are:
Understanding the Cause
Understanding the root cause of what has been identified in a retrospective or post-mortem can be a challenge. Whether it’s a success, a challenge, or a mistake, misappropriating what caused the success, challenge or mistake, can lead a team down the wrong path.
Surface-level observations identify surface-level issues, but a deeper analysis of potential root causes could save time and effort in the future.
Nimble’s delivery consultants can utilise tools like Ishikawa or Fishbone models, drawing the right people into the room, and helping to remove guesswork.
Agreeing on Actions
Once the root cause is understood, the next challenge is agreeing on what to do about it. There might be two or more options on how to get the most value out of the lesson being learned, and in all likelihood, trying to tackle all of them at once will not give you the desired results. It might even make matters worse.
If there’s no single clear option, you need to analyse the options you have available. You can consider: the effort required vs the value derived; the potential longevity of a solution; or perhaps if you even need to take action now, you may want to monitor the situation longer, or it may be something that the team can live with. You might want to try one option and fall back onto another if the first attempt doesn’t work.
“Once you’ve identified something that needs to change in some way, you’ve got to try SOMETHING. You’ve got to be comfortable to just give it a go, knowing that it might not work. And if it doesn’t work, you can learn from that.” Dan Kastelik
Sharing Knowledge
While a lesson might be learned within one team, a lack of knowledge sharing prevents other teams from learning the same lesson, leading to repeated problems and missed benefits.
When sharing knowledge, consider the target audience, how the knowledge impacts them, how they can effectively consume that knowledge, and even the tone of how the knowledge is shared. A poorly delivered lesson can easily backfire.
This challenge could have been written under “Moving from Learned to Implemented”, but it is just as important here.
Someone Else Will Handle It
Possibly one of the biggest mistakes a team can make is identifying a lesson, and hand waving it saying that it is someone else’s problem to deal with. This is a sure fire way for nothing to change, and for everyone to become irritated. To top it all off, the person who might be responsible for handling “it”, may not even be aware that “it” is a problem.
The solution to this challenge is simple, and it goes back to the “Not Sharing” point above. Communication.
If your team fully believes that someone else is responsible for doing something, they need to communicate that clearly and effectively. It might be that another team disagrees with the assertion that they’re responsible for doing something. And the only way to resolve that, is to invite people into a conversation, where constructive communication can take place. It can help to have a third party who is not associated with either team to help facilitate the conversation.
One of our delivery consultants was brought onto a client project where a third party was supplying a front end product that required input from half a dozen internal teams. Each team had its own plan, priorities, and deadlines. The teams were communicating, but only ever in an “I need this” way, and there was no overall cohesion.
Taking a step back, and bringing representatives from each team together, our delivery consultant was able to show that none of the plans or priorities aligned. That was all that was needed. No one fought for their plan over another team’s plan, they just hadn’t realised that they were all dancing to a different beat.
Moving from Learned to Implemented
Once lessons are learned, it is easy to think the hard work is done, but often, the real challenge is ensuring implementation. To avoid repeated issues and disenchantment with retrospectives and post-mortems, the following approaches can help:
Record, Review, Revise, Removed
When lessons are learned, someone should be able to go and see what the lesson was. Recording lessons in a shared space means that those lessons can be reviewed, and if they’re not being adhered to, a conversation can be had as to why.
It should be noted that lessons should not be written in stone. If a lesson needs changing, or is no longer relevant, it can be revised or removed. Just as long as (at least) everyone in the team is made aware of the change, and the reasoning.
Ownership, Accountability and Responsibility
Possibly the most important step in moving from lessons learned to lessons implemented is ensuring that someone owns the action to make the lesson a reality. This creates responsibility on the owner to ensure that an action is completed. But it is important that responsibility is not just dropped onto someone, they have to accept the responsibility, making them accountable to the team by committing to take on that responsibility.
It can help to link the target value with the owner of an action. If there’s a lesson to be implemented that will benefit one individual in the team, they have a vested interest in ensuring that the lesson is successfully implemented.
But just because someone is accountable to the team for the completion of an action surrounding a lesson, does not mean that it is their only responsibility. Life and work can catch up with people, so having a “responsibili-buddy”, or someone who can check up with the action owner, can help to raise awareness of blockers, requests for assistance, as well as ensuring that actions aren’t forgotten.
Retrospective actions should also be regularly reviewed at the start of each retrospective to verify whether they have been completed or not.
All of this ensures that actions are progressed until a lesson is successfully implemented.
External Resistance
Sometimes, even with the best intentions, a team might find that something is outside of their control, or not a part of their responsibilities to implement. In these instances, there are three options:
- Be a disruptor – If something is outside of your control, you need to escalate it, and to have the courage to put yourself in front of the people who are able to influence or control the situation.
- Own it – If something isn’t really your responsibility, but doing it will improve your life or those around you, you might want to step up and just handle it. Dan Kastelika, a Principal Specialist of Agile Delivery at Nimble Approach, recalls a time where he had to call suppliers directly because they hadn’t delivered laptops to the client, for our Nimble team to use. Without those laptops, our team couldn’t do their jobs, and so Dan stepped up and for a brief moment, organised the logistics, not of the client, but the client’s supplier.
- Ignore it, throw in the towel, or give up – At Nimble, we don’t accept this option.
Monitoring and Evaluation
Whilst not always necessary, it can be beneficial to monitor the effectiveness of a lesson implemented, and to plan a point in the future to review those results. A successfully implemented lesson does not guarantee positive outcomes. As noted previously, there may be multiple options on how to approach a lesson, so you may want to measure the success of one before trying another. Or maybe there are unexpected knock-on impacts from implementing a lesson, and so the lesson needs to be removed, or changed.
The monitoring or evaluation of an implemented lesson might not be entirely scientific as the initial lesson identified might not allow for that, but a conversation on how the lesson has impacted people can provide valuable insights.
In Nimble’s Experience
Zach, one of our Managing Consultants, recalls a situation a while ago where a recurring retrospective topic was the need to speed up the deployment process.
The team identified where something needed to change, and they agreed on an approach to driving that change. But the topic came up time and again because even though a lesson had been identified, they needed someone to own the action from the Retrospective, for the lesson to be learned.
That would be a quick win for the team, agree an owner for the action, and there should be improvements in future sprints. But that didn’t happen. Talking about the challenge, it became clear that the effort required “now” to drive the change was perceived as being more than just putting up with the slow deployment pipeline in the current sprint.
Even though it was acknowledged that the longer term value would far outweigh the effort “now”, it was always put off because of the effort in the current Sprint. To help drive the implementation of the lesson, the action was factored into the next Sprint. This gave daily visibility, and accountability for making the change.
So the team knew there was a problem with deployment speeds (Identified), that there was a way to improve their deployment speeds (Learned), and eventually, they were able to make the change (Implemented). But until they completed that journey, no matter how many times they Identified or Learned the Lesson, they were wasting effort.
And within this journey, there was another lesson about making time for learning and implementing lessons. This became a part of the team’s ways of working, with each action from a Retrospective, the Scrum Master asked if the effort to complete the action required additional time in the next Sprint.
Dan Kastelik tells us about a time where you could feel the negative energy any time you joined a call with one of the engineers and the Product Owner. This animosity had deep roots in how work items were handled before being passed to the team. This was addressed in a retrospective in the hope that solving the work item issue would alleviate some of the tension between the two.
- Lesson identified – The work items are too big, and we don’t have enough time to break them down before they reach the board, so new work keeps being identified to break the work items down that are already on the board.
- Lesson Learned – Dan will lead the team in reviewing their Workflow Definition, to include a maximum size of any work item that is allowed to reach the board, and to add some data points around workflow to keep track of potential problem items.
- Lesson Implemented – The Workflow Definition was updated, and the entire team (including the Product Owner) were forced by their own rules to work more closely to ensure that work items were appropriately sized and understood before being accepted onto the board.
The lesson had been implemented successfully, there were less surprise work items appearing out of existing work in progress, and overall the performance of the team was able to improve. But the tension between the engineer and the Product Owner continued. This required a new lesson to be identified, learned, and implemented.
There was no quick win, but the commitment from Dan and the rest of the team to try new things helped to improve how the engineer and Product Owner worked together. The aim wasn’t to make the engineer and Product Owner the best of friends, but by improving the way that they worked together, there were positive benefits for the entire team.
Conclusion
Learning from our past makes us more resilient for our future. This is not a new concept, but you have to make learning, and acting on those learnings a core part of your culture. This can be at an individual level, at a team level, or at a company level.
Remember that lessons “identified” aren’t always “learned”, and lessons “learned” aren’t always “implemented”. Simply identifying lessons is not enough. True learning involves active application and continuous improvement.
By bridging the gaps between “identified”, “learned”, and “implemented”, you can unlock the full potential of your experiences and achieve better outcomes. Once you’ve achieved that, ask yourself, “can we do better?”.
This blog in itself is a lesson that needs to be implemented. You can take these lessons on your own, or Nimble are also here to guide and support you through the learning journey.
Authors Bio
Ketan Parmar, Principal Consultant at Nimble Approach
Ketan has over 22 years of experience in IT delivery, spanning diverse industries. He believes in empowering delivery teams to unlock their true potential and consistently deliver tangible value.
Greg Horsfall, Lead Consultant at Nimble Approach
Greg has over 12 years of IT delivery experience in a wide variety of industries. He has a passion for enabling delivery teams to realise and deliver real value, through effective communication, process adoption and leadership.
With contributions from:
- Zach Stratenwerth, Managing Consultant at Nimble Approach.
- Dan Kastelik, Principal Specialist of Agile Delivery at Nimble Approach.
