For Scrum Masters, team members, product owners, and everyone else developing amazing things.
What does it mean to be "agile"? And how does one achieve agility in the first place? These are important questions. Perhaps the best way to judge of a team's agility is the degree to which it is able to react and adjust to change in its environment. Or, to put it another way, how well is a team able to continuously improve?
In order to enable agility, scrum, one of the most popular agile frameworks, encourages teams to run short experiments called sprints, each of which is designed to test one or more hypotheses. During every sprint, a scrum team holds a variety of meetings (called "ceremonies") including sprint planning, product backlog refinement, sprint review, and finally, the retrospective. To record the functionality they need to develop, scrum teams write user stories and record them in a prioritized list called a product backlog. Taken together, scrum provides a framework that enables teams to learn from its experiences and adjust to new realities.
But not all scrum teams hold all of these ceremonies, just as not all scrum teams write user stories in a product backlog. In fact, many scrum teams don't hold the retrospectives at all. Why is that and what is the cost? Are these teams missing out on something critically important? Can a team even be agile without running regular retrospectives?
To answer these questions, let's imagine a scrum team that has adopted a variety of modern technical practices that encourage and enable agility, such as test driven development and continuous integration. Let's also imagine that this team is new and hasn't worked on a project together before.
At the beginning of every sprint, this team holds a sprint planning meeting in order to learn about, and commit to developing, new functionality in the upcoming iteration. And at the end of every sprint, the team demos the software to key stakeholders to see their reactions and get their feedback. Critically, the team does not run retrospectives.
How does this team perform? While it's certainly possible that this team performs at a high level, it's not likely. Teams take time to form; they require relationships to be built and trust to be established. Good technical practices are just that: good to have. But they aren't enough.
So it isn't a stretch to imagine that this team fails to meet its commitments and falls below expectations. Similarly, we could easily imagine that team members are stressed out, quickly assign blame when things go wrong, and lack empathy for those who make mistakes.
At this point, it would be smart for someone on the team to ask itself: why? Even more importantly, what can the team do about it?
Let's paint a different picture. This time, imagine a new scrum team that has yet to adopt the modern technical practices of the last team, yet consistently runs retrospectives at the end of every sprint.
As the team starts on its journey together, its progress is slow, it makes mistakes, and like the last team, its members lack trust in, and empathy for, each other. Yet as the team's first sprint comes to a close and it runs its first retrospective, it asks itself: what can we do to improve? After much discussion, the team agrees to focus on getting more face time with the Product Owner. During the second retrospective, the team agrees on the need to write more unit tests. At the third retrospective, it commits to getting more clarity on the Definition of Done for each user story. And so on.
Over time, this team goes from dysfunctional to functional to high-performing. And it's all due to the retrospective. Having a regularly scheduled opportunity to improve is critical to unlocking a team's potential.
As is evident from the two scenarios described above, retrospectives are the most important aspect of agility. In fact, it isn't a stretch to say that a team that adopts every aspect of scrum except for the retrospective isn't really agile at all. How can one be flexible and continuously improve without giving itself the time and space to do so?
So, the key takeaway is: run retrospectives to create high-performing Agile teams. Even "bad" ones are better than none at all. But if you want to learn how to run them well, find out here.
.png){kind=small}
