Jul

9

The Diminishing Value of Retrospectives

Posted by Keith McMillan

July 9, 2012 | Leave a Comment

One of the fundamental tools in a Scrum project is the retrospective, the regular meeting at which the team looks at what they’ve been doing, and thinks about ways to improve. To my way of thinking, it’s sort of like the project post mortems we used to have, only better. But not all retrospectives are created equal.Start off with the idea that all projects are different. In software development, we seldom do the same thing twice. We don’t build the same software system, on the same platform, using the same language. That’s not to say that some of us don’t build systems that are very similar time after time, or that there aren’t similarities between projects of even very different types, just that none of them are identical.

If you start off with the notion that each project has a unique goal, a unique set of obstacles and resources (tools, people, time, money, etc), it shouldn’t be any surprise that a process optimized for a given project isn’t optimized for all projects.  Having the traditional project post-mortem, usually held at the end of the (hopefully successful) project is not very useful with this understanding. It tells us how we should have changed what we just finished doing. What’s the likelihood that the next project will need to do the things we should have done? That’s not at all clear.

What’s far clearer is the idea that we should have done something different on this project. So a retrospective is a very nice way to accomplish this goal: get together regularly, look at what we’re doing (and not doing) and make improvements. This brings me to my point today: when you have a project that’s winding down, the goal is in sight, is a retrospective useful?

I don’t think I could defend a position that says “no, absolutely not” but I will defend one that says the value of a retrospective to a project, and to the team working that project, can have a fairly steep fall-off near the end of a project. If the team is being broken up to work on other projects, they can take their knowledge with them, but in terms of making substantive changes to this project, most of the water is already under the bridge.

If the team feels they can still make real meaningful changes in the way they work in the last sprints of a Scrum project, I fully support them. But if they feel the goal is in sight, everyone is working towards that goal, and real substantive change won’t happen at this point, I think that’s realistic as well.


Comments

RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll