[NitpickLawyer]

> there’s a process by which you can replace these expensive skilled workers with cheap unskilled idiots and still get great results. > Another variation: the magic process that lets you get great results from people who don’t care.

Isn't that pretty much what the US military does? They take in "dumb" teens + docs + processes and get whatever it is they need out of this? It's also cheap (compared w/ industry). And by the end of the exercise the "dumb" teens become skilled in their own niche, some of them highly skilled (see nuclear specialists, ATCs, pilots, navigators, managers, procurement, etc.)

The military processes are at the base of lots of organisational stuff we have in software dev and business as well (agile, scrum, ooda, etc)

[WJW]

Where do you get the idea that this is cheap? Militaries are somewhat famous for being incredible money sinks. They need incredibly specific skills that are not really taught in the civilian world. This means the military needs to train everyone at its own cost. So while the input might be "cheap, unskilled idiots", there is then a significant expense to turn them into expensive skilled non-idiots before they are ready for duty.

As someone who worked inside the military for 14 years, it is also quite a stretch to say they consistently get "great" results tbh.

[gnat]

I feel like you're saying that education (as practiced by the US military) is a somewhat reliable process for taking unskilled people and making them skilled. I agree.

The US Military have admissions criteria. They bounce people out in Basic Training and in every other part of training. Not everyone gets to be an ATC, a pilot, or a nuclear specialist. Air Traffic Control turns out not to be a process you can put an unskilled person into. It requires training and careful integration, and once you have a skilled person with many hours invested in them, perhaps you can let them direct traffic.

Training isn't a magic process that takes unskilled people who don't care and delivers great results every time. The equivalent in our world would be "I'll hire cheap people who don't know how to program, put them through a Bootcamp process, and then I'll have great programmers." That didn't work.

I am trying to say that: every version of programming where there's been The Process You Just Have To Follow (from Jackson Structured Design) has failed significantly and hasn't been a substitute for hiring smart people who care. If someone came to me with a business plan that was "hire mediocre people who don't care, and we'll achieve great results because of My Process", I'd be veeeeery skeptical indeed.

[aleph_minus_one]

> The military processes are at the base of lots of organisational stuff we have in software dev and business as well (agile, scrum [...])

The Agile Manifesto was exactly the counter-manifesto to this, and thus any methodology that calls itself agile (e.g. Scrum) is:

Agile Manifesto

> https://agilemanifesto.org/

Principles behind the Agile Manifesto

> https://agilemanifesto.org/principles.html

[jerf]

"Scrum" isn't really "Agile", though. Maybe someone developed it through a truly Agile process, but then they froze it and held it up as an unchanged ideal and started down the oh-so-appealing road of telling anyone that finds it doesn't work for them that it's because they weren't doing it right.

I find myself having to distinguish between what I call "Real Agile" and Scrum quite a bit, because Scrum is exactly the sort of thing that Real Agile was a reaction against.

I've raided Scrum for ideas in my agile processes, but I would never rigidly do exactly it.

[SAI_Peregrinus]

Royce's original "Waterfall" paper[1] is significantly more iterative & agile than Scrum! It's outdated since at the time (1970) programming was done mostly on paper & then run later on a mainframe or special-purpose computer, but many of the core ideas still hold true for modern programming environments.

Of course many of the organizations that claimed to be implementing Waterfall omitted the iterative steps, then wondered why it didn't work. That also happens with "Agile" processes. Sticking to the waterfall analogy, it's like if you stopped the evaporation & precipitation cycle that refills the upstream aquifer & wondered why the waterfall stopped flowing!

[1] https://www.praxisframework.org/files/royce1970.pdf

[aleph_minus_one]

> "Scrum" isn't really "Agile", though.

Wikipedia:

> https://en.wikipedia.org/wiki/Scrum_(software_development)

"Scrum is an agile team collaboration framework commonly used in software development and other industries."

In other words: people who claim to do Scrum, but in a non-agile way are simply scammers.

[9rx]

Agile is a set of considerations to ponder if you think you want to operate in a manager-less environment. The supplemental 12 Principles[1] goes into a bit more detail, explaining that developers need to take on jobs like communicating with the business people and amongst themselves to supplant what a manager would normally take care of.

Scrum, on the other hand, is a "process" to manage teams. It even assigns what it calls a "Scrum Master" to act as a manager. Literally the opposite of Agile. Scrum does propose that if you follow it, it can help lead you to eventual reach a state of Agile, which seems to be the source of the association, but when have you actually ever seen that happen?

[1] https://agilemanifesto.org/principles.html

[jerf]

I am aware that Scrum essentially defines itself as "agile". However, the Agile Manifesto defines a very, very specific sort thing as "Agile", and is what I'm calling "real agile", and Scrum is not it.

Scrum could be it, if it presented itself as "here's a set of things to consider as tools you could deploy, but hey, do whatever works". But it doesn't. It is every bit as prescriptive as any of the methodologies that real Agile is a revolt against and can and does have all of the pathologies when it is applied in places where it doesn't make sense, or even just excessively rigidly. Scrum as it is practiced in the real world responds to "it's not working" with "do it more accurately, then!", not "oh, well, fix it up as you see fit". That's why so many of us here have such a visceral distaste of it. Many of us have enough experience and run-ins with "Scrum" to know that anyone trying to claim "Oh, but it 'really' wants you to be Agile and change it to work however you need to" is in practice just motte-and-bailey. That's not how it works in the wild.

You need to figure this out sooner or later or you're going to be deeply and repeatedly taken advantage of in life: Just because someone puts a label on something doesn't mean that label is accurate. Scrum isn't Agile and I don't care how many times someone grabs a label printer, prints out the word "Agile", and slaps it on Scrum. It's plainly obviously not an Agile methodology and never was.

Agile isn't a methodology; it's a meta-methodology, which is why it's so hard to productize.

[9rx]

> it's a meta-methodology

It is not even that. It is basically just a roundabout statement of "We believe software developers should be in control of the entire software development process". Or even more succinctly, "No managers". The Twelve Principles highlights the things developers need to consider when there isn't a manager around to do that work for them.

Scrum, while having little to do with Agile in and of itself, suggests that if you follow it, developers can start to learn how to operate on their own. This seems to be why it is commonly associated with Agile.

[dragonwriter]

> Agile isn't a methodology; it's a meta-methodology, which is why it's so hard to productize

More specifically, its a meta methodology that specifically rejects methodology as a one-size-fits-all, or even custom but top-down-imposable, product, but explicitly holds that methodology is an emergent product of continuous optimization within and specific to the team doing the work.

[MoreQARespect]

Scrum is training wheels for agile. If your team were truly terrible and previously had 6 monthly iterations or something you'll be seeing some "agile" benefits which may seem amazing compared to the bullshit you put up with before.

Training wheels do ultimately need to come off, though.

If you were using kanban, TDD, pairing, CI, close customer feedback, multiple daily releases and all that good stuff, enforcing Scrum is little different to putting training wheels on a tour de france team's bikes, patting the cyclists on the head telling them that if they use the wheels correctly it'll give them a speed boost.