"Every" is a pretty big word, and it's a pretty immature attitude to write off whole groups of people.

You also don't seem to have much understanding of any of the key concepts of Scrum, Agile, or Kanban beyond "merging code is all that matters!" News flash: you "merge code" for a business who has business requirements and customers, and if you ship the wrong stuff, all you've accomplished is lighting lots of money on fire and wasting your professional life.

It's a common attitude among immature devs who can't get beyond the whole "I have the most important job in the company" mindset. I'd expect it out of a junior dev, but someone who has 13 years of experience? That's not the flex you think it is.

> "Every" is a pretty big word, and it's a pretty immature attitude to write off whole groups of people.

"Every" usually doesn't literally mean "every", but I'm sorry that my experience across several large companies is that the people that demand following "Agile Ceremonies" are by-and-large Project Managers, and (with rare exception) not the engineers or the technical eng managers. I've seen this at multiple large companies. And I remember clearly how much awesome, robust software we shipped before Agile creeped in around 2008-2010, to then be told we were "doing it wrong" because our work wasn't broken down into 2-week sprints.

> if you ship the wrong stuff

Two-Week Sprints are neither necessary nor sufficient to avoid this.

> It's a common attitude among immature devs who can't get beyond the whole "I have the most important job in the company" mindset. I'd expect it out of a junior dev, but someone who has 13 years of experience? That's not the flex you think it is.

That's super ad hominem. I'd rather hear a specific counter-argument on the necessity of Agile sprints.

2-week sprints are neither always necessary nor required. And yes, there are unfortunately plenty of inflexible idiots pushing cookie-cutter methods like that in industry because they don't understand the deeper reasons behind what they're asking, such as empirical process control theory and the behavior of complex adaptive systems.

But what's equally ad hominem is this implication that every agilist is this incompetent, that no one who goes by that term has ever deployed code, or that Agile as an approach is always wrong and always inhibits delivering good software. THAT is immature. That's taking bad implementations and generalizing them to say that every implementation is automatically bad. Just because the Detroit Lions are historically horrible isn't empirical proof that it's impossible to play good football.

Agile is not two-week sprints. Agile is not daily standups. These are tools which may or may not be appropriate in a given context. Agile is a mindset, not a strict process, and it was originally developed by engineers for engineers. The fact that you're even bringing "Project Managers" into the discussion is telling, because that is not a role which exists in any credible Agile organization, and for good reason.

> Agile is a mindset, not a strict process, and it was originally developed by engineers for engineers. The fact that you're even bringing "Project Managers" into the discussion is telling,

I think true Agile and agile organization are big foot that common people like me have never seen. Only enlightened Agilist understand the meaning of:

Agile is Nothing, Nothing is Agile. If scrum is not enough have scrum of scrums if scrum of scrum is not enough have scrum of scrum of scrums (duh).

Again . . . make an actual argument. This is just flinging shit like monkeys, or like an arrogant junior dev who thinks the world revolves around their specific role because they just figured out lambda functions or something.

Agile is like communism, the only reason it never works is that Real(tm) Agile has never been tried. This is the argument you have been making this whole time while accusing the other commenter of flinging shit like a monkey.

I think it is wrong to look for "true agile", as it's not a set of checkboxes to fill. I agree with other comments that sprints, backlogs, etc. are just tools to pick from based on the problems you're facing. You see them proposed time and again because many organizations face the same, boring problems as everyone.

To me, the only one true principle of Agile is to: - Always take time to reflect on the way you and your team work - Discuss openly if it's appropriate or not - Be ready to accept ANY solution that is discussed, be it organizational, technical, or self-improvement.

I would even go as far as calling it a basic principle of engineering. It is very simple to state, but very hard to implement due to our human nature (ego and feelings get in the way of open discussion and self-change) and budgets (taking time to discuss and implement change feels like a cost to most management, not added value).

There were examples of this principle and mindset in many organizations long before Agile was codified, and it can actually cause valuable results in organizations that look nothing like the stereotype of Agile !

For example, the NASA software department was famous for stopping all developments any time their QA detected any bug, and taking the time needed to ensure this kind of bug can never be committed again in the future. This kind of behavior is extremely Agile to me : continually improving your process to match your requirements. It is very slow and expensive for them, but it matches the stakes (potential loss of lives).

If you read TFA, it's abundantly clear that the author is talking about death marches (they even use that word), not the agile meaning of 'sprint'.

I'm talking about sprints.

And having some proximal observation of the Chrome team at work, btw, Boodman is spot-on that that team kicked ass because they had awesome engineers and super-technical leadership.

Counterpoint, the people that strongly oppose agile practices the loudest have never managed a software project in their lives.

In your case, you've CHOSEN to ignore the scrum practices in favor of nose-to-the-grindstone death march. If your company says "we do scrum", that gives you and your team ammunition to say "no". Or in other words, poor planning on management's side does not constitute an emergency on yours.

Scrum practices, if done right, offer predictability. Management loves predictability. You should love predictability as well because it means you won't have to do overtime / stress.

Hey, so, I have managed a ton of software projects. I strongly oppose Agile, "agile" and nearly every variation thereof (SAFe is the worst). Not every software project is a website contracted to an agency for the lowest possible cost, and any software of any consequence has a lifetime of decades, not minutes, so "working code over documentation" is a fundamentally flawed basis, before getting into any of the other bullshit cargo-culting nonsense that flows from the agile methodology.

you identified the exact problem. developing a website with very inexperienced people? requirements very fluid from the customer (they know what they want when they see it)?

agile, as practiced today, is the way to go.

building a defined system with performance requirements? with a budget? using staff that understands the technology?

something else, is the way to go.

in my experience, a short requirements exercise (say 10% of the expected project duration), followed by development iterations, is the way to go. how long are the iterations? between 2 weeks and 3 months.

take time for design. have milestones where the system is functional and stakeholders can interact. but not continuously.