Agile Retrospectives: The Preventative Medicine

One of the features of using Agile methods is the opportunity for continuous improvement within a project. There are a number of improvement opportunities throughout a typical iteration or sprint─over the next few weeks I’m going to walk through a few, starting this week with the Retrospective. Retrospectives are one of the many tools in Scrum and other Agile methods that are absolute must-haves for continuous improvement.

Think about the last time you built a product (or had one built for you). If you weren’t using an Agile method like Scrum, chances are that you pushed through the project in one big rush, waiting until the end to think of the things you would do differently next time. If you were lucky there may have been a chance for a review afterwards.

Enter the retrospective. Retrospectives take place frequently, at the end of every sprint (typically 2-4 weeks), and give the team a big opportunity to do things better sprint by sprint. A retrospective helps the team identify any changes or corrections needed during the project.

While I’m a fan of a good post-project review it is often equated to a post-mortem and, following this analogy through, retrospectives are closer to the idea of preventative medicine. Ultimately this isn’t so different from any other lessons learned process but for me the frequency and drive for action that comes out of a retrospective make them highly effective. As an added plus, retrospectives are also fun to facilitate (if you’re into that sort of thing) and generally make everyone feel more positive about the approaching sprint.

Running a retrospective is a pretty standard process but again is open for improvement and adaptation. My favored format is:

  1. What just happened? (aka “set the stage”) The team builds a brief time-line of what happened during the sprint.
  2. How are we feeling? Each team member draws a mood line of how they were feeling throughout the timeline, talking through their personal peaks and troughs during the sprint (I’d love to know how this technique came about!)
  3. Things to note! You can use whatever categories you need here, but generally Good Things, Bad Things, and Ideas work well. Some facilitators also add Bouquets─things that other team members have done during the sprint that are worthy of praise.
  4. Actions: The best way to get a short-list of actionable items is to use dot-voting/multi-voting to highlight the top three or four things that the team wants to address. If these items are related to the product they’re moved into the product backlog. If they are process related they generally become the project lead/Scrum Master’s (or sometimes Product Owner’s) responsibility.
  5. Close the retrospective: Check how the retrospective went, and confirm the next steps.

For a bigger retrospective, particularly in between project phases, I think it’s good to use a more elaborate Innovation Game to generate ideas for how things could be better next time. I like Remember the Future─it’s a game that can be used for either product brainstorming or focused towards the effectiveness of the whole team.
Retrospectives are a good habit to get into. They can also be used in non-Agile delivery as well (i.e. in Waterfall, running a retrospective after the completion of every milestone).

More on retrospectives
There are some good books (Agile Retrospectives) and many articles around the web but ultimately you need to run one, get feedback from the team and start improving. Some useful starters:

  • An action planning focused method
  • Another on product level retrospectives
  • A useful article on improving your retrospectives—you’ll get the idea soon enough.

 

3months
3months are a 16 year old, independent software services company with offices in Auckland and Wellington, New Zealand. We specialise in helping organisations of all sizes (from entrepreneurs through to large corporates, government agencies and international advertising agencies) conceive and build new generation web & mobile software solutions, fast.
3months
3months are a 16 year old, independent software services company with offices in Auckland and Wellington, New Zealand. We specialise in helping organisations of all sizes (from entrepreneurs through to large corporates, government agencies and international advertising agencies) conceive and build new generation web & mobile software solutions, fast.

The Related Post

Testing in Agile Part 1 – INTRODUCTION TO AGILE In case you missed the first part of the series in our last magazine issue from Michael Hackett, Agile’s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic.
Janet Gregory draws from her own experience in helping agile teams address alternative ways to cope with roadblocks including projects without clear documentation, testers with limited domain knowledge and dealing with either black box or white box testing. For testing on projects without clear documentation, is exploratory the only method? I often make “tester errors” ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Four of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile”   LogiGear Corporation  LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and ...
LogiGear Magazine July 2012 Testing in Agile  
If your Agile implementation is not about people, you’ve missed the boat! The most profound impact to becoming more Agile is happier teams! Agile manifesto Value #1: * Individuals and interactions over processes and tools Words like these do not show up in Waterfall or RUP SDLC process descriptions. Agile cannot get more basic than ...
There is a multitude of Agile testing techniques that are quite sophisticated. The DAD process can help guide your process of tailoring decisions. Agile developers are said to be quality infected, and disciplined agilists strive to validate their work to the best of their ability. As a result they are finding ways to bring testing and ...
As CTO of Xebia and highly experienced in offshore testing in India, Guido articulates his methods in addressing common challenges faced by the in-house and offshore teams. He weighs heavily on strategic tactics as well as key cultural aspects to execute efficient and effective Agile methods. 1. I work at a US-based company and we ...
Agile methods were developed as a response to the issues that waterfall and V-model methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed. From www.agiletesting.com.au A software tester’s role in traditional software development methodology, a.k.a waterfall & the V-model can be ...
Michael Hackett sat down with FNC’s Chris Floyd to get his take on numerous Agile topics.
Build the right test platform including infrastructure, virtual lab and process. Testing embedded software is both similar and dissimilar to application software testing. The first eye-catching thing is that embedded software is significantly less visible to the end user. User interfaces are limited; there may be a console-based text menu, a simple command line interface, ...
How to fit automated testing into scrum, and keep testers in sync with other teams One of the benefits of the approaches of agile projects is their friendliness towards testing. The testing activities, and the testers with it, are integrated into the teams, and testing and quality are redefined as team responsibilities. Automation nowadays is a must-have ...
Distinguishing these terms from each other can be rather confusing. In an attempt to go back to the basics, Nadine Schaeffer explains in detail the benefits and the necessity of using realistic situations.

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe