Sprint retrospective

Introduction 

 

For those who are not familiar with the term Scrum, it is a framework that helps in managing team and project development. It is a part of a larger Agile methodology which principles it applies. We can certainly say that most of the software companies use Scrum or some other alternative Agile framework for managing their project. This popularity probably rises from its flexibility that allows a team to quickly adjust their process to the current needs of a project, but still not allowing them to divert from the project goal course.

This flexibility actually creates love-hate relationship towards Scrum methodology. Also, you couldn't find two companies that carry out Scrum in the same way. Most of the teams I've met get irritated when a pattern or event that worked great in the other company doesn't work well for them. One of such patterns/events is a sprint retrospective.

Sprint retrospective 

 

Sprint retrospective is a team meeting, usually done in the end of development iteration (i.e. "sprint"), where team discusses about events that happened in the past iteration and solutions they can provide to improve following iterations. These events are usually categorized by the certain way. Here, I'll describe one way of categorizing those events. We'll categorize events in five groups:

1. Start - things we didn't do in the past, but it would be beneficial to start doing it.
2. Stop - things that blocked us to make a progress in our iteration. Usually, things in this category should be handled as a priority.
3. More - we identified things that helped us become more efficient.
4. Less - we identified things that made us less efficient.
5. Stay - things that are proved to be good at the last iteration and we should keep doing them.

Picture 01 - Sample of sprint retrospective board

Process

 

At the beginning of the iteration we draw a section for each of these categories on the whiteboard (see Picture 01). During iteration, team members are allowed to write their suggestions on the board. Once the iteration completes, Scrum master will review the board and prepare the team for the meeting. Entire team discusses of each suggestion and comes to the conclusion. These discussions should be done in three steps:

1. need - identify reasons why this event/suggestion should be beneficial or damaging to the team
2. decision - entire team needs to come up with the decision whether to accept or decline the suggustion
3. action - maybe the most important part. As before, the entire team needs to come up with idea of how to carry out the proposed solution in the following iteration.

Once the Sprint retrospective is finished, all the meeting points and tasks should be documented and shared between team members. Also, it would be a good practice to briefly review these previous meeting points before new Sprint retrospective in order to determine if we failed in providing identified actions.

Known issues

 

One of the main issues here is carrying out the actions we agreed about. This happens a lot. Most of the time it happens that team members simply forgot about performing them. It even happens to people who suggested them in the first place. And this is perfectly OK (I can't emphasize this enough). The worst thing that can happen is to blame each other in the team for not doing his/her job.

The reason why this usually happens is that we all get overwhelmed by work, so we don't have much time to develope an action as a habit and therefore we'll probably forget about it.

I've seen that Scrum masters usually start by introducing new rules for following certain actions. Sometimes they are printed on a sheet of paper and shared between team members in order to remind them to behave a certain way in a certain situations.
This doesn't work in most cases. Due to a fact that humans are usually very defensive when they are forced to do things in a certain way.
Blaming people is also not the way of handling issues, due to a fact that it won't make any grownup person fill better or even perform better.

So what to do? How to make people remember? 

 

It is important that all actions we identified as beneficial should become habits and this takes time. It is my personal experience that the best way is to start small by picking 2-3 actions from a list and making a decision within team members that we'll work on these things in the following iteration. Don't force anything. Not all team members will remember to follow them, usually they simply forget or they don't see the benefit yet. But, at the next sprint retrospective you should make sure to recommend team members who followed suggestions and performed the actions. Also, it is important to underline what benefits this had to our project. This way we can attract other team members to become more engaging.

Conclusion

 

There is no easy way to apply a certain process methodology within your company. In most cases we should balance between adjusting methodology frameworks towards team behavior and modifying team habits toward project goal.
It is important that there is no brute force approach to solving this problem. There is only the way where all team members work together on making their work environment the most enjoyable and productive one.