Agile in Practice: What Is Actually Going On Out There?
Scott Ambler talks about actual data resulting from surveys made during 2006-2008, showing how Agile is perceived and implemented within organizations.
News
How Long Should Retrospectives Last?
Posted by Amr Elssamadisy on Nov 13, 2007 04:08 PM
The original definition of a retrospective, as presented by Norm Kerth, was a 3 day, offsite meeting. Since then, the Agile community has co-opted the practice and made it part of every iteration. In, Agile Retrospectives, we are given 5 phases to be covered, but no specific guidance on time. In her recent article, Refactoring Your Development Process with Retrospectives, Rachel Davies suggests that we have 30 minutes per week under review. In many teams I have seen first hand, they tend to minimize the time for retrospectives - even as little as 15 minutes. How long should a retrospective be to be effective?
Esther Derby and Diana Larson, in Agile Retrospectives, tell us that each retrospective should cover the following phases:
- Set the stage
- Gather data
- Generate insights
- Decide what to do
- Close retrospective
For each of these phases, they give several different practices that can be used to effectively perform the phase(such as Mad/Sad/Glad for gathering data). But perform all the phases, it takes over an hour (probably no less than two). If you are running one or two week iterations, are you willing to put in two hours for a retrospective at the end of every iteration?
In Rachel Davies' paper, she suggests 30 minutes for each week:
A rough guide to timings is a team need 30 minutes retrospective time per week under review so using this formula allow 2 hours for a monthly retrospective and a whole day for a retrospective of a several months work.
Does this imply that we should be having retrospectives no sooner than once a month? Or does that mean we should have 30 minute and hour long retrospectives for one week and two week iterations respectively? And how do we fit in all the phases in the shorter retrospectives?
Finally, many teams on the ground practice 15-30 minute retrospectives that don't have all the phases. They get little to no value out of this practice and end up dropping it or doing it out of habit.
So, with the varied advice and practice out there - what is the most effective? What are your experiences? Do you perform retrospectives regularly? If so, how long are they? Are they effective or wasteful?
RelatedVendorContent
Gamma's Jazz platform's first implementation: Rational Team Concert (Trial Download)
The End of Middleware: Freedom from IT Stacks as we know it
Scaling Agile on large teams & Being Agile every day Tracks @ QCon SF Nov 19-21
The Agile Business Analyst: Skills and Techniques needed for Agile
Related Sponsor
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
30 mins per week sounds good
by
Eric Lefevre
Posted
Nov 14, 2007 5:47 AM
Re: 30 mins per week sounds good
by
Rachel Davies
Posted
Nov 14, 2007 1:05 PM
Re: 30 mins per week sounds good
by
Amr Elssamadisy
Posted
Nov 14, 2007 2:48 PM
Re: 30 mins per week sounds good
by
Rachel Davies
Posted
Nov 15, 2007 11:00 AM
Re: 30 mins per week sounds good
by
Diana Larsen
Posted
Nov 20, 2007 1:21 PM
Re: 30 mins per week sounds good
by
Patrick Kua
Posted
Nov 20, 2007 10:49 PM
-
I think Rachel has a nice, simple way of dimensioning retrospectives. However, I don't belive she implies that Retrospectives should be done no sooner that monthly. For me, it's obvious that you need to have them at strategic moments, i.e. at the end of an iteration. My guess is that she used the "one month" value based on the recommendation from Scrum, but that she avoided mentioning the word 'iteration' in order not to dilute the point of her paper. If I had one-week iterations, I would still have 30-min long retrospectives. But of course, I'd rather have iterations that last at least 2 weeks.
-
Eric's interpreted my intention accurately. Yes, I'd recommend a retrospective at the end of every iteration/sprint and the duration of that retrospective should be proportional to the sprint length. So short sprints have short retrospectives. I also recommend every few months having a longer session that looks back across several sprints/iterations.
-
Yes, I'd recommend a retrospective at the end of every iteration/sprint and the duration of that retrospective should be proportional to the sprint length.
Thanks Rachel. So, have you found 30 minute or 1 hour retrospectives useful? The majority of short retrospectives I've seen end up floundering. (but it may be just my luck) -
Yes, I think it's valuable to discuss experience close to when it has happened. However, for short retros I'd recommend following an proper retrospective structure (based on ORID with a timeline) rather jumping straight to "start doing" and "stop doing" actions.
-
It also depends on how long a team has been working together. Early in a project, I recommend spending more time on the retrospective--up to 90 minutes for a week or two-week iteration. Early retrospectives offer both a) an opportunity to consider and continuously improve product, process, and practices, and b) time for reflection on the current state of the team's collaboration skills (how they work together to create value). Investing longer time up front to create solid team collaboration pays off in later iterations by building the capacity to get the most out of 30 minutes.
-
The majority of short retrospectives I've seen end up floundering. (but it may be just my luck)
Why do you think the retrospectives flounder? Does it take a long time to gather data? Or is it that you are not discovering anything useful? I find if you do them often enough you may not end up with that much valuable output. On some teams I made these less frequent, as in every two weeks instead of one and increased the frequency if I got a sense there were more issues that need resolving.
6 comments
Reply