This article talks about the least important meeting in a Sprint, the retrospective meeting, at least as considered by the business and sometimes also by the developers.
It is often considered to be a waste of time and given the least priority, and sometimes even omitted if there are time constraints.
In fact it is the most important meeting but does not show any immediate business value.
Talking about my own experience, we were newly into the project and the geek in the team was not getting enough technical tasks to devour, resulting in not so good documentations by him and his general disinterest in the team.
This was discussed in the retrospective and his problem was faced, assessed and solved within a span of two weeks (a single Sprint), and he was given enough tasks to fulfill his coding appetite, resulting in better output by the entire team.
Talking about retrospective techniques, the most effective way to conduct a retrospective is the Timeline Review.
The team starts on a whiteboard where the time line is drawn as shown below and the team discusses: What went well, what did not go well and what should we keep doing.
Image Source: Google Images
The business should not be a part of this meeting as the team should feel comfortable enough to discuss their concerns. The aim for a retrospective should be more to get the team to come up with their issues.
Any thing that went well deserves a pat on our(team’s) shoulders, and it becomes the responsibility of the scrum master to make sure the grievances are addressed.
While reading the graph we should follow a sinusoidal pattern which means we get an idea on what went well and what did not go well at a particular time in the Sprint. This would help us understand if at any point in a sprint, any team member is facing issues due to other dependencies.
Image Source: Google Images
For Example: In my team we needed data on the go for some ongoing tasks, the other team sometimes failed to give it on time resulting in non completion of the task and so we decided that if we do not get the inputs before the start of the sprint we will take the task which we planned for the first half of the sprint. This was a small issue which had a simple fix but could be addressed only after the team discussed it in the retrospective, or else it would keep on affecting the team's velocity.
Keep on noting down the feedback from the team members.
Once the team is matured the time of the retrospective should go down but it is supposed to be a dedicated meeting until that level of maturity is achieved.
Now, since the team is matured it has more knowledge about the process and flow. They are now in a better state to suggest changes in the project flow.
Other methods can be taken up once the team is reaches this point, one effective method is ‘Starfish’
Image Source: Google Images