≡ Menu
Pawel Brodzinski on Software Project Management

Don’t Bother with Retrospectives

Look back

I’ve seen quite a lot retrospective summaries. Usually a great reading. In vast majority of cases they were clear proof that someone put a lot of work in. You know, gathering information, discussing, looking for methods of improvements and finally writing down the whole thing.

Good job. They should get a medal or something.

Except it was complete waste of time for everyone who was engaged.

It is still a very common situation that retros are done as we were taught but only to the point when the summary is written down. Then people call it a day and go home in sense of the job well done. The trick is they don’t learn a thing from the exercise, which means the whole effort was futile from the very beginning.

So don’t bother with retrospectives. Unless you plan to do anything about problem you find, that is.

in: project management

24 comments… add one

  • Marek Kirejczyk December 28, 2010, 1:53 pm

    This is totally not like you. Retrospectives are valuable tool… in many contexts. Your thesis sounds true that for teams that are experienced (or teams with experienced SM). People in such a teams often say that everything is fine during retors. Still they are able to say on stand-up meeting or on corridor “hey guys we need to change… bla bla”.

    However for newbies, this often great opportunity to learn that they can change things, discuss improvements etc.
    So please Pawel, with all your wisdom don’t make too general statements :) Everything depends on the context ;)

    Other titles for your post might be: “don’t bother retrospections if you don’t need them” or “don’t be afraid to skip retrospectives” or “retrospective as a lean waste”.

    I appreciate marketing value of your title however :)

  • Pawel Brodzinski December 28, 2010, 4:37 pm

    I guess I wasn’t clear. Actually I don’t care whether the team is experienced or not, knows how to change things or has no idea about that, cares about improvements or doesn’t give a damn…

    The point is: as long as you don’t plan to do anything with the outcome of retrospective it is futile effort and you better stop before you start.

    Many teams I see fall into the same trap: they believe there’s value in doing retros. Well, there isn’t. There’s value in improving the way they work and retros are just a tool to help with that. If you don’t want to do anything to improve the tool itself is useless.

    And this time it isn’t generalization.

    Glad you liked the title though.

  • Luke Chadwick January 2, 2011, 4:17 pm

    So what you should be saying is ‘Learn to do your retrospectives properly’. Telling people not to do them at all is counter productive.

  • Paul Klipp January 3, 2011, 5:04 am

    Some things that I have done to address the problem of retrospective burn out (when the energy required to hold the retrospective is spent before the critical last steps) are:

    Tighter timeboxes – no one gets anything out of a retrospective that is too long. Too short is a safer risk.

    Identify and post action times visually – find the one or two things that you want to focus on in the next iteration and make them visible during the iteration.

    Review – start retrospectives with a review of the lessons from the last retrospective. Is there any evidence that you learned anything from that one? If not, why are you doing this one?

  • Manoj Vadakkan January 3, 2011, 6:53 am

    Nice Article Pawel!
    The key phrase is that “Unless you plan to do anything about problem you find, that is.” I agree. without that, we are not just wasting the time spend on discussing the “stuff” but a team loses confidence in these processes that obviously wasting time.

    A good retrospective not only should come up with a list of action items but a top 1 or 2 the team has interest and energy to solve during the next sprint.

  • Esther Derby January 3, 2011, 7:12 am

    Do nothing retrospectives are a waste of time, and they breed cynicism.

    Some common causes of failed retrospectives (and what to do about the):

  • Jamie January 3, 2011, 7:21 am

    You make a fair point. Anything conformity driven is just silly. This is like saying, ‘don’t do tdd if you are not willing to do the tests’. Of course, uncovering why teams conform is the real problem. Maybe host a retrospective to find out?

    It’s plan-do-study-act. What happens often, like in your example, is plan-do-celebrate how cool we are/moan/sit quietly/-don’t act.

  • Patrick January 3, 2011, 8:26 am

    Wow, this is a typical case where the comments actually add some value to an original not-so-informative blog entry.

    I would have liked to see the author mention *why* these retrospectives were a waste of time and *how* it was overcome in cases that it *did* work.

    I certainly agree that doing retrospectives just because they are part of the process can be counter productive. Most of the time it has to do with someone facilitating it badly. Apparently the teams were not self-organized enough to do it properly on their own.

    So instead of bashing retrospectives, teach people how to do it properly. A retrospective is valueable even when the outcome is “we did not learn anything”. In that case you became aware and that is always the first step.

  • Diana Larsen January 3, 2011, 10:12 am

    Maybe you could title it, “Don’t bother with ‘do-nothing’ retrospectives.” ;) Just as with any meeting, if a team holds retrospectives that don’t lead to continuous improvement or other beneficial actions, they are a colossal waste of everyone’s time. On the other hand, retrospectives that _do_ lead to action make an equally enormous difference in process, teamwork, practice, & quality outcomes. See Esther Derby’s comment below for some hints that your retrospectives are not adding all the potential value your team could capture.

  • Federico Zuppa January 3, 2011, 11:43 am

    I was just thinking a few days back about the advantages and disadvantages of informality in an Agile context. Informality contributes to being lighter and Agile. At the same time, it also contributes to the things you mention: do a retrospective which is a complete waste of time. Probably, this just happens in less mature teams of course. Team members of a very mature agile team feel accountable for the action items decided in the retrospective (how do you get there though?)

  • Nick Oostvogels January 3, 2011, 12:27 pm

    Congratulations on bringing up a common pitfall in so many agile adoptions. Sure, why keep up the effort when nothing get’s better? I’ve been in this situation myself, and the reason why we didn’t abandon them is because it was the only time the team got a change to slow down and take a look at what they were doing and how they were doing it. A lot of the exercises we did helped to create a shared framework of understanding. After a while, slowly but sure, actions got solved, more and more often. So I believe that retrospectives are a great way to keep learning, and sooner or later, improving.

  • YvesHanoulle January 3, 2011, 2:03 pm

    Hello Powel,

    I love your title! It grabs my attention. It annoys me, makes me think you are wrong. Then I read the article and agree completely with you.
    As you know, I love retrospectives, I think they are the best tool any team has.
    Except when they learn a retrospective is a useless meeting.
    Yes I have been in useless retro’s. Fortunately I also led useless retro’s. I say fortunately because I learned from it.

    Esther’s list is a great way to avoid most of the problems.
    Nr 5 is my “favorite”

    People prefer to focus on the outside world.
    Christopher Avery would say: logical as it is the first step of the responsibility proces. (Blame)


  • Tomek Łasica January 3, 2011, 2:57 pm

    Nice twit ;-)

    I cannot agree with you.
    IMHO it is not an action set which makes retrospective valuable.
    Valuable retrospective needs at least one condition to be met:
    * a set of commitments or actions was taken by the team for the next sprint
    * a subject was given by the team and causes hot discussion between team members
    * the restrospective is focused on a software-development related subject (e.g. clean code) and has been prepared by the team member (not by SM)

    Please remember that in some cases / companies / projects people do not have time to discuss such issues like writing clean code (e.g. due to tight schedule). The retrospective is a time which cannot be reduced by the PM (or at least is should not be).
    In such case even a “do-nothing” retrospective is valuable as it helps to share knowledge about team members.

    So I will come to the definition:
    The retrospective is not a waste of time if the decision about its organization and subject was taken by the team (not forced by SM).
    And of course it is not mandatory to attend :-)

  • Pawel Brodzinski January 3, 2011, 3:02 pm


    It’s a funny thing that people rarely if you come to them with a good advice. However when you are controversial they start listen to you. By the way if someone read the post “don’t do retrospectives” they didn’t get the point. At all.

    And if someone takes the post as an argument to avoid retros, well, they would probably find this argument or another not to do them. After all, you can’t force people to do good retros and bad ones are a waste of time.

  • Pawel Brodzinski January 3, 2011, 3:08 pm


    Good advices. I found it a retrospective booster to make them (almost) as short as possible and as immediate as possible. Ad-hoc, short retro which deals with only a single issue is way better than delayed long and dull meeting at the end of the project/phase/sprint where we try to recall all the problems we spotted over the longer time period.

    I especially like the idea to visualize the tracked thing. It always help to remember about the issue.

  • Pawel Brodzinski January 3, 2011, 3:11 pm


    You nailed it. I used to look at bad retros only like on the waste of time but they’re worse. They also build frustration and aversion to change anything. After all if the organization can’t do anything about the most obvious issues how can one expect it would deal with the less obvious ones.

  • Pawel Brodzinski January 3, 2011, 3:29 pm


    Well, the point was to show the simple, yet frequent, pattern which renders retrospectives useless. I didn’t discuss reasons why this pattern kicks in on purpose – there are a number of them (see a post Esther refers to). However, no matter the reason, outcome is usually the same.

    What more, what I see very often is people doing retrospectives with no will to change anything whatsoever, which is waste of time by definition.

    As a final thought – if I didn’t make it controversial there would be no buzz around the post and most of readers would simply ignore it as yet another boring piece of advice. The funny thing is, using this approach I probable reached more people with the message than I would otherwise.

    A lesson to learn?

  • Pawel Brodzinski January 3, 2011, 3:39 pm


    You don’t have to convince me how valuable good retrospectives are. Not so long ago I described how we do retros in our Kanban team. And yes, they work great.

    But then, title was chosen on purpose. People’s attention isn’t caught by detailed and specific statements. They have to be slapped in the face to acknowledge your existence, let alone your arguments, thus the controversial title. By the way, by the number of comments it looks like I was successful here.

  • Pawel Brodzinski January 3, 2011, 3:42 pm


    I think it is a general rule: the more freedom you have the more you can use it… for the better or for the worse. This is one of contributions why immature teams often fail with agile (and even more with Kanban). Lack of discipline along with few policemen makes flexible process easier to abuse. And then we see people telling this or that doesn’t work. Retrospectives being not so rare example here.

  • Pawel Brodzinski January 3, 2011, 3:46 pm


    Retros are a great tool – I guess you have to convince very few readers here to this. But you can misuse pretty much any tool I can think of. You can use a knife to cut bread or to cut one’s finger (or even worse). It’s not a tool which is good or bad. It’s not a tool which is useful or useless. It’s how we decide to use it.

    If we learn from retrospectives then good for us. If we improve things around basing on them – even better. But if we do virtually nothing, don’t tell me it isn’t a waste of everyone’s time.

  • Pawel Brodzinski January 3, 2011, 3:54 pm


    I’m glad the title worked for you. It was chosen on purpose.

    When it comes to principles I know you value retros highly and I’m totally with you on this one… if they do bring value. I remember a couple of teams where we struggled to suck any value out of retrospectives and they seemed to me as a waste of time (which they were by the way). On the other hand it’s hard to overvalue retros we were doing in my last team. The basic difference was everyone’s attitude. We were set to learn and improve.

    You are right that people tend to look for explanations (excuses?) in the outside world which is out of anyone’s control. It’s just easier to find some kind of “them” who are responsible for all the evil. And you’re right that this attitude usually renders retrospectives useless.

  • Pawel Brodzinski January 3, 2011, 4:01 pm


    You bring the issue to a single specific Scrum-like scenario. I look at retrospectives from a broader perspective. I don’t care what kind of process you do follow. I don’t even care if you can call your team agile or not. Retros can be valuable in many different cases.

    Anyway, you point that retro can be valuable if someone learned something. I think it depends whether the knowledge is applied to change/improve organization/process/whatever or not. If the new knowledge remains completely unused I think it falls into “waste of time” category.

    Note: I never said the outcome from the retro has to change the organization instantly. If it takes more than just a couple of weeks, fine. Just remember that when people don’t see progress they tend to become discouraged and abandon further work on the issue.

  • Simonas January 4, 2011, 12:26 am

    Even if retro has failed, it is not completely worthless if you can show it as a bad example :)

  • Pawel Brodzinski January 4, 2011, 9:29 am

    Bad example is good example. Well, I guess I might have heard it somewhere.

    However, while the learning experience is important, I think in this case we should avoid bad examples if possible. Bad retro is not only about learning (or lack of it) but also about wasting everyone’s time and building frustration. It’s much worse than just a bad manager serving us as counterexample of what we want to become someday.

Leave a Comment