Code Library

The sprint retrospectives have proved very efficient throughout this case study. At the end of each sprint, the team discusses what went right and wrong and decides how to improve these items for the next sprint. Having the team own its own process within a framework is ideal because each team member is a part of something and is not forced to do anything unwillingly.

Creating a safe, trustworthy environment for team members to speak is crucial. You may notice that certain people will want to constantly speak on things and others will simply blend into the background. To create a trustworthy environment, the ScrumMaster or team members need to notice when someone is taking control of a meeting and halt it so that others can speak. As for those who prefer to blend in the background, it is up to the team to encourage them to speak. Be an advocate for them to speak their minds. You may notice that the quiet ones have profound views on things.

Retrospectives are worthless if team members don't feel as if they can speak up or they don't have confidence that things will change as roadblocks are uncovered. Good, safe, clear communication is key to evolving a team and evolving any process. There needs to be good facilitation skills present to help with this. Normally, you can find these skills in the ScrumMaster or Agile coach, but it does not have to be limited to them. Team members can also bring these skills to the table. Retrospectives are a fantastic way to have the team own and improve their own process.

There were milestone action items that came from retrospectives, including the importance of pair programming and the importance of having an available customer and/or product owner. Be sure to occasionally change your activities on how to conduct a retrospective. You saw that the team started doing the retrospective one way and then switched to the retrospective game “The Soup” to get a better understanding of the issues the team was dealing with. As with anything, repeatedly doing the same thing gets dull and you may not see a problem unless it’s presented from a different angle. If retrospectives get dull, they are no longer useful and you may as well discontinue having them because they become a waste of time. While not advised, teams have skipped a retrospective because they didn't think it was useful. Sometimes it may be more fruitful to not have a retrospective, as long as the team has an effective retrospective at the end of the following sprint.

Be prepared, have a variety of different activities to gather what went well and what didn't go so well during the sprint. You don’t have to change how you run retrospectives at every sprint, but try something new and give it time to work. If it doesn’t, then throw it out and try something else. If you are a ScrumMaster on a team, check out books or blogs on retrospectives. For example, the book Agile Retrospectives by Esther Derby and Diana Larsen (Pragmatic Bookshelf, 2006) is a great resource for discovering different ways of running a retrospective. These sources can yield a plethora of ideas on how to run your retrospectives. This keeps the team members alert and alert team members are more willing to give constructive feedback. That's what we want!

Also, make sure that the action items that come out of the retrospective get acted upon and resolved quickly. If the same painful action items appear week after week, there's nothing more damaging to a team's morale than to see that nothing is being done to update or resolve these matters. Have each action item assigned to one person on the team, even if the action item concerns the entire team. It's that person’s responsibility to follow up and make sure the action item is getting handled.

If an action item gets carried over from sprint to sprint, throw it out. It obviously wasn’t important enough to work on or it would have been completed. A truly important item will come back again.

By completing action items, the team gets a sense of accomplishment and confidence in the process. Presenting ways to improve a process and seeing nothing come of it is death to a team. Eventually team members become disconnected from the entire process. Without the team working together, you might as well go back to the old way of doing things. Remember, agile is excellent at bringing the weaknesses to the forefront, but solving them is your job—make sure you solve problems quickly to build team moral!

Source of Information : Pro Agile .NET Development with SCRUM