Teams sometimes consider to skip a retrospective meeting. For instance when they are feeling time pressure, or do not see the direct benefits of doing one. Next they question themselves if they have to keep doing retrospectives? Agile retrospectives help teams to learn and improve continuously, and there are valid reasons to keep doing them also with mature teams.
Dave Moran mentioned that he is hearing the question can we skip the retrospective? more lately. When hearing that question, he suggest:
Asking a team what it means for them to be agile and guiding them back to the Agile Manifesto is helpful in these situations. As one of the principles states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
His experience is that they way improvement is done changes when organizations adopt agile:
The retrospective is an opportunity for the team to stop, reflect and learn. It is a key mechanism designed into Scrum to support continuous improvement, a difficult concept to implement in actual practice for many non-agile organizations. Improvement in non-agile settings comes in fits and starts, generally showing up as centrally-mandated practices and added to an already bloated development process designed to cover any and all scenarios.
Dave explains why it is important to explain how agile supports continuous improvement, and how using agile practices like retrospectives impacts the approaches organizations use to manage change:
We’re looking to strip away the nonessential overhead while retaining a simple, direct, effective approach to work that involves combining traditional tasks and functions to accelerate delivery – with quality. If we want to eliminate that overhead that most organizations believe is necessary (today), we need something to balance their concerns. Continuous improvement via retrospectives provides the assurance that agile teams are concerned with their productivity and effectiveness. Retrospectives balance concerns about agile and provide the means by which agile implementations increase effectiveness over existing approaches – which is what we need to demonstrate.
In never underestimate the importance of continuous improvement, James Harvey explains how teams that are skipping retrospectives run the risk of becoming less productive:
From my experience with agile teams, Sprint Retrospective meetings are skipped when a level of efficiency is hit because, “Hey, we’re already doing a great job so why do we need to find things that are wrong?” This is where the danger of entering the comfort zone starts to become a reality. Without doing anything wrong, you’ll find that the team will lose velocity, efficiency and drive, and enter a slump where the assumption is that work will get completed without any effort.
His opinion is that it has value for teams to keep doing retrospectives:
The challenge of improvement becomes greater, but the reward of achievement is also amplified enormously.
Brian Copeland wrote a blog post agile vs fragile: Retrospective look forward, where he describes how “Fragile” teams, “teams that are using Agile as an excuse for poor project delivery practices”, view retrospectives:
This is one area where a lot of teams have dropped the ball. They don’t take the time to do retrospectives because people don’t understand the value they bring. They are perceived as a waste of time that could be spent on the next development sprint.
Fragile teams may do lesson learned sessions, but only because the Agile guide tells them they need to. They aren’t taken seriously, and the results are rarely acted upon. They become “blame game” sessions where everyone tries their best to ensure that failure of the sprint was not their fault, and that the sprint would have been successful if only the other team had done something differently.
The problem with retrospectives by fragile teams has to do with the way that those teams are adopting agile:
What these teams fail to realize is that the problem isn’t the methodology they choose, but the discipline they have in leveraging that methodology that determines their success. When teams adopt a methodology, but don’t fully embrace the principles, it leads to unpredictable and inconsistent results. It truly becomes Fragile.
Justin Carmony blogs about the results that his team got from doing retrospectives, in the catalyst for agile development: sprint retrospective. He start by explaining the situation that they were in before doing retrospectives:
(…) when I joined and started managing the Deseret News team we had our agile process: sprints, estimations, standups, planning sessions, etc. It worked well for the most part, but we still struggled as a team to find that next level of productivity. It always felt like we were missing something, so we’d shuffle things around. One week sprints to two week sprints, which day to hold the meetings, who was involved in what, etc. But no matter what we did it felt like we were just shuffling things around. We couldn’t achieve that next level of productivity.
They introduced sprint retrospectives in their sprint planning sessions:
We continued every two weeks in our sprint planning meeting to reflect on the previous sprint in our retrospective. (….) just a list of things that went well and didn’t go well, and what we wanted to change. We’d look at the previous sprint’s list and see how well we did on the things we set out to change to make sure we did them. Week after week, we’d set aside this time to revise the process and see what we wanted to change.
After doing 10 retrospectives, they saw the results that retrospectives have on their productivity, way of working, and delivery deadlines:
We’ve doubled our velocity as a team.
When we started this process, we were tackling big problems like a backlog and tasks that lacked definition. Once those were fixed, we started to notice other things to help the process go along. However, these things to change would never had been noticed if we weren’t regularly iterating over our process.
It’s not just our velocity that has increased: we’re hitting our deadlines much better. We’re able to make decisions about features much more confidently. When a new feature comes in, we can estimate it’s impact on our deadlines and decide what course of action to take.
His advice: “if you’re not doing a retrospective, start doing one. If you are, start sharing it with others”:
I truly believe the Retrospective really unlocked the potential of agile development: We went from shuffling around our process to iterating over our process. What kills me is every time I’ve heard someone talk about the agile process, I’ve never heard anything about doing a “retrospective” before. I’ve heard about estimations, backlogs, sprints, velocity, yet the central principle, the very catalyst that can take whole agile process to the next level, seems to never get any attention.