Retrospective:  looking back on or dealing with past events or situations.  

In projects, it is a meeting to discuss what was successful, what could be improved, and how to incorporate successes and improvements into future initiatives.  In Scrum, the purpose of a retrospective is to inspect and adapt with regards to people, relationships, process, and tools seeking to implement improvements to the way the Scrum Team does its work.

If you believe that you are the very top of your industry and your competition cannot ever touch you, this article will not help you.  Hope you are right….To everyone else, keep reading.

So you acknowledge that maybe you might need to improve and grow… but here are 7 signs that you’re not doing sprint retrospectives right. Retrospectives might still be a waste of time if:

  1. You think you are smarter than your employees or peers and thus believe they have nothing to offer you.
  2. You just like to be in control.  After all you worked hard to get to the position you are and they should just respect what you tell them to do.
  3. You think that people are the problem and you really just get tired of their complaints and whining.
  4. You think that if somebody has an issue with the way we do things around here, they are just a trouble-maker and should get with the program, or just move on.
  5. You think that if somebody thinks they can do something better, than they should just go do it themselves to prove their worth and stop asking for help all the time like they cannot cut it on their own.
  6. You promote continuous improvement, as long as nobody makes your area look bad, or expects you to have to do anything new or different.  After all we really just want to look good and promote what we are doing.
  7. You really are just too busy.

You are right then!  Retrospectives and continuous improvement initiatives are in fact a waste of time for your organization or team.  Your employees and peers will not contribute anything of substance anyway out of fear.  Sadly, I suspect there are elements of this thinking more often than we would like to admit.  But there is hope, and these attitudes can change.

To succeed, continuous improvement requires a supportive culture – one of safety and respect.  Establishing the culture can be very hard.  The vision and expectations for the culture must be explicitly clear and communicated effectively to all.  Those who are hindering the adoption of the culture must be refocused immediately.  More of this later….

In a culture of safety, ideas and opinions are respected and not criticized. Dissenting opinions are welcome and people are not punished and devalued for them.   It is understood that healthy debate of conflicting views often results in better solutions and sharing of new knowledge.  People are not viewed as the problem, and problems are viewed as opportunities.

It takes time to establish a healthy continuous improvement mentality.  I suspect that is why Scrum came to build it into the process framework – to ensure that new teams were focused on getting this culture established and healthy.  But this is very hard to do well and often gets abandoned too early.

Over time, high performing empowered teams and organizations just build it into how they work and it is not so much a “scheduled reoccurring event”, as just how we do things here.  It becomes the culture.  It occurs spontaneously all the time as part of the norm without requiring a focused activity to ensure that it gets done.

So, if you think a scheduled meeting called a retrospective is a waste of time or not needed because you have achieved a true culture of spontaneous improvement as a way of working, then I applaud you!!!  To everyone else, I suspect you still have some work to do.

Perhaps the first retrospective your business or team should conduct is to determine why they think they do not need an improvement program.

Leadership should immediately resolve impediments that are holding them back from realizing the benefits of the ideas that those closest to the work can offer.

Join the Discussion

    • Mark Manta

      I like the article a lot. I would only add that at the start of introducing SCRUM to an organization and the idea of Retrospective Meetings. That the culture of open communication and admitting fault are part of that new culture and to establish it at the very beginning before the first SCRUM project. So when arriving at the retrospective the “Fear Factor” had been removed.

      • Jo Hollen

        Thanks Mark! I agree completely that the culture must be addressed in the beginning to obtain the full potential that Agile offers. “Being Agile” is all about the culture. An Agile transformation plan must include an assessment of the current state and steps to establish new norms that are consistent with Agile values and principles.

    • Songtai Sangtaweep

      This is an excellent article. I totally agree with you about seven sign of ineffective retrospective. In my perspective, I truly believe that that worst sign that lead to have ineffective retrospective is that people do not give a recommendation or complaints when the others are having problems. Being silent will kill the teamwork. People should always try to talk and participate. Another bad sign in retrospective is that you do not trust each other. People might think that the others do not perform their best for the responsible task. For being agile, you should believe that the other people do their best for the assign task. I believe that being talkative and trust people will improve the communication efficiency. As a result, we will have an effective retrospective.

    • Jo Hollen

      Thanks Songtai for your feedback. I agree that most people truly try to do their best. But still often there are problems. Great teams and successful organizations learn to be open and communicate with respect. This takes a great deal of trust that first has to be earned. Teams must invest the time and effort to build trust.

    • Scott Weeklund

      Very true Jo. I would add that, if there is a leader on the project, be it the PO or the Scrum Master or some other lead role, and they that have 1 or all of those characteristics, the project has more issues than just poor retrospectives.

      • Jo Hollen

        Scott – thanks for your feedback. I agree. They would have issues indeed and probably no real understanding why either.

    72 + = 75