Question

You have just completed two (2) projects in your assessments, Assessment 2 used the PMBOK method, Assessment 3 used the Agile Method.

You have been asked to conduct a review on both projects. With PMBOK a post project review focuses on what went well, issues and any improvements for future projects (Learnings). For Scrum it is done after every sprint in the Sprint Retrospective.

Describe what issues had you experienced with the Agile project in the Sprint Retrospectives

Answer 1

Describe what issues had you experienced with the Agile project in the Sprint Retrospectives.

There are four issues or problems that expriced with the Agile project in the Sprint Retrospectives.

1. People Aren’t Honest or Trustworthy

One of the most common complaints about retrospectives is that people fail to bring up real issues or admit to their problems. If people aren’t going, to be honest in a retrospective, the argument goes, they’re a waste of time. That’s actually probably true. But the solution is not to abandon retrospectives. Rather we need to focus on getting people to be more honest and open during them.

2. Retrospectives Are Boring

It’s fine to have a few standard ways you like to run retrospectives, just like it’s fine for a rock singer to have a few go-to moves that are repeated each concert. But you can’t do the retrospective the exact same way every time and expect people to remain engaged.

3. Retrospectives Aren’t Effective

There are enough agile teams around the world who will attest that retrospectives are effective for them. So if you feel your retrospectives are not effective, you have to look at how you’re running them. Retrospectives, when done well, are an effective way of identifying and choosing new ways to improve. I really don’t think there’s a lot of room to argue against that. An argument can be made, however, that retrospectives are not cost-effective for a given team. That is, the improvements that result from the retrospective aren’t big enough to justify the time spent.

4. Retrospectives Don’t Work for Distributed Teams

There are a few things you can do that help.

First, I think video is a must for a distributed retrospective. Don’t try to do a retrospective just with a conference call.

Second, any sort of collaborative editing tool can be used for the meeting. Encourage all participants to type new ideas into the tool. That should not be the sole responsibility of the Scrum Master or other facilitator.

Third, keep your retrospectives short and frequent. Do this despite what I said in the previous section about maybe doing retrospectives once a month rather than every two weeks once a team is great.

Long meetings are never fun, but they’re particularly painful when not in person. Even worse, if the team is spread across very distant time zones, it’s quite likely that part of the team is staying late to participate. Team members in that city are unlikely to bring up big issues that will just keep them in the office even later. So, short retrospectives are better.

Fourth, do anything you can to keep retrospectives fun, especially when meeting remotely. Common practices such as having each person share something they appreciate about someone else on the team can help here. If someone always brings food to the retrospective in your office, find a way to get snacks delivered during the retrospective to people in other cities.

Fifth, during a distributed retrospective it may be worth the extra effort to ask team members to assign responsibility among themselves for the various changes that have been agreed upon.

I don’t normally do this with a collocated team, reasoning that they’ll discuss it and figure it out collaboratively throughout the iteration. But things seem to fall through the cracks more often with distributed teams, so a little time spent discussion which team members will take responsibility for working on each change is worth it.