When I started with Agile and Scrum back at 2005, I was not much different from any other agile newbie, and I was complaining for having regular retrospective. “What for? We are already sitting together, we are a good team, we tell each other what should be said. It’s waste of time. Formal meeting…” Later I realized retrospective is quite useful and implemented it as one of the key Scrum practices.
The frontier is somewhat thin between analyzing things for continous improvement in Agile and blaming people for failure. In this blog post, John Allspaw discusses how Etsy wants to consider mistakes, errors, slips or lapses with a perspective of learning. he explains how having blameless post-mortems on outages and accidents are part of this approach.
The last Agile Manifesto principle states that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” For Scrum teams, the sprint retrospective is therefore a key meeting for continuous improvement. The results are however not always satisfying. In his book “Essential Scrum“, Kenneth Rubin discusses the most common issues in sprint retrospectives that he has noticed in his Agile coaching experience.
Continuous improvement is one of the main values of Agile and retrospectives should play an essential role in supporting this process. In his short and free book “Agile Retrospective Kickstarter”, Alexey Krivitisky provides some exercises that should help Scrum teams to get the most out of their retrospective meetings.
The basic rules of Agile project management frameworks like Scrum are deceptively simple. Drawing from his experience as an Agile coach, Jeff Campbell offers in his book “Actionable Agile Tools” some lightweight practices and tools that could help you to implement successfully an Agile approach.
The retrospective is one of 12 principles outlined in the Agile Manifesto. If this is easy to do this for collocated Scrum teams, how can you achieve good results if you have remote members. In this blog post, Robert Matheson provides a valuable collaborative retrospective technique that can be used for distributed Scrum teams.
People often say that retrospectives are useless, boring and take too long. This means that they are not done right! The difference between a good and a bad retrospective is the structure and the facilitation.