Agile Retrospectives - Over and Over Again
February 2nd is Groundhog Day. That famous day of the year when Punxsutawney Phil (a little Groundhog or more commonly known as a woodchuck) analyzes long-term weather patterns to predict when spring will arrive. NOAA is waiting with bated breath for his final decision I am sure.
When I think of Groundhog day, I think back to the movie where a single day keeps repeating over and over. Each time the main character goes through the loop, he improves himself by learning new skills and having fun along the way. It also reminds me of retrospectives. How very Agile, right? Not just retrospectives in Agile but lessons learned as well. There is gold in that mountain of pain and frustration you just went through if you only look at it. Instead of waiting for the end of the sprint or phase in your project, how about learning as you go long?
When you are in the heat of the moment, it is hard to learn anything. All hands on deck and forward focused on getting the job done. Whether that is a process map, functional decomposition diagram, user interface or even a context diagram it is important to step back after completing a sprint, deliverable or milestone and reflect back. Hindsight has always been 20-20. I wish foresight were 20-20. Looking back is a good way of learning from the mistakes that were made and even learn from the things that went exceptionally well. Looking back does not have to be a group activity but rather an opportunity for you to see your difficult spots and figure out ways to not repeat those mistakes in the future. Never reflecting means you are never learning, so repetition in the style of Groundhog Day appears. You just keep repeating the same paid and frustration over and over.
In a previous article, I advocated for the keeping of a journal in which you would write down your accomplishments that day. Give yourself a little celebration for all the things you completed to give yourself a sense of accomplishment instead of staring at the endless list of tasks. In this article, I advocate adding a section for what you learned that day.
I have been involved in many process improvement projects over the years. Honestly, all projects are process improvement projects in some way. On one of these projects, there were several critical processes that were changing as part of the project. The project team decided to tackle each of the processes one by one and not doing them all at the same time. The same business resources were needed for eliciting requirements, and they were limited in the amount of time they could provide to the project.
The first process that was mapped was frustrating, painful and took a very long time to complete. After the team had finished the process mapping, we all sat back and tried to figure out a better way to approach the remaining processes. After every process was completed we asked ourselves:
What didn’t go well? What can we do to avoid these things?
What worked out great? How can we repeat these great things?
What still confuses us? What do we need to learn?
The beautiful thing about stepping back after each process was completed was that we learned how to do the process mapping with considerably less frustration and effort. In the beginning, we were taking four weeks to finish a process, and in the end, we could crank out a process map in 3 days.
We found ourselves in that Groundhog Day loop just like in the movie. We made the best of it. By looking back and taking the time to learn from our failures, we could move forward with new approaches that produced better results quickly.
Put some time aside after that next deliverable, document, process map or task is complete and ask the three questions above. Even if you are only doing it for yourself and not involving others, it is still a good practice. Create a page that shows the issues you encountered and how you overcame those issues. Even to this day whenever I need to put together a process flow, I look back on that notes and what I learned from that project.