Join Doug Rose for an in-depth discussion in this video Purpose of agile retrospectives, part of Agile at Work: Getting Better with Agile Retrospectives.
- View Offline
- Retrospectives have been around since the beginning. After running the agile manifesto, the alliance listed out several core principles. These principles clarified the shorter agile values. One of the principles says that at regular intervals the team should reflect on how to become more effective, then adjust their behavior. So the team should reflect, tune and adjust. In many ways, the retrospective is about the team being agile with their own improvement. They use the same ideas to turn their efforts inward to reflect on how they can be a better team.
Typically, the team will meet for 2 hours on the last day of every sprint. Then they'll reflect on things that went well and what can be improved. Agile retrospectives are a very lively area. Norman Kerth first used the term around the same time agiles started. Since then, there have been numerous books written on how to run a good retrospective. Still many organizations see retrospectives as a time waster. They feel they are hiring developers to focus on the product. They shouldn't spend time reflecting on their work. In sense, they're saying that the team is too busy working to try and improve.
Some organization say this explicitly while others just give the team lukewarm support. They're welcome to reflect, they just need to do it when all the work is done. This is just another way of saying, never. The scrummaster has to work closely with the product owner to make sure that the team has this crucial reflection time. Without a retrospective, the team will continue to make the same mistakes. They won't have time to inspect, improve and adapt. I once worked for an organization that had a real challenge scheduling their team's retrospective.
The team had a reputation for spending too much time playing with new software. Some managers even joked that they were too busy downloading software to spend time building software. There was some truth to the criticism. That's one of the reasons the team was trying agile. When the scrummaster talked about retrospectives, it looked like history was repeating itself. When managers heard the term reflection, they imagine the team spending hours researching the latest software tools. The managers' view was the team could reflect as much as they wanted after the product was delivered.
Yet the product owner understood the value of the retrospective. They'd been to the training, they also saw the team getting better. They were improving over time and the product owner knew that this was part of the process. The scrummaster and the product owner convinced the senior manager to sit in on a retrospective. The scrummaster facilitated the first retrospective so they could explain the process. All the developers met in the room and immediately started talking about the project. The scrummaster asked the team to list out what went well in the last 2 weeks.
They listed out on the whiteboard and then they asked what could be improved. The developers sprung to life then came up with many areas of improvement. Most of them were about communication and an outdated process. After the retrospective, the senior manager felt much different. They liked how the event was structured. They also saw that without this reflection, the team would make the same mistake over and over. If you're the scrummaster for the team, try to keep these points in mind. The retrospective is a time for improvement.
Keep this meeting structured and productive. It isn't an informal gathering. The team should try to record everyone's ideas. Then they should create action items and even use some communication games. All the time in the retrospective should be planned and organized. That's why many teams use an outside retrospective facilitator. Also keep in mind, retrospectives are one of the most misunderstood agile events. Some development teams see this as a biweekly brainstorming session.
They focus on the software. This isn't the purpose of a retrospective. It's about improving the team. It's about helping the team work better together.
Watch and learn agile project management techniques to assess your project today, and get back on track for tomorrow. Find more courses on agile project management in the Agile at Work series on Doug's author page.
- Five phases of retrospectives
- Choosing an ideal meeting space
- Identifying issues and improvements
- Working with a distributed team
- Encouraging discussions
- Setting goals using SMART criteria
- Asking good questions
- Making team decisions
- Closing out an agile retrospective