Recently, a LinkedIn discussion on retrospectives (retros) caught my attention. A person asked, “Should retros be done before ending a sprint and avoided during the next one?” While some practitioners listed some good answers to this question, I have a different take on this topic.
I want to address two popular mindsets that team members have about retrospectives: Retrospectives are done only at the end of a sprint or a project, and they are done to identify “what didn’t go so well.”
In reality, I have found that retrospectives support an “inspect-and-adapt” approach and are needed for continuous improvement. Agile teams are able to get together at any time and reflect on what’s going on in the project and how to work better. Having a “do-only-at-the-end” mindset dilutes the real intention behind retrospectives.
It’s possible that some teams might end up waiting until the end of the sprint to find a better way of working. Continuous improvement should happen on a daily basis and not simply once an iteration.
Additionally, retros should not be used to find faults; they are a platform in which team members can find better ways of working and learning. What you focus your question on makes a lot of difference.
Incidentally, people deviate from the original purposes of other agile practices, too.
Daily Scrum meetings have become overrun with team members who only use the sessions to discuss issues and blockers. This practice is so ingrained in team members’ minds, I’ve seen many practitioners wait until the next Scrum meeting to raise further issues and blockers. A better way of working would be for a leader to allow the team members to raise issues and blockers any time they sense it.
Planning and estimation are two other practices about which some people have misconceptions. Some practitioners believe that planning and estimating should only be done at the beginning of a sprint. I’ve found that teams always miss the “daily-plan” section of the five levels of planning and tend to forget daily estimation as well.
In conclusion, having a rigid mindset in which you believe that teams should only do retrospectives at the end of an iteration or raise issues only during standup meetings reduces agility, which results in process-oriented thinking.
Have you seen similar patterns in your team recently?
Venkatesh Krishnamurthy is an author, speaker and a coach. In his 15+ years of career in the software industry, he has played different roles as a developer, architect and an Agile coach.