Part of the Scrum methodology is the Sprint Retrospective. This enables the development team to reflect on the past sprint, and determine aspects that can be improved. It is the Sprint Retrospective that drives the team to continuously improve their development process.
Despite the goal of the retrospective to improve the way of working, it is often a problem to come up with a retrospective that meets this requirement. So should we have a retrospective about the retrospective? Though I have little experience with working in agile teams, and I am certainly no expert of Scrum, I still feel that the Sprint Retrospective often falls short. The reasons I think of it this way, is the topic of this blog post.
A traditional Sprint Retrospective is always pretty short and has the same pattern each time. The Scrum Master asks 2 questions:
- What did we do wrong?
- What did we do well?
Do you find these questions hard to answer? Well, I do. I am certain I am not the only one who thinks of it this way. Though I sometimes feel that a way of working is not perfect. But can you say that something you did as always, is something you did wrong? The biggest problems with these questions is that often you only talk about things you did yourself. It tears up the entire team into individuals, which is something that goes against Scrum.
But even if someone is able to identify a thing that went wrong, moving it from something that is said to something that can be done, or should not be done in the future is a huge step. An action point should be made out of it, as it is clearly something that was identified as being bad. But finding the right action point, to make sure it will be better in the future is hard. Even harder is enforcing the action points, people often fall back into their routine. But the entire idea is to change things around, and thus the habit needs to be broken. Finally it is important the actions taken are re-evaluated and changed if necessary. All of this requires a lot of time, and a lot of effort from everybody in the team, but especially the Scrum Master.
The Scrum Master is a crucial role as he guides the team in unveiling problems by asking questions. The Scrum Master needs to have all the right characteristics, but not only the skills of the person matter. The position the person executes (or did in the past) matters as well. The Scrum Master must be objective, he is the referee that watches and makes sure all rules are enforced. To enforce this the Scrum Master can not be someone that ever had any control over the team. Doing so violates the Scrum principle that says a team should be responsible for its way of working. Where in reality the team still depends on the ‘Scrum Master’ for approval.
Even if the Scrum Master gives the team complete freedom to make their own decisions and choices, there still is the risk of the “invisible gun” effect. Where they are afraid of saying things that will be bad for their career.