By Andrea Gran
My experience with retrospectives is mainly from agile scrum teams. At the end of each sprint we would run a combined retrospective and planning meeting. At the start of the meeting we would check the current status by looking at metrics such as; velocity, load factor, defects, bugs and capacity. This would sum up the facts and form the basis for the retrospective.
The techniques I have used most is to discuss emotional ups and downs and to use post-it-notes with color coding
Emotional timeline approach
- Draw the sprint timeline
- Each team member draws a line with emotional ups and downs during the sprint
- Each team member discuss the ups and downs and what he or she would like to do different next time
- If several team members experience the same challenges, the team discuss the challenges and decides what to improve for the next sprint
- Use post-it notes with different colors
- Red: did not go well
- Green: did go well
- Orange: do different next time
- Each team member writes on the colored post-it notes and posts it on the whiteboard divided in;
- What went well (within team/outside team)
- What did not go well (within team/outside team)
- What to do different next time
- Prioritize and vote for the most important thing to change
- Focus on that the next sprint
I found the above two are sufficient after a 2 week sprint. A retrospective meeting is a positive exercise for the team as it works as an opening for everyone to contribute in improving the process and the team. I mostly see it as tailoring the process to the individual teams need and think that there will often be some basic elements related to the process that each team within an organization follows, but at the same time each team will still tailor the process to best fit the teams need.
In a traditional project planned with a waterfall approach it does not come natural in the schedule to set time for retrospectives. Therefore it is more common to do this at the end of the project, an approach for a retrospective could then be to combine the above two:
- Build the timeline
- Let the team build the timeline
- Each member adds significant project events on the timelin
- Use flip-charts to answer the questions:
- What went well?
- What did not go well?
- What to do different next time?
Also for traditional projects it is good to start with some metrics; such as project cost, effort and schedule. In a sprint the sprint goal would be defined up-front as it would with a project, however when a project is long-term and ongoing for a year or more it is beneficial to spend some time at the beginning of the retrospective to define project success to get hold of the learnings from the project.
Andrea Gran has worked in the IT industry for 16 years and has experience from different roles like developer, development lead, architect, test manager, agile project manager and scrum master. She is now working as a project manager managing traditional projects.
Article source: http://www.pmhut.com/project-retrospectives
Powered by Facebook Comments