In a previous article I talked about failure (check it out: here) and how we can use it to give us a positive advantage, a driving force for innovation and improvement. I also mentioned a tool I sometimes use to identify these areas for improvement called a retrospective. Retrospectives form an integral part of a project that is using the Agile framework – I would also argue it should be integral to every and any project, regardless of the framework that the project adheres to.
A retrospective is a process that encourages you to look back and learn, providing teams, projects and organisations with a good way of ensuring that there is continuous improvement. Learning from past mistakes and things you have done well can often be the key to future success. Often when we only look ahead we can have an “optimism bias” which can lead to underestimating work and not anticipating potential problems with .
The retrospective process
Retrospectives allow a team to look back on the last iteration of work (the last sprint) and highlight what went well and what can be done to improve the efficiency and effectiveness of the next iteration. Generally a retrospective meeting will have 4 parts to it:
1. An introduction
- Throw down some ground rules so everyone is on the same page
- Highlight that this retrospective is about continuous improvement and you should share whatever you feel will allow the team to improve.
- Highlight that improvement sessions and criticisms shouldn’t be personalised – it is a team effort and the team as a whole are looking to improve
- Everyone should listen with an open mind, remembering that everyone has a valid opinion/experience
- What is the scope of the retrospective? A sprint? A month? The last quarter?
2. The positives first – what went well?
Provide post-it notes or simply ask people to shout out. Personally I have found post-it notes more effective as some people who aren’t comfortable with yelling out their ideas will be more than happy to write them down. Similar ideas should be grouped together and the team should discuss each of them
3. What needs to be improved?
This flow is the same as above and should have some clear actions going forward. The team should be reminded this isn’t a time to get personal and pass the buck.
4. Take action
Discuss what actions, owners and due dates can be assigned to tackle these improvement areas. This can also be done as a post-it exercise, allowing the team to provide ideas for actions that could be undertaken by the team.
It’s also a good idea to switch up the retrospective facilitator in order to keep things fresh and to allow for increased buy in of the team.
Don’t forget the “what went well”s!
I think quite naturally we gravitate to what can be improved and gloss over what has been done well. I believe it is very important that sufficient time is given to praising the team for what they have done well and working out how this can be kept up as to not compromise the integrity of future sprints. One important talking point that often gets missed with relation to what went well and improvements is whether internal company processes were followed correctly during the sprint. Internal processes can be a big driving factor for continual quality and integrity of work.
What if I’m not running an Agile project? In general most project management frameworks have some sort of feedback loop in which lessons are captured and have actions assigned. I think the most important thing is that if there is any iterative behaviour within your project, e.g. you have several software deployments in scope for this one project, then you should have frequent retrospectives that line up with those iterations. This will facilitate continuous improvement within your project and will help to increase the quality of the final deliverable.
It is also worth running retrospectives at the programme level so that improvements can be made at a higher level within the company by understanding how various project groups are run well and where improvements can be made.
Want to make your retrospectives more fun? Check this website out: http://www.funretrospectives.com/ – I quite like PMI myself.
Do you use retrospectives? Do you have any useful tips/tools you use?