Can you explain the objectives of an Agile retrospective? Is it about evaluating the code developed in the last...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
iteration? Is it about evaluating the development team's processes? Is it about updating the project status?
I consider retrospectives to be the most important “Agile” practice. Agile development is all about continually improving. Methodologies and tools don’t make projects successful. Having the right people, respecting them, and letting them do their best work is the way to get a high-quality software product.
Agile teams continually “inspect and adapt.” We use retrospectives to look back at the previous iteration, discuss what went well and what didn’t. We may spend some time analyzing why a problem occurred, but we don’t always have to know the root cause of an impediment in order to overcome it. We simply think of small experiments to try in the upcoming iteration to address any problem areas.
Code should be evaluated via a code review, whether that is using pair programming or a more formal group code review process. Project status is tracked in various ways depending on your situation and flavor of Agile: a Scrum task or story board, a Kanban board, an online tracking system. So, retrospectives aren’t about reviewing code or project status.
Retrospectives may indeed lead to a change in the team’s processes. Some teams use a “stop/start/continue” approach to come up with action items: What should we stop doing? What should we start doing? What is working well, so we should continue doing it? Write those down on a big flip chart or whiteboard, and revisit them after the next iteration to check the results. My team likes to use happy/sad/neutral faces next to our action items to show whether we tried each proposed experiment.
My team often comes up with enough “stop/start/continue” items to fill a big flip chart page, or more. You can’t fix everything at once, though. Have the team vote on which one or two impediments or issues they want to address, and focus on those for the next iteration. Identify your biggest problem, and work on it. Once you’ve solved it, move on to the next biggest problem.
It’s crucial that each team member feels safe enough to speak up honestly during a retrospective. It’s not a time for blaming or pointing fingers. Remember Norm Kerth’s Prime Directive as you discuss your team’s successes and failures. Remember that failures and mistakes are good – that’s how we learn. Some teams start their retrospective with a short game such as Jenga to help everyone relax and remember that failing, and improving, are a team effort. Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen is a great resource.
Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting.continue reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates.continue reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.