Comment by vannevar | Hacker News Reader

Comment by vannevar | Hacker News Reader

While the author implicates Agile, it seems like their real problem is with software development at scale, or really, any production process at scale. Once you've come up with a design (the fun part), you are faced with the prospect of implementation (the not-so-fun part). If that implementation includes so much work that you need a bunch of people to do it, you are left with the inevitable task of decomposing and distributing the work (into widgets or services or subroutines, or however you functionally break down the system). Whether you do Agile or not, that work is going to have to involve requirements and acceptance criteria, and tracking and reporting and scheduling.

But all of that doesn't have to be dehumanizing. Nothing in Agile says you have to call people "resources." Or that you can't say things like “Oh, Samantha would be a great fit for this project.” And if your Agile team's primary motivation is to move tickets from one column to another, you should fire your Agile management team, because that is literally antithetical to the Agile process, which focuses on delivered value.

Yeah it's not Agile's fault but it's a tool that makes it easy for bad mangers to squeeze every last bit of productivity out of people in dehumanizing ways through the power of the velocity curve.

At least in the past bad managers had no access to such tools so their power to harm was limited a bit.

Never heard of a death march? A bit dehumanizing eh?

I didn't. Care to explain what it is?

" Agile, it seems like their real problem is with software development at scale, or really, any production process at scale."

I think it's more unique to software development. You don't see this kind of approach in large scale construction project with layers of contractors and subcontractors covering dozens of disciplines. You don't see this in car industry where they can do design, engineering, testing, factory tooling in 3 years.

I really believe the only reason why we do it in software is because we can.

And we can get away with it.

I also think the proliferation of outsourcing and offshoring was a strong catalyst for various reasons, though I'm sure that's a sensitive topic.

When industries that cannot get away with doing so tries, plane falls out of sky.

I think Agile can be great, but having been in the industry for 20 years and being put to practice, I see more reluctant Agile than true Agile. Meaning, people don't like it, but it has perception of working, so they go along with it, because there doesn't appear to be impetus to move away from it.

First, construction and automotve have been around for over a century, and they definitely suffered through growing pains in their discipline - there are boondoggles galore in the engineering and infrastructure space, and for the same reasons as bad software - a lack of clear vision and product fit.

And of course secondly they are subject to a much more rigid set of constraints to define success - primarily the hard laws of physics, chemistry, and human physiology.

But the key difference hands down is the raison d'etre - the demand for cars, buildings, bridges, roads, airplanes is self-evident.

Almost no software rises to such an elemental need in our world. The ones that do (Linux, avionics firmware, etc) don't run on Agile.

The rest: who really (really) cares?

You don't see this kind of approach in large scale construction project with layers of contractors and subcontractors covering dozens of disciplines. You don't see this in car industry where they can do design, engineering, testing, factory tooling in 3 years.

I think you do see it in construction and automotive assembly: the project is decomposed into small pieces and tackled by large numbers of specialists, who are individually regarded as interchangeable. Or when you say "this kind of approach" are you thinking of something else?

Reply on news.ycombinator.com