Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!


I was pinged last night with a question about how to do retrospectives and what to be examining in the retrospective.  I think retrospectives are a vital piece of any disciplined Agile approach.  Working adaptively is really only effective with plenty of feedback and reflection.  Actually, I’ll go farther than that and say that one of the biggest elements of success on any software project is the effectiveness and quantity of the feedback loops. 

I also like using retrospectives and iteration planning meetings to bookend iterations.  It’s just too easy to blow off iterations if there isn’t at least a little ceremony around iteration boundaries.

In shotgun fashion, here are my thoughts around doing effective retrospectives:

  • Avoid the embarrassment meeting – I was a technical lead on a project that was effectively nothing but interpersonal tension and conflict.  The project manager started every single iteration retrospective with a hugely painful comparison of estimated hours against actual hours for each and every story.  It’s the kind of abuse I expect from traditional software shops when status meetings often involve a project manager collecting updates line by line on a Microsoft Project plan or Jira printout.  Stop it.  This type of meeting just sucks all the oxygen out of a team.  I will personally pile drive any project manager that does this.
  • Do reflect on your estimates – Avoid the embarrassment meeting yes, but it’s very valuable to examine your estimates.  Early estimates generally aren’t very good because you’re making those estimates without the complete picture.  Use the early estimates to adjust your later estimates for the following iterations.  Improved estimates affords the project manager much more control over the delivery schedule.  In the nasty project I described in the previous bullet, we used a release retrospective to completely change the way we estimated and ran retrospectives.  The change in process, plus the empirical data from previous iterations, made the project much more tolerable.
  • What do I retrospect on? – Everything.  Think about anything that is slowing the project down.  If you’re doing short iterations, it should be relatively easy to remember what was getting in your way in the past couple days.  In a typical retrospective on my previous project we would discuss particulars of the design, how we were testing, and the interaction with the analysts.  One of the best things you can do in a retrospective is simply ask “If you could change one thing, no matter what it is, what would that one thing be?”  From our retrospectives we changed the way we tested the application (dumped FitNesse :( ), improved our interaction with the ultimate customer, and worked out the kinks in our design.
  • The Spaghetti Western Format – My favorite way to do this is just to have one person go up to a clean whiteboard and write headers for “Good, Bad, and Ugly.”  After that, open the room up for suggestions for all three headers.  If you’re having trouble with participation, go around the room and make everybody add something to the whiteboard.  At this point you’re brainstorming ideas.  Write the list first, then discuss.
  • Celebrate the good – Do not let retrospectives disintegrate into a wave of negativity.  Yes, there’s always something that could be going better, but remember to talk about what *is* going right.  This is also an opportunity for developers to share knowledge and experience about the things that are working.  This new tool we’re using rocks.  The developers helped me with some test automation thing.  Our estimates were better.
  • Identify improvements – Don’t just reflect, act.  Come up with specific, concrete actions to make improvements.  If you make any changes in process or design or tool selection as a result of a retrospective, come back and visit that change in the next retrospective.
  • Make it safe – The retrospective has to be a “safe place” where anyone can discuss the issues facing the team.  I think the most accurate way to measure the health of an Agile team is to watch their retrospectives and planning meetings.  If these meetings are cordial and the team is willing and able to dissect their own performance without fear, you’ve got yourself a healthy Agile team.
  • As much transparency as you can stand – Transparency is always good, but see the previous bullet point first.
  • Everybody participates – I left this for last, but this is crucial.  Sometimes you have the process and design that you deserve.  Don’t be a spectator on your own project.  Own the process.  Own the technical direction.  The retrospective is everybody’s job.  The junior most members of the team may not have as much say in the direction of the project, but they’re still a set of eyes and ears on the project that has to feel the pain from any bad decision.  In an earlier bullet point I mentioned a case where my team changed the way we captured estimates and did iteration planning that I credit with partially saving a failing project.  That recommendation came from another developer, not from the project manager.   Do not allow the project manager or lead to dominate these meetings because that will choke off the conversation (I’ll admit it, I don’t have a lot of good will towards project management in general.  I think PM positions are largely filled by the Dilbert Principle). 


Recommended Reading from Smart People Who Have Thought More about Retrospectives Than I

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Carlton

    I was responding to this: “I do agree with your comments about “bashing”, but to some extent developers do need to have feedback on the estimations vs. actuals so that they can get better at estimation. At a minimum developers should then learn to under promise and over deliver for any particular sprint or iteration (this of course is not ideal but better than going over budget every sprint).”

    I was also sharing my feeling that people ought to be praised in public and corrected in private. I also was sharing my own feelings that if I was “bashed”, then I would respond defensively, like most anyone else would. I certainly hope I would identify my emotions first, reflect on them before responding, but I’m only human.

  • http://www.jeffreypalermo.com Jeffrey Palermo

    It’s interesting to me that you have a member of your team own some estimates. I’ve been on several agile teams and coach it as a consultant now, and the team owns the estimates. The iteration is filled with stories. The team owns the stories and estimated them together in the planning meeting. I couldn’t point to one person and say “you estimated wrong”. It would be “we estimated wrong”. Or “we overlooked a dependency”. In the planning meeting everyone estimates and we talk about it until our estimates converge.

    We also don’t assign stories to individual developers. A key tenet is that the team is filled with motivated individuals. The stories are on the wall. Grab and go (and talk the whole time).

  • Carlton

    Hmmm….I’ve been on a number of agile teams and I understand the process. I am talking about a general principle “Praise in public, correct in private.”

    For instance, if Mary’s estimates are always way off and consistently are blowing the iteration, then someone ought to take Mary aside and ask “what’s going on?” Mary probably knows she’s the problem and may or may not know how to change her behavior. I hardly see it productive for the team to put HER performance under the microscope in the crucible of a retrospective. I cannot speak for Mary, but if it were me, I would get REALLY defensive. I would very likely remind the team estimates are not commitments.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    In an Agile project you estimate collectively. You should be able to talk over the past estimates to make the future estimates better, and that does need to happen together.

    The tone and the way that you do that reflection on estimates matters quite a bit. You should be able to do this without a feeling of persecution.

  • Carlton

    Shouldn’t individual coaching of people on their estimates occur in private, not in public? I think that type of feedback should be given without their peer group being present.

  • http://stevenharman.net Steven Harman

    >> I will personally pile drive any project manager that does this.

    In that case… I’ll point you in the direction of a few ex-managers. :)

  • http://www.codesqueeze.com Max Pool

    I do agree with your comments about “bashing”, but to some extent developers do need to have feedback on the estimations vs. actuals so that they can get better at estimation. At a minimum developers should then learn to under promise and over deliver for any particular sprint or iteration (this of course is not ideal but better than going over budget every sprint).

    Another book that deals more with games and ideas on how to run a retrospective is Agile Retrospectives by Derby/Larsen