Project Management

Sprint Retrospectives

From the The Reluctant Agilist Blog
by
Adam Weisbart | Agile | Agile 2013 | agile 2014 | agile 2015 | Agile 2017 | Agile 2018 | Agile Alliance | agile coaching | Agile Metrics | Agile Practice | agile transformation | Agile Transition | agile2014 | agile2015 | agile42 | Agilistocrats | Alistair Cockburn | autism | Bas Vodde | BigVIsible | Bob Tarne | book review | Brian Bozzuto | business agility | carson pierce | Center for Non-Violent Communication | Certification | Certified Scrum Master | Certified Scrum Product Owner | Chet Hendrickson | Chris Li | Coaching | commitment | Communication | conteneo | Craig Larman | cross functional teams | CSM | CSPO | DAD | Daniel Gullo | Dave Prior | David Anderson | David Bernstein | David Bland | David J Anderson | Dhaval Panchal | diana larsen | Digital Agency | Digital PM | digitalpm | Disciplined Agile | Disciplined Agile Delivery | Distributed Teams | Don Kim | dpm | dpm2013 | drunken pm radio | drunkenpm | drunkenpm radio | eduscrum | emotional intelligence | empathy | Enterprise Agile | Essential Scrum | esther derby | Excella | Gangplank | Gil Broza | Howard Sublett | Individuals and Interactions | Jean Tabaka | Jeff Sutherland | Jesse Fewell | Jessie Shternshus | jim benson | johanna rothman | john miller | Jukka Lindstrom | Jutta Eckstein | kanban | Kanban Pad | kanbanfor1 | Ken Rubin | Kenny Rubin | Kim Brainard | lacey | Language | Large Scale Scrum | Larry Maccherone | LeadingAgile | lean | Lean Kanban North America | LeanKit | LESS | lkna | luke hohmann | lyssa adkins | Maria Matarelli | Mark Kilby | Marshall Rosenberg | Michael Sahota | Mike Vizdos | Modern Management Methods | modus cooperandi | Natalie Warnert | Nic Sementa | Non-violent communication | North American Global Scrum Gathering | NVC | Olaf Lewitz | ├średev | ├średev 2013 | organizational agility | Organizational Change | overcommitment | Patrice Colancecco Embry | Paul Hammond | personal kanban | personal productivity | personal project management | Peter Saddington | PMBOK | PMI | PMP | podcast | portfolio management | Product Development | Product Owner | Product Ownership | productivity | project management | Project Management Institute | Rally | Release Planning | reluctant agilist | Renata Lerch | retrospective | Richard Cheng | Roman Pichler | Ron Jeffries | SAFE | Safety | Sallyann Freudenberg | scaling agile | Scaling Scrum | Scott Ambler | Scrum | Scrum Alliance | Scrum Gathering | Scrum Master | ScrumMaster | self organizing teams | SGPHX | SGPHX 2015 | Shane Hastie | social engineering | SolutionsIQ | SoundNotes | sprint planning | Team | teams | Temenos | The Improv Effect | Things | Tom Perry | troy magennis | User Stories | value | Vivek Angiras | waste | Waterfall | What We Say Matters | why limit wip | women in agile | Woody Zuill | show all posts

About this Blog

RSS

Recent Posts

Getting Better at Saying No with Tim Wise

Chief Scrum Master & Chief Product Owner - Checking in with Melissa Boggs and Howard Sublett

Ryan Ripley - Fixing your Scrum

Leadership is Language with David Marquet

Agile for Non-Software Teams w/ Gil Broza



If you are accustomed to working within the context of a traditional approach to managing projects you are probably familiar with the idea of doing a post mortem, or review at the end of a project. The objective of this meeting (or set of meetings) is to examine what has taken place and find a way to generate lessons learned which could be used to improve future efforts.  In theory, this sounds like a great idea. In practice, however, there are two problems with this approach. First, they are rarely done with the regularity, or rigor required for them to truly add value. More often than not, team members are reassigned and send off to work on new projects before the project review can be conducted. Second, when project reviews are conducted, it is typically to focus only on the things that went wrong. Unfortunately, this often turns into a finger pointing session that does little to recognize the things that went right, and often is more centered around hanging blame on individuals than on determining the practices or processes that allowed the trouble to start in the first place. There are, to be sure, exceptions to the above, but in a traditional model skipping this critical step is far too common.

Repeatedly taking the time to examine how things are going is something that is baked right into an Agile approach. Scrum, for example, is defined as being built on “three legs”: transparency, inspection, and adaptation. If you are practicing Scrum, each Sprint includes the Sprint Retrospective, a “ceremony” where the team meets privately to inspect how they are working and to determine what steps they need to take in order to improve during the next Sprint. While a disciplined traditional approach may include a review at the end of each project (or ideally, the end of each phase), in Scrum, this happens every 2-4 weeks. It is the last official thing a team does during each Sprint.

The Scrum framework offers a more lightweight approach than you’ll have under a more traditional methodology like the one defined in PMI’s Guide to the Project Management Body of Knowledge (PMBOK). Because Scrum has removed so much of the process overhead, one of the things that teams come to depend on is the cadence of Scrum. We begin each Sprint with our Sprint Planning meeting; we hold a Daily Standup (or Scrum) meeting each day (at the same time in the same place); we hold a Demo (or Review) meeting with the stakeholders at the end of the Sprint and we follow that up with the Sprint Retrospective. Each of these practices provides opportunities to inspect and adapt, but it is the Retrospective meeting where the team comes together privately to exhale at the end of the Sprint and work out how they, as a unit, can become more effective.

Another interesting aspect of the Sprint Retrospective is the way the meeting is conducted. Teams will often start by focusing the positives and identifying what went right during the Sprint. Even if the Sprint did not go well, there is always something positive that can be gleaned from it.  When the team talks about what could have gone better, the goal is to offer constructive criticism geared towards enabling them to function better as a unit. The subtle shift in from focus on “you” to “we” is a very important cultural change for those of us making the switch from a traditional approach. Before the Sprint Retrospective ends, the team will come up with an action plan for the next Sprint so that they can do more of the good things they’ve identified and take steps to correct some of the things that did not go as well as they could have.

If you are new to Agile, it may seem unnecessary to hold reviews with the frequency called for by Scrum - especially if things appear to be going well. Many rely on the old adage, “if it ain’t broke, don’t fix it”. The problem with that approach is that it becomes far to easy to overlook things until a time when they are so clearly broken, that there is no way back. If we are always inspecting and adapting, we are far more likely to catch things while we still have the ability to make any necessary adjustments.

If you are interested in learning more about Retrospectives, there is a great book by Esther Derby and Diana Larsen called Agile Retrospectives: Making Good Teams Great.

Posted on: September 14, 2011 10:45 AM | Permalink

Comments (0)

Please login or join to subscribe to this item


Please Login/Register to leave a comment.

ADVERTISEMENTS

"Creative minds have always been known to survive any kind of bad training."

- Anna Freud

ADVERTISEMENT

Sponsors