No retrospectives in software company - Is this a bad sign?

Question

I know of one software company that does not have sprint retrospectives or retros of any kind. They had it in the past but cancelled them. Is there ever a good reason for not having retrospectives or cancelling them forever? Is this necessarily a bad sign if your company does it or if a potential employer does it?

Here is my speculation for why a company might not have retrospectives, despite being aware of this prevalent practice:

Benign reasons - Retros are conducted too often, or things generally go well which means there is nothing to talk about in most retros. So, it unnecessarily blocks time on people's calendar.

Bad reasons - The company is in serious trouble, maybe beyond repair and has lot of attrition. So, they don't want newcomers to quickly realize these problems and then quit too soon. After all, they need live bodies to keep things working. Maybe the culture is so bad, that people use retros as a means to attack and humiliate others instead of being constructive.

Answer 1

TL;DR: Maybe you're having a XY problem. Retros are a tool for a means, not a means in itself.

As yourself: Why are you asking around if the team has retros? Chances are, this question is a shortcut for a longer, more complex question similar to "how is the team materialising actual, concrete inspection and adaptation on a frequent basis? How are these benefits measured and converted into value?".

Having retros per se does not mean the team is inspecting their behaviours, culture and working model and adapting themselves to be better and ready for bigger challenges.

With that in mind, you might want to dig deeper into the team dynamics to answer your real question.

Is it a bad sign if there's no retros in a software company? Maybe yes, maybe not. Maybe they had 50 weeks of "what we did well, what we failed, what we'll keep doing" and they just dropped it on week 51. Or maybe 50 weeks of the "boat retrospective" (and they sink the lovely boat in the week 51). Maybe they have other means. Maybe the team works so well that if they spot a problem, they get together and swarm about it on spot. After all, correlation does not imply causation.

Is it bad if there's no inspection on where wastes are and how the team is sharpening up their skills, fixing their own problems and being mindful about their own limitations and working towards overcome them? Definitely, yes.

Answer 2

Fundamentally, improvement is a part of any serious organizational process. Reflection and improvement is the only practice mandated in the Manifesto for Agile Software Development. It's also embodied in ISO 9001 (and all of its derivatives), CMMI, The Toyota Way, and more.

That said, these events may have many different names and take different forms. They may be called retrospectives, post-mortems, kaizen events, or something else entirely. They may happen at different cadences or at different milestones or events during a project or effort.

Regardless of what they are called or what they look like, the key question is how a team or organization reflects on their way of interacting, their processes, and their tools to find and implement improvements. If that isn't done in some way, that would be worrying.

Answer 3

First, there are many ways to reflect and adapt apart from a Scrum "retrospective". However, those should be readily evident. If I take your post at face value, I have to assume there is no time set aside for reflection and improvement. This would be a big red flag for me.

There are whole books written about this, but the take-away from all of them is this: we tend toward entropy. Processes get clunky, ways of working age out. This is normal and unavoidable. We can counter it with constant vigilance toward improvement. If we are not creating time to do this, we just slide into disorder. I have never worked with or heard of an organization that does not experience this. Therefor, it would be a red flag for me if the company does not create time for this.

As for your benign reasons, this alerts me to a fixed mindset. You can look up info on Growth vs Fixed mindsets, but in this context, it's enough to say that in a fixed mindset, people make value judgements around their current skills. Even saying "we're good" means they are applying judgement against their performance in a fixed manner. This inhibits improvement just as much as saying "we're bad" does.

So, the only reason I can see that wouldn't be a red flag to me would be because they honestly don't know that's a practice people do - and that's not very common.

Answer 4

It's interesting that you say "the company" does does not have retros. Could that mean it's a matter of policy not to have them, or does it just mean all of the teams at this company choose not to do retros? That seems like an important distinction. Retros are for the benefit of the team and each team should choose when to have them. Teams do sometimes decide to skip retros but regularly skipping them is a bad idea because it may discourage people from speaking up.

Answer 5

I echo the other answers, and will just add a couple of thoughts. The primary question is, are the teams meeting their performance objectives? If not, by definition they need to improve, and some form of reflect-and-adapt meeting like Thomas Owens mentioned needs to happen on a regular basis, at least monthly. (If the company does not have performance standards or objectives, that's another problem entirely!)

I'll also note that I've never coached a team, pre- or post-Agile Manifesto, that objected to getting more free time. That is, they have always liked my advice to block the time; meet to see if there's anything to talk about (things come up face-to-face that won't come up by e-mail); and if not, adjourn. Now everyone has a free half-hour or more with no meetings! :-)