[noarchy]

>That's because it works. There's a reason it's popular.

Versus:

>That said: a lot of places don't do it correctly and really do deserve being called cargo cults.

That's how it always goes, right? Company after company implements some kind of Scrum process, and when it doesn't work the problem is never Scrum itself.

I'd contend that the reason things like Scrum are popular is that it gives non-technical managers things to play with: things like burndown charts, that gives them metrics to measure and show to their own managers. Devs aren't measured by lines of code generated per day anymore. Now it is all about "velocity" and burndown. Old wine in new bottles.

[varelse]

To be fair (and probably downvoted), _The Agile Manifesto_ is a great read IMO. None of its 12 principles mandate open floor plans, scrum or daily standups.

https://www.smartsheet.com/comprehensive-guide-values-princi...

Combine these with Joel Spolsky's 12 steps to better code and I'd call that a winning culture.

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

But that's never how it turns out so "you're doing it wrong" is (and I hate to admit this) a valid objection. Sigh...

[noarchy]

I actually agree that the Agile Manifesto is a good read. That's why I tend to use air quotes when discussing "Agile" at any shop, because I think it rarely resembles anything in the Manifesto. But I'm not sure one can sell certification courses as easily based on the elegant-yet-simple principles outlined in the Manifesto.

[thwarted]

There's being "agile" as in flexible and outlined in the Agile Manifesto, and there's being "Agile" as in Scrum. I've found myself, and others, referring to the later verbally as "capital-A Agile" to distinguish the two.

[dasmoth]

I'd agree with most of that, but for me the point where it starts to go off the rails is

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

No, not mandating stand ups and open offices, but it's used to justify those things...

[varelse]

Really? Because one fantastically productive team I was once on implemented this practice by eating lunch together most of the time. I have never seen a more effective way of keeping everyone up to date and synced. Sure, they mostly talked about movies, TV, or WTFever, but whenever something critical was in play, it was all about work.

And of course, the manager of that team has not been promoted in over 1.5 decades.

[abritinthebay]

Devs were always measured by velocity. It was just called "deadlines" or milestones in classical waterfall methods.

With Scrum (for example) that turns into a much more sane, smaller, easier to predict and adapt with metric. Which is due to smaller units of work and shorter turnaround times.

Scrum (and agile in general) isn't magic. It's just sane process improvements.

It's also not an all-in-one philosophy. You can take parts from it and still get benefits (usually ends up showing why you should be more agile however).

Simple daily standups, short sprints, and grooming+planning meetings each sprint will help most software companies a lot, even if they don't go full scrum/kaban/etc

[noarchy]

>Devs were always measured by velocity. It was just called "deadlines" or milestones in classical waterfall methods.

I tend to think that the entire concept of waterfall is a great strawman. At some point, "rapid iteration" runs into the cold, hard reality of how companies tend to work. There are definitely still deadlines, even if no one wants to come out and call them that.

I don't want to suggest that I'm dismissing everything coming out of Scrum (and its cousins) out of hand. But I also think that there's sometimes too much salesmanship pushing it. This represents the commidifying of Agile itself, where now there is money to be made in coaching teams, and selling certifications, regardless of what the end result is.

[abritinthebay]

You say salesmanship I say companies resistive to change ;)

The point of the manifesto and of training is to present the idealized form. All decent Scrum training will point out that, when the rubber meets the road, there are going to be compromises.

The idea is that it's more a frame of mind than a rigid system. If you approach the "cold, hard reality" with that frame of mind you'll still see improvement.

I'll give you a common real world example: having simple timeboxed sprints and daily 10 min standups is all many companies end up doing.

That's a shame but at the same time now that team has better team communication and better tracking of progress.

Will it be as good as it could be? No. Is it as bad as it could be? Also no.

It's a trade off.

The salesmanship that pisses off so many devs is because a truly Agile workplace requires buy in from all levels and know what helps get buy in from management? Certification, training, webinars, and enterprise-y biz-dev seminars.

There's a tendency of developers to think that every part of something that applies to them should be for them, but that's not true. That salesmanship is not aimed at you, it's useful training for you (I'm doing CSD training this summer for example), but that part is aimed at other parts of the company.