Retrospective - what are the issues you encounter?

A retrospective should look back on the action items from the previous sprint, but this is often forgotten. The result is "drift". Sometimes it can be necessary to raise a ticket for retrospective action items and add it into the Product Backlog, or reduce the story point budget in an upcoming sprint so they can be done. In most cases this is overkill, and pinning action items above the scrum board will be enough...but if an item is likely to take significant time then this needs to be accounted for transparently.

You say that you have had difficulty with root cause analysis. Have you tried asking the "Five Why's"? This is a kaizen technique that is often applied within Lean and Agile workflows: http://en.wikipedia.org/wiki/5_Whys

You've likely run across this already, but Agile Retrospectives is a great book (http://amzn.com/0977616649). I'd also recommend a tool like https://www.mercuryapp.com/. You can certainly track things with a simple set of stickies or a wiki, but the problem always becomes remembering to do so. MercuryApp.com helps remind us, but then again that's part of what the SM's role is.

Do you feel like you have an objective, capable facilitator in the retro? Is it possible the SM is getting too involved and engaged in the Retro that they aren't able to facilitate or help coordinate time management? It's for situations like this that the Scrum Master should not be pulling double-duty as a Development Team member. They need to be objective and disconnected from the outcome of the team's choices so as to help elevate the team.

I've always done 1-hour retrospectives every two weeks. I typically do

- 30 minutes of data gathering
- 5 minutes of basic grouping (and voting on topics, if there are more than 3 or 4 groups)
- 30 minutes of root-causes analysis and corresponding action items

I like to limit the analysis / action items to 3 or 4 items, which I can pretty easily keep track of as far as time goes (5-10 minutes a piece).

I try to schedule them for the last hour of the day on Thursdays or Fridays, regardless of when the iteration ends, and it's worked really well so far. I should note that I come from more of an XP background than a scrum background, so there tends to be a little less weight to the concept of a sprint ending.

I always like to end at exactly one hour, even if there are still items to discuss, so that people always know that I value their time outside of work (since the retros happen late in the day).

As far as who runs retrospectives, if there is a new team member, I always ask them to run it - especially if they've never run one before. They typically have the least amount to contribute if they've only been there a short time (a few days) and they tend not to dominate conversations. After that, I like to rotate through team members so everyone gets comfortable leading retros. I've found that team leads running retrospectives is only a problem if they do it often. If they are just one part of the rotation, I haven't noticed any issues with that.

I've never really been able to get to 5 why's, but I've found that getting to two or three is often enough to come up with some action items that can help move things in a positive direction.

The biggest problem I've noticed is that some themes come back over and over. I haven't seen a good tool that's worked for me to deal with this, so I'm currently building one (http://retrospectr.com/) to try to help with the retrospective-memory part as well as helping remote team members participate more easily.

As far as team members participating actively, one technique I use very often is the "talking stick" - I bring a small plush toy and ask people to pass it around in order 2 or 3 times and throw out one data point / piece of feedback. That usually lasts about 10 minutes, at which point people just sort of throw things out. I've had a few teams where we kept throwing the fuzzy duck around just to keep order, but those have been rare.

Hi Jeff

Did you try doing some 5 Why's (or 2 or 3) into the reasons for certain themes recurring? Maybe it isn't within the team's power to resolve the underlying issues. If so then there could be an external impediment that needs to be flagged to management, assuming the Scrum Master can't find a way to unblock it directly.

Interesting point. I've never done a formal 5-whys for why themes reoccur - I've always focused on the item itself. We have done things like reassign action items to different people (sometimes the person assigned was too busy to get them done). That's a great idea though - I'll give that a shot the next time an issue reoccurs in a retro.

" themes come back over and over."

As opposed to tracking them, what's stopping those recurring themes from being resolved? That would seem the greatest retro improvement to me.

Hi Barry.

We do our Retros after the review, so there is no way to "keep working" cause it is not part of the sprint time-box.

May you can try to make an improvement backlog nad do it the scrum way. try to gather all the problems and put it in the backlog. Priorize the backlog and then discuss the highest valued problems (1 or 2) where you are able to make changes during the next sprint. Keep the improvement backlog, so no once found problem disappears. And then make for the improvementbacklog item you are planning to do in this sprint, a "sprint planning 2" how it can be fixed, and may make one difference to the normal scrum-flow, let the members choose then what "task" they can do to make the improvement.

Ryan: since I haven't really dug into why things weren't being done too much, it's hard to say. My guess is that for the most part it's because things are out-of-sight-out-of-mind, since I trust that the people I work with have good intentions. But until I spend some more time on it, I can't really say.

I wouldn't feel out of the norm. Every company/team has their engrained ways that might need fixing. It's not always easy, but nothing worth doing ever is.

I would suggest

1. No next sprint planning meeting till team does the retro for previous sprint
2. Ideally the retro should happen after the sprint review but it can be adjusted for a distributed team setup
3. Every team member including SM and PO should be available, can use video conf or webex for remote participants
4. Can have some snacks for the team members
5. There should not be any major coding/testing activity left on the last day of sprint
6. Rather than focusing on all three items - What worked, What didn't work and What can be done better. Team can concentrate on just one of them per sprint .e.g What worked in this sprint which team should continue idoing n future sprints.
7. For each action item came out of retro meeting, get an owner who will keep a track of it in future sprints
8. This is a good book on retrospective - http://marketplace.pmi.org/Pages/ProductDetail.aspx?GMProduct=001014061…

Why not create a backlog of retrospective issues that were raised, order them as a team to which is the highest value item and continually burn down the list of items?

Don't try fix everything at once, fix your top most pain/block issue and move down the list in order.