If you go back to the article on Scrum Meetings one of the regular meetings that is expected to happen every Iteration or Sprint is the Retrospective Meeting. However, in real life scrum projects, many people actually skip the regular retrospective meetings for a variety of reasons (we will get to that in a bit) and just continue working on the project. The purpose of this article is to help you decide whether your scrum team (or Project) requires a retrospective meeting at the end of each sprint.
Reasons Scrum Teams Give – For Skipping Retrospective:
Whenever we talk about doing a retrospective at the end of the sprint, one or more members of the scrum team may have some reasons or should I say excuses as to why a retrospective isn’t needed. Some of the popular reasons include:
- They are boring, nothing fruitful comes out of these meetings
- We have real work and cannot waste time in such meetings
- We are very good and have delivered a lot of story points in this iteration. So, can we skip it?
If you have been a Scrum Master, chances are that you would’ve heard either of these or maybe some more reasons on why they want to miss the retrospective.
Are Retrospectives Really Boring?
A retrospective meeting isn’t one of those meetings that gets everyone excited. Nobody likes to look back in time to figure out how things could’ve been done better. This is where the role of the scrum master comes in. The scrum master needs to the keep the discussion focussed and not become a finger pointing blame game. The scrum master should mix things up by asking a different team member to facilitate the retrospective every time and so on. The next article will cover the topic about how a Scrum master can run an effective retrospective meeting but you get the picture right?
Can a Team be too busy for Retrospectives?
Retrospective meetings are part of the work or job description for a team that is doing scrum projects. Realistically speaking Yes, there may be a few instances where the team could be really busy like toward the end of the release (Last iteration) and people are scrambling through to get the last few bugs fixed. During these situations a smart scrum master would wait until the tight deadline related activities are done and then schedule the retrospective.
Have you heard of the story of the woodcutter who took up a job in a log house?
A very strong young man took up the job of a wood cutter in the local log house. He was big and strong and could easily crack a log in two with a single blow of his axe. During the initial few days the log house owner was quite impressed with his ability and saw that he finished up his pile of logs fairly easily. As days went by, even though the guy was as strong as he was before, he took more and more time to finish his job. The same log that broke in two with a single shot now needed three or four shots each. No matter how hard he hit the log, it would still not give in.
Can you think of a reason why?
The young man, too busy in his quest to finish his work quickly, kept pounding away on the logs without thinking about whether the blade of his axe was still sharp as before. He is still the same but his axe has worn out due to the continual use and if he had spent maybe 15 or 30 mins every week to sharpen his axe, his efficiency wouldn’t have come down.
Yes, cutting logs is his job and sharpening the axe may be considered a low-value activity but if you think about it, this 15 or 30 min sharpening will ensure that he is able to continue his output with the same level of efficiency.
Get the picture? This is what Retrospetive does for your Scrum team. This 1 hour you spend every sprint will help your team identify improvements and work towards them.
Can a Team be Too Good for Retrospectives?
Yes, this is a very real possibility but even teams that have been doing scrum for many years still spend a few hours regularly to do retrospective because you will always be able to identify ways to improve. It is highly unlikely that the team is so good that, there are no further improvements either to be identified or worth implementing.
Some Last Words:
One of the key aspects of Scrum is the ability of the team to inspect and adapt. This by definition means that we regularly introspect and understand areas that we are doing good/bad and continue on the good ones and improve on the bad ones. Having the Retrospective Meeting is the disciplined approach for the same.
The retrospective meeting gives the team an opportunity to inspect what went well/not so well in the last sprint and make adjustments. This is crucial in any scrum team and is not one of the meetings you can skip. Even if your team is resisting to the idea of doing frequent retrospectives (like in a team with 1 week Sprints), you should try to schedule periodic retrospectives at least every 2-3 iterations to make sure the team can polish their axe and avoid slowing down.
What is your take on retrospective meetings? Sound off on the comments section for the benefit of the others….