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 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 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

Michael Hackett sat down with FNC’s Chris Floyd to get his take on numerous Agile topics.
This is part 1 of a 2-part series. The 1st part will discuss the culture and mindset around Agile, and how Agile Quadrants are used. Part 2 will discuss how to use the Agile Quadrant, the significance of Automation in Agile Quadrants and how to use Agile Quadrants to overcome Quality Assurance headaches. Organizations aspire ...
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 ...
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 ...
SKILLS Agile teams need training! One of the missing links in the implementation of Agile development methods is the lack of training for teams. I noticed in our recent survey on Agile that only 47% of the respondents answered “Yes” that they had been trained in the Agile development process, with over half responding “No.” ...
Writing code that is easy to read and easy to test is difficult to achieve. The fact that poorly written code can function often leads to coding practices that are effective but not necessarily efficient. Too often, many programmers fresh out of school write code in the manner that was effective for passing their courses, but contains ...
Agile stresses instant and easy communication and is built on teams working efficiently together. This necessitates an open work space environment. A characteristic of an effective team is a high level of collaboration, making the physical work environment an important factor. Cubicles should be eliminated in favor of an open work space in an effort ...
Agile Automation Michael Hackett – Senior Vice President – LogiGear Corporation Michael Hackett Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the ...
Over the years many Agile proponents have come out strongly against offshoring some of the development team, and in particular against having a remote testing team. We made use of not one, but two separate outsourcing providers located in two distant locations. While we had many challenges, what we found was that by starting with ...
LogiGear Magazine – July 2013 – Agile Testing
Team collaboration is essential for testing embedded systems. Developing software for an embedded system often carries more risk than for general purpose computers, so testing is extremely critical. However, there still has to be a good balance between time spent on testing and time spent on development to keep the project on track. As consultants ...
Take our quick survey on Testing in an Agile Development Team! 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. There are many positive things about the move to be more Agile and responsive in software ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news