In 2007, just before my first encounter with Scrum, I went to a lessons learned workshop as the test manager for a multinational company implementing a global technology and corporate change program.
By this time, I had attended many lessons learned workshops, which often took place at the end of projects, as a way of learning from the past project and improving the next. I enjoyed these events as they were an opportunity to work with the whole team to look at and solve all those day-to-day problems that prevent large complex implementations from succeeding.
I was often excited by lessons learned opportunities, but I was particularly looking forward to this one, since it was taking place midway through the project, and there was a chance that much-needed change would be implemented.
We workshopped away for a couple of hours and ended up with a stack of issues that needed solving, all clearly visible on a very large wall. The session had been productive. At this point, the program manager stepped up and announced rhetorically: “Well, I don’t think there’s anything there that we don’t already know!” And then he closed the meeting. We just shrugged reluctantly and went back to our jobs.
That meeting cost several thousand dollars. What did I learn? That leadership was not listening to its teams. What did the teams learn? Nothing that they didn’t already know. That program did not fare well.Then I Found Scrum …
I was excited when I was introduced to Scrum and the Agile Manifesto shortly afterwards, since continuous learning is not just encouraged, it is essential.
Sure, learning is essential in a waterfall program, too, but the beauty of Scrum is that it makes it achievable by:Working with small teams so that shared communication is optimal Embedding frequent inspection into the framework through the daily scrum, review and retrospective
When you’re working with a team to get stuff done, being able to adjust and adapt to not only changing circumstances, but also your own internal team dynamics is pure gold. It is one of the behaviours that make a team great.How Scrum Facilitates Learning Lessons
The Scrum framework gives the team a sprint goal and empowers them to deliver it. The team is therefore invested in learning about itself.
Because of the daily scrum and the close-knit working relationship of the team members, external impediments are quickly identified and raised, so don’t become “lessons learned” flotsam.
The desire to deliver something of value and put the goal of the team first enables individuals to negotiate “personal preference” impediments. These are the impediments that we all bring to any team we join, and are simply our personal preferences for ways of doing things.
Having a clear team goal helps us to put these to one side when we need to and/or negotiate a shared way of working. In this way, the team culture develops.
The Scrum Master, by practicing servant leadership can support teams and invite them to act as servant leaders to one other. The retrospective is a good event for developing this skill.The Retrospective is a Gold Mine … But Not Everyone Sees It That Way
The retrospective acts as a container in which a team can influence the next sprint by looking at the last one. It is an opportunity for team members to support and acknowledge one other by reflecting on the good work they have done, and their ability to adapt and find creative solutions.
In a positive working environment such as this, issues and difficulties are more easily resolved and can make the retrospective enjoyable, interesting and productive. Conflicts will naturally occur, but in a culture of mutual respect, they can be resolved openly and for the good of all.
However, I have known Scrum teams to discard the retrospective on the grounds that they already know what the problem is, and believe they would make better use of the time in working to deliver more features, especially since they have not delivered much in the last sprint (or two). This is a team that has lost its way.
The following scene is based on a version of real events …
Enter the Scrum Master.
Scrum Master: O Team!
Delivery Team: Yes, O Servant Leader?
Scrum Master: Have you forgotten that if you do not do Scrum, you are not doing Scrum?
Delivery Team: Go away, for we are busy!
Scrum Master: But what is the sprint goal towards which you strive?
Delivery Team: Um…
Scrum Master: Ah, let us retrospect and entreat the product owner to share their vision so we may be enthused and therefore desire to make it so.
Delivery Team: OK, but the product owner is busy and wants us to just get it done.
Scrum Master: Fie!* Let us retrospect all together as one Scrum team and reflect on the importance of the energizing goal.
*interjection, used to express annoyance
In the past 12 months, I have worked with a number of teams that have been introduced to Scrum and retrospectives for the first time.
And one question I have posed is: “How do we know when we have learned a lesson?” After all, saying that you have learned something is one thing; changing a working practice or behavior is quite another. Change often occurs incrementally. So how can a Scrum Master facilitate this process?How to Get the Most From Retrospectives
A Scrum Master can help by supporting the team to create its own team charter—becoming a great team is not an accident or coincidence; it needs to be a conscious decision.
The team charter is team created and co-owned by every member. It defines the behaviours and ways of working that will help the team grow and work together. By setting this vision for itself, the team creates something it can reflect on in a retrospective, not as a way of punishing itself for failure, but as a way to honestly look at how it has lived its own principles during the last sprint.
With a clear sprint goal and team charter in place, the retrospective will be a rich source of ongoing learning.
In time, retrospective behavior and thinking can become a part of the daily work: Not everything needs to be saved for the retrospective; equally, not everything can be resolved on the spot.
What I like to do is create an area on the Scrum board called “retrospective,” where team members can stick a note when something occurs to them that may not be an immediate problem, but a creative way to improve the team’s delivery capability. We then review the notes in the retrospective and work with the ones that are still resonant.
This can remove the pressure on team members at retrospective time, as they won’t spend so much time furrowing their brows trying to remember that thing that happened.
Another light touch technique is to get a large white board, draw a horizontal line across the middle, put a vertical start point far left and a vertical finish point far right.
The distance between the two points represents the sprint. The y-axis represents “level of activity”; the top is “frenzied activity,” the bottom is “nothing, zero, zilch.”
Now, ask each team member the draw a line from left to right over the life of the sprint that shows their level of activity as the sprint progressed (different colours work well).
It’s fun, and when done, there is a clear pattern that the team can see. Often the team will annotate sudden plunges or spikes. This technique can be a good place to start if you have a team that often inflicts three days of frenzied activity on itself at the end of every sprint.
In sum, I’ve been through many variations of “lessons learned” meetings throughout my career, and this is what I have learned so far:
Some lessons have to be learned many times. Some lessons are learned quickly, some slowly, bit by bit. Some are never learned. But, the most important lesson of Scrum, for me, is to challenge the team to take responsibility for its own development by creating a charter, trust it to live those principles and remind it to reflect on them at the retrospective meeting.