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?
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.<p>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.<p>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.
I've never worked anywhere where the end of sprint retrospective was in any way useful. Same with the huddle.<p>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.<p>This combined with childish themes, and nonsense like describe how this sprint went for you in terms of World Cup teams. WTAF.
> 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?<p>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.
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.<p>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.
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).<p>"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.<p>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.<p>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?<p>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".<p>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.
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" :)
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.
> Ask HN: Why aren’t ‘team retrospectives’ a thing in ‘traditional’ industries?<p>They are.<p>> However, most ‘traditional’ industries don’t seem to be adopting this seemingly superior way or working.<p>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.)
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.
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.
<i>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><p>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.<p>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.<p>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?<p>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:<p>- A retro inevitably involves frank discussion of people's work, and whether it was acceptable or not. <i>Most people cannot separate criticism of their work from criticism of themselves</i>.<p>- Therefore having your work be openly criticised makes you likely to dislike the person criticising you.<p>- So people may simply turn around and blame their colleagues or management for their own failings instead.<p>- 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.<p>In engineering professions what we do <i>must</i> work and it <i>must</i> 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.