As a Scrum Master, I care about all the Scrum “events” – Sprint Planning, Daily Standups, Sprint Demo / Review and of course, the Retrospective. Do I care more about the retrospective? I’m not sure – but I certainly put a lot of effort into each one.

Partly that’s because I think it’s really important to make the most out of every meeting, and since each sprint is different, I try to make sure that the retro fits the overall needs of the team. And partly it’s because in my experience retrospecting has been a sorely neglected part of project management (in all industries, not just software) so there’s still a lot to learn about it. But since it’s arguably the most valuable tool we have for continuous improvement – to look back, identify strengths, clarify areas for improvement, and set plans in place to do so – I figure it’s worth putting extra energy in.

The retrospective is at the core of the Agile principle “Inspect and Adapt”. (Marc Bless unpacks this principle very nicely).  It’s particularly valuable in complex environments, where there’s a high degree of uncertainty and teams must be able to adapt to changing information and changing needs – which happens to be the realm of most software projects.

As an ex-Project Manager, I’ve been on projects where everyone knew we were veering off-course, with a collective feeling of “why doesn’t anyone do anything about this” hanging in the air – but we were always too late or under too much pressure by that time to do anything other than hold our breath and hope we can avoid disaster.

The ability to pause regularly to assess our overall progress, identify corrective action and implement it, seemed like an impossible luxury – or the final straw, when in extreme cases we had to go cap-in-hand to the client and explain why we couldn’t meet the time / scope / budget commitments. And while necessity may be the mother of invention, in these situations very few team members have much creative energy left.

Of course, when we had delivered a project on time & in budget (it’s a rare but not entirely mythical thing), we were immediately put under pressure to deliver more in the next project, with little opportunity to review what made this project different and be able to harvest that learning.

As I moved into an Agile environment, the focus of my retrospectives naturally shifted from projects to teams, and to me this is where the most value – and greatest challenge – lies.

Developing strong teams is one of the greatest assets a company can invest in. When a team is collaborating openly, sharing collective knowledge and engaging in constructive disagreement, it becomes increasingly easy to identify and eliminate blockages, smoothing the ability to complete work, and move on to the next challenge in a continuously improving – and highly functioning – team.

A lofty goal, and frequently considered the “snake-oil” of agile salesmen, this can only really be achieved when teams become dedicated to owning their improvements in an organization that supports and participates in the changes identified, over a sustained period of time.

At their heart, I see regular retrospectives as a key tool for team transformation, which help teams move from being a fragmented group of individuals reacting to corporate pressure, to trusting, self-organizing, motivated and directed teams, contributing to corporate discussions.

Yes, I have lofty ideals. Fortunately Agile provides me with a lot of practical ways to implement them :D