Live data from Hacker News

Scrum Sucks

blog.mb-consulting.dev

131–140 of 298 posts

Re: Scrum Sucks

#131
post #20

Earlier quoted context omitted.

Scrum is just one offshoot of Agile. It has become laden with jargon, Scrum-specific job titles, and rapidly trained Scrum Masters. This obscures the fact that a competent team can start with traditional jobs and roles and use The Manifesto for Agile Software Development as their guide, with some modifications for a remote, Slack/Zoom world. Don't be afraid to dump Scrum.

Agreed. This is more or less what we did in the 90s, deliver quickly and incrementally with right-sized processes. Scrum adds so much complexity, heavy processes and endless meetings it is truly incredible.

The XP folks crystallized what a lot of people were doing (in ad-hoc ways) and documented it so others could reuse the learnings more easily. [There's more to it than that, but that's the core of it]

I think that's in-line with what you described above. I also think it captured what a lot of folks were trying to do at the time: shorten feedback cycles with RAD, etc.

Scrum - or whatever it is that we see in the wild that's called Scrum - is exactly how you (and the article) describe. The way I see it, the corporate types were scared of the devs actually being self-managing/self-optimizing teams, and decided to turn to an Agile-Lite that they could sell as being new and shiney, but it's still the same command-and-control distrustful crap under the hood.

(Non-Scrum) Agile did a great job at the lower layers (devs, facilitators), but nothing can change that much if you don't affect the management and exec levels.

Re: Scrum Sucks

#132
post #12

I agree that agile methodologies are a whole lot of bullshit, but the problem really is cargo cult. Most people working in software are juniors, and that includes most managers. The fact that they have a title of "VP operations" 2 years after graduating does not magically make them experienced. What do they do then? They read books about "how to lead a team", and they blindly apply what they find there. Because they…

> the problem really is cargo cult

I’ve said that many times over the years. The irrational mimicking of what others are doing created this Frankenstein model of working that proliferated over the industry.

Re: Scrum Sucks

#133
The best is when you, as a dev, get to have a struggle session with project planners because "your group's estimates are consistently half of the required points to complete the project." But, for some reason "then just double our consistent estimates for your purposes" is treated as a joke.

Re: Scrum Sucks

#134

The things I've taken from scrum and use at every team: - plan in 2 week chunks - estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev. - make sure you define what 'done' means, and make sure it relates to what exactly you are trying to measure (Eg just coding effort, work till feature can ship?, etc). This is probably the most tricky bit. - capture total…

“Past performance is not a predictor of future success”

Capacity planning only really works where you are creating the same thing over and over.

Otherwise I’d suggest it is better to just bring work in and work on it (kanban basically)

Re: Scrum Sucks

#135

Earlier quoted context omitted.

See this all the time. There is a huge distinction between teams that are oriented to be proactively planned and teams that are oriented to be reactive. Neither is bad and both need to exist. Things will break people will have to fix them and therefore reactive work will exist.

Yes, exactly! In my career I am usually the first ops/DevOps person on the team. These are usually startups who have been run by developers. Nothing wrong with that, I've spent most of my career as a developer. But there is typically a huge blind spot with developers when it comes to ops. That could be a whole blog post and will someday, but relevant here is that they often do not understand when I try to explain how…

This brings flashbacks of so many conversations I've had with scrum masters during kickoff meetings - "Estimate how many points this story has?"

"Depends on if I figure out the answer in 20 minutes or 20 days"

Re: Scrum Sucks

#136

Earlier quoted context omitted.

> everyone meeting This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup) I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't…

> Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup) It was even worse than this: The Scrum operators wanted an engineer from every team they interacted with to also join their meetings. So if a project made an API request to another project, they'd insist on pulling an engineer from that team into their weekly or daily meetings. I had daily meetings with 10 people, half of whom m…

sounds like my (big co) meetings. also in the "scrums" everyone gets stuck on one topic and it turns into an hour long debate that could have been resolved by 30 mins of coding.

Re: Scrum Sucks

#137
post #112

Earlier quoted context omitted.

> everyone meeting This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup) I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't…

As a counterpoint: back in the day (around 2010) at JetBrains we had a daily all-hands stand-up for several teams, about 15 people in total. It was literally a stand-up, that is, everyone stood in a circle. Everyone was expected to utter exactly two sentences: what has been done yesterday, and what are the plans for today. It usually took 10-30 seconds per person, so the entire meeting was under 10 minutes. It was pr…

Being relatively new to the SE game, I’m curious - why can’t this be done via Slack?

Re: Scrum Sucks

#138
I never liked Agile nor Scrum. It has been more than 20 years since the Agile Manifesto was written... can we apply something better?

Re: Scrum Sucks

#139
post #112

Earlier quoted context omitted.

> everyone meeting This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup) I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't…

As a counterpoint: back in the day (around 2010) at JetBrains we had a daily all-hands stand-up for several teams, about 15 people in total. It was literally a stand-up, that is, everyone stood in a circle. Everyone was expected to utter exactly two sentences: what has been done yesterday, and what are the plans for today. It usually took 10-30 seconds per person, so the entire meeting was under 10 minutes. It was pr…

This is how it should be done. No filler, no smalltalk — straight to the point.

Re: Scrum Sucks

#140
post #12

I agree that agile methodologies are a whole lot of bullshit, but the problem really is cargo cult. Most people working in software are juniors, and that includes most managers. The fact that they have a title of "VP operations" 2 years after graduating does not magically make them experienced. What do they do then? They read books about "how to lead a team", and they blindly apply what they find there. Because they…

Re-reading http://agilemanifesto.org/ (which is ridiculously short) and comparing it to an "agile practice" around you is very eye-opening.

Some companies actually practice agile development, and it works. They are small, nimble, and have very little process. But then they grow...

Post reply on HN