Traditional project management encourages post-mortem (lessons learned) at the end of the project. This ceremony is great as it provides a moment in time to think about events in the project that lead to the results. There is, however, one important disadvantage of this approach. It is a post-mortem, the project is done already. There is no possibility to improve it, it is only possible to learn from mistakes and apply this learning in other projects.
Team in a retrospective
Agile is different. We want to improve our way of working while project/product development is still active.
The retrospective is a regular meeting of the team for continuous improvement practices, processes and also feelings of team members.
Once this is a regular event, team members can think about blockers and ideas continuously and improve the way of working constantly. In such a case, a big change is split into multiple small changes that even can become a reality hence improving the motivation and engagement of the team. Remember, any change slows down people. Regular retrospective helps to have that change trench shallow and narrow.
Satir’s model of a change
- Identify system constraints and waste.
- Get ideas for improvement.
- Identify what works properly.
- Prioritize proposals.
- Draft an action plan for the implementation of selected and preferred ideas.
We see the Product Owner as part of the agile team. All have one common goal. To deliver a working product. Therefore they are in the same boat. Just with different responsibilities.
These are prerequisites why the Product Owner should actively participate in the retrospective as other team members.
- Organizes and moderates the meeting.
- Identification of the topic of Retrospective.
- Selection of a technique for getting ideas.
- Informes about the resolution status of previous proposals.
- Keeping track of proposals and their resolution
- Proposes ideas.
- Votes for ideas to be implemented.
- Agrees on how to implement the most important proposals.
- Identifies the tasks for implementing the selected proposals.
A great retrospective has the following parts:
- Set the stage– ScrumMaster introduces a theme of the retrospective. Experienced ScrumMasters often use some kind of games or activities to open the retrospective and make it more fun.
- Some techniques for Set the stage: Appreciation postcards, Explorer-Shopper-Vacationer-Prisoner, Focus On/Off, Temperature reading, Weather Report, Check-In question, Amazon review, Three words, Greetings from the iteration, Alignment check, Emoticon project gauge, Happiness,
- Gathering data – team members write down ideas with help of some retrospective technique. For example Star Fish, Mad sad glad, 6 thinking hats, 4L, Start Stop Continue, The Wheel of Change, Speed Boat, PMI, Repeat Avoid, WWW, KALM, DAKI.
- Understanding – the team sorts ideas, group them, tries to understand them so they know what needs to be done to implement ideas and solve problems identified. Techniques: 5 Why, Fishbone, Causal Loops Diagram, FLAP diagram
- Decision – voting and discussion about selected ideas and implementation proposals.
There are many retrospective techniques for gathering and understanding ideas. For example,
The simplest way of data gathering
The simplest technique is Good-Better.
- ScrumMaster identifies a theme of the retrospective. The theme is selected based on the life of the agile team in the last (or last few) sprints.
- The team is silently thinking about ideas and writing them on post its. One post-it per idea so we can work with them later. The time is not strict, ScrumMaster should observe if more time is not necessary to provide a space for team members to give feedback.
- The team will read ideas and group similar ideas into groups.
- The team votes for ideas (groups). Every team member has three dots as a budget which can be distributed on ideas.
- Once the voting is done, ScrumMaster prioritizes ideas based on the number of votes.
- The team then discusses the first 1-3 ideas and proposes implementation tasks that can be added to the Kanban board for the next sprint.
Retrospective ideas with votes
- A priority list of new proposals.
- The updated proposals solution state from previous Sprints.
- Identified action items for design solving.
- Tasks are assigned to the team members and the deadlines are set.
Analyze ideas, problems
To analyze the problems the Agile team can apply root cause analysis techniques, i.e. 5 Why, Fishbone, Causal Loops Diagram, etc. Some problems are better to analyze more deeply to solve the real problems, not just symptoms.
Casual loops diagram example (in the Slovak language)
How to discuss and realize ideas
It would be wrong if the team tried to implement ideas without a deeper understanding. Such changes often fail and make things even worse.
A very nice approach is to introduce Lean Change Management (by Jason Little) into the implementation of ideas as every idea is, in reality, a small change.
Every problem is suggested to solve with help of these steps:
- INSIGHT – analysis of the problem from different perspectives.
- OPTIONS – identification of multiple options that should be considered. It is even suggested to try multiple options and choose the best one (similar to A/B testing).
- EXPERIMENT – the goal of the experiment is to validate expected results defined by options.
Lean change model
How ScrumDesk supports retrospectives?
ScrumDesk is very unique Scrum project management tool that comparing to other tools supports retrospectives in roots. ScrumDesk provides multiple retrospective techniques with voting, ideas categories, colorized cards, notifications and synchronized changes.