
Ask HN: Why aren’t ‘team retrospectives’ a thing in ‘traditional’ industries? - firstbabylonian
Like most people on here, I work in the software industry, and my team follows a version of ‘agile’ methodology that (disregarding all of the software-specific principles and aspects of it) is a result of continuous iteration and input from the team itself. Over the course of months and years, we’ve developed a system that more or less works for everyone on the team, accomodating not only the nature of the work we do, but certain personal needs and cultural quirks of every individual. While never perfect, the system is continuously revised, as we are encouraged to regularly ‘look back’, voice concerns, discuss issues, and come up with action items to solve problems that arise within and outside the team that affect our productivity and happiness.<p>I almost take this for granted, feeling like this is ultimately the only way to get any team work done over a long period of time, as this gives room for everyone to speak up and bring to light problems that management may not necessarily be aware of (or be willing to solve otherwise).<p>However, most ‘traditional’ industries don’t seem to be adopting this seemingly superior way or working. Why is that? I hear complaints from my working parents who are often dissatisfied with the way their work is organised, having concerns about their roles on their teams, the efficiency of the process, etc. Yet, my obvious suggestion of ‘just bring this up at your next retro’ doesn’t apply here, as there is no such thing in their world.<p>Is there something special about software with the level of introspection workers in this industry are expected to do, which cannot (or shouldn’t) be done elsewhere?
======
thisisit
I assume by 'traditional' industry you mean stuff like manufacturing, finance?
If yes, then you should check out Six Sigma, Kanban etc. Those came from
traditional industry - manufacturing and applied to software engineering.
Scrum and Agile evolved out of these methods.

That said, you might think retrospectives work because of the method behind
it. But in my opinion it works because of the intent and culture of the team.

At a past employer we started Agile with bang. Our manager used a clock to
ensure everyone spoke for 2 mins max. "Brevity is the Soul of Wit" he said.
But once he left Agile meetings were in shambles. People rambled on about who
they sent mail to, what meetings they had etc. because it showed "importance"
of their work.

~~~
bb88
> People rambled on about who they sent mail to, what meetings they had etc.
> because it showed "importance" of their work.

Yeah, I ran into that more than once. Scrum turns into a daily performance
evaluations which tends to encourage micromanagement.

And this is something I don't get. Managers complain about getting too many
emails that they have to read through, but yet they're fine with 5 minute
status reports from every member on their 10 person team on a daily basis.

Every company that I worked for that had retrospectives dropped them, as they
were pretty much useless. Because once a team optimized internal processes,
the thing they couldn't optimize was the external managemalaise that impeded
their ability to get things out on time. And that never ever flowed upwards.

------
LandR
I've never worked anywhere where the end of sprint retrospective was in any
way useful. Same with the huddle.

The problems I've found with the retrospectives is they become a meeting just
for people to moan. And it's the same problems every time that people moan
about because the team isn't really empowered to change anything.

This combined with childish themes, and nonsense like describe how this sprint
went for you in terms of World Cup teams. WTAF.

------
lmm
> Is there something special about software with the level of introspection
> workers in this industry are expected to do, which cannot (or shouldn’t) be
> done elsewhere?

I'd say it's just the opposite: the software industry is very immature
compared to other industries. We've only been writing software for 60-odd
years. We don't know what our methodology should be - we haven't even figured
out basic things like the right programming language to use. We expect to
spend a significant amount of time and effort on process refinement because
everything we're doing is (comparatively) new. Whereas many in other
industries believe (rightly or wrongly) that they've got their processes
figured out, and don't need to reassess them every week or two.

------
Yizahi
It's not a thing in most of the software industry yet. And wherever people do
team retrospectives there is a high chance that it is a formal procedure - the
only concerns that are voiced aloud are the ones that are known and "approved"
by management or are expected to be acknowledged. Any critical concerns that
can backfire at a person who raises them are never mentioned, just in case.

I'm not saying that all IT companies are like that, far from it, but really
the issue is very human one - it is very likely that at least some critical
issues are caused by mistakes of the management and unless management can
accept blame for own mistakes retrospectives won't really work.

------
r0ckarong
Isn't this a question of how "hierarchy" is handled? I work in software too
and here everybody is basically equal when it comes to pitching ideas and
input. The decisions are bundled around the team leads and managers but they
welcome input and suggestions to improve for everybody. The managers jobs is
just to manage resources and not to be a king or a general in an army (and
thus being full of themselves).

"Traditional industry" is based heavily in "I'm paid more, therefore I'm
better than you" and those people just don't want to hear what was wrong about
their decisions. These industries are driven by the magnates, the admirals and
the kings of the world for centuries so that's how their structures evolved to
mimic this.

Software is new, it has a different set of goals and different means to
achieve it. Make it better for everyone and be more productive VS. make
yourself look good and shit on everybody else that isn't directly useful for
your benefit.

You will find outliers in each direction in each industry. The fundamental
difference is: Do I accept others as my peers because my role is just
"manager" (to perform the management function) OR Do I want to cover my ass as
much as possible and gain an advantage over everybody under my command?

I worked in Kitchens, Trash removal, Callcenters, Hotels, Banking ... it all
boils down to "Am I treating people as other human beings or as resources I
can shuffle around to my advantage".

It is the latter that your parents are most likely complaining about and
something that the lavish financial freedoms in the software world -paired
with the freedom to do away with traditional hierarchy- have afforded people
to deal with differently. You will still find assholes in software and good
people in "traditional" industry.

------
johnorourke
Have you done any research before posting? Read up on LEAN manufacturing,
Kanban, and how it evolved into the methods you use today that you think are
"new" :)

~~~
firstbabylonian
Oh, I'm perfectly aware that LEAN and Kanban originate in traditional
manufacturing. But I'm not seeing those methods being anywhere near as
widespread in fields other than software nowadays, at least not in my country
(New Zealand), hence the question.

~~~
leohutson
Do your parents work in the public sector by any chance?

------
robjan
A project management methodology, widely used in Hong Kong, the UK and Europe
called PRINCE2 includes an issue register and lesson log which kind of maps
back to team retrospectives. These logs are supposed to be taken into account
when initiating future projects.

------
dragonwriter
> Ask HN: Why aren’t ‘team retrospectives’ a thing in ‘traditional’
> industries?

They are.

> However, most ‘traditional’ industries don’t seem to be adopting this
> seemingly superior way or working.

The software industry actually got this from a variety of related things in
traditional manufacturing, particularly lean methods; it's not universal in
traditional industry, but then, it's not universal in software, even in places
claiming to be using agile methods (which are often doing top-down cargo cult
variants of Scrum.)

------
karmakaze
The point of 'agile' is that it's self-organizing. If a team isn't empowered
to self-organize, there there's little value in holding retrospectives. Same
goes for those agile teams that don't have the means, motivation, or too much
inertia to change. A better question would be "why don't more industry use
self-organizing teams (aka be agile)?" To a large part, many industries have
already been optimized in some aspect and set in that way.

------
jwhitlark
In the military they are called After Action Reports.

------
hluska
I've been doing software for a long time and, I've got to tell you, your
company is far from typical. In my experience, the typical retrospective is
little more than a circle jerk session for sicophants.

------
repolfx
_Is there something special about software with the level of introspection
workers in this industry are expected to do, which cannot (or shouldn’t) be
done elsewhere?_

It's not so much software, more engineering in general. You do find rigorous
self-review and continuous process improvement in many areas of engineering
(more commonly called quality control), Toyota being the obvious example.

However, you are right that most industries aren't like that. Compared to
engineering most industries are very 'soft' in that correct results don't
really matter or can't even be defined.

Take industries like marketing, retail, law, management consultancy. Look at
the output of your average office worker in these fields. Most likely their
output is in the form of Word documents, PowerPoints, maybe some Excel. Is the
last ad campaign your firm ran "correct"? Did the management consultant who
breezed around your corridors earlier give advice "efficiently"? Did the
lawyer who botched your paperwork ever face any consequences for that or did
they just go, oops, and do it again?

The vast majority of workers work in environments in which the connection
between input and output isn't very clear, and in which being wrong is less
important than having the right relationships with people. In such an
environment a retrospective would not only be pointless but actively harmful:

\- A retro inevitably involves frank discussion of people's work, and whether
it was acceptable or not. _Most people cannot separate criticism of their work
from criticism of themselves_.

\- Therefore having your work be openly criticised makes you likely to dislike
the person criticising you.

\- So people may simply turn around and blame their colleagues or management
for their own failings instead.

\- Therefore the idea of frankly discussing a team's failures in ANY kind of
setting, whether it's called a "retro" or otherwise, is largely anathema in
many lines of work.

In engineering professions what we do _must_ work and it _must_ be correct,
and it's very clear to everyone if we make mistakes. Therefore a culture
develops in which people can separate criticism of work from criticism of
themselves, in which people aren't usually called out specifically for their
errors, and in which systems thinking dominates. The answer to "why did this
project suck" isn't "because so-and-so couldn't make their mind up" which is
the sort of answer you're liable to get from non-engineers. It's "our planned
process didn't correctly refine our requirements from the start". Totally
different mentality.

------
leojg
We do scrum(sort of) and the last retro I had was last year... so, not only in
"traditional" industries

