4 ms·

What a bogus claim. No piece of working software of any merit was ever written before Agile! ... um, I joke, but this is the attitude I see from every propone

What a bogus claim. No piece of working software of any merit was ever written before Agile! ... um, I joke, but this is the attitude I see from every proponent of agile. "How can a team possibly deliver a product on time without sprints and ceremonies"? I've seen serious discussions about whether to use "Kanban" or "Scrum." They're completely different, you see: one has 4 columns for your open/to-do/in-progress/complete tasks, whereas the other has a list view for your open/to-do/in-progress/complete tasks! "Agile" has bugged the hell out of me the last 13 years, and one of the main reasons is that the people who push for this the loudest, have never deployed a line of code in their lives: Project Managers and their ilk. Their livelihood depends on owning a process and reporting the state transitions of the actual engineering work. I'm forced to have 2-week sprints at my company, and I just realized today that the Sprint Planning calendar entry --which I own for my team-- had expired a couple of weeks ago. Of course, no one on the team noticed because we're actually heads down merging code. But I'm sure the PMs will freak out. Now, all that said, I do support teams meeting every 2 weeks to review tasks and priorities. That's fine. But do we have to pretend that's "Agile"?

usefulcat 3y ago
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'.
- khazhoux 3y ago
  I'm talking about sprints, as is Boodman in the tweet. 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.
psunavy03 3y ago
"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.
- khazhoux 3y ago
  > "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.
  - psunavy03 3y ago
    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.
    - 3y ago
Cthulhu_ 3y ago
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.
- yc-kraln 3y ago
  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.
  - 9659 3y ago
    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.

usefulcat 3y ago

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'.

khazhoux 3y ago
I'm talking about sprints, as is Boodman in the tweet. 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.

psunavy03 3y ago

"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.

khazhoux 3y ago
> "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.
- psunavy03 3y ago
  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.
  - 3y ago

Cthulhu_ 3y ago

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.

yc-kraln 3y ago
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.
- 9659 3y ago
  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.