Primary source: Derby, E. and Larsen, D. Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf, 2006.
I've been working hard lately on getting teams to experience a good retrospective, after hearing many teams say they tried it and quickly fell off the practice. I've been challenged by the fact that every one of the retrospectives I've helped facilitate recently has been distributed. We've used phone bridges with WebEx; we've tried to incorporate the use of some of its attendant tools (whiteboarding, chat, and polling) to help make up for the extreme inhibition of interpersonal communication a phone environment creates.
Letting the team understand the steps you will take them through is one way to keep your retrospective meetings effective. Sticking to the outline can prevent your team from getting derailed with solutions while you're still in the data gathering or insight generation steps.
A key distinction I've found between effective use of retrospectives relates to what the team decides to commit to. Vague promises that aren't tracked or verified upon completion eventually lead to the team's choice to not bother with retrospectives. Instead, a commitment needs to be treated similar to a story. A perhaps better analogy is to an experiment, as there is a hypothesis: "This change will lead to some form of improvement." In any case, it should be tracked and tested. Generally, the more specific the better: "We will do a quick status and mention of issues in the standups, and then allow people to drop off the call who don't need to be involved in follow-up discussions. We will work on completing stories as a collaborative team instead of drawing stories out across the iteration; this should help keep standup calls interesting for all parties. We will monitor the initial time spent on the call and keep this average to below 10 minutes per day."
There are many areas not explored in the Agile Retrospectives book that might be a good addition for a second edition. I've found the activities to be helpful, but I would love to see a larger number and variety. I think it could touch on some ideas for distributed retrospectives. And finally, I think it needs to incorporate discussions of safety exercises.
Thanks Jeff,
ReplyDeleteI'll keep your suggestions in mind. :)
Hi Diana--Thanks for the comment. I think it's a great book, and is in fact the one I have most frequently pulled from my shelf over the past year or so.
ReplyDeleteIs the retro to "post mortem" to be effective in reality? On paper it seems like a wonderful idea but we do the retro's, talk about all the things that went well, the things we need to change and try to keep them top of mind in the next iteration but once in the trenches its back to focusing on the 100 other things in a day that we need to do to get stories moving across the board. So retro's need to change to something interactive in the daily grind.
ReplyDeleteGood point. It frequently happens that people agree on something vague and then don't do it ("pair more", "write better tests"). We've had to push for actual tasks, and get permission that one iteration can have so many days of time devoted to tasks identified in the retro. That has helped. We've actually done things that way.
ReplyDeleteI think that most managers would be happy to sacrifice a few days of developer time per iteration to increase the effectiveness and/or productivity of the team.