Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum Sucks

blog.mb-consulting.dev

Post reply on HN
Print view View original

271–280 of 298 posts

Re: Scrum Sucks

#271

Post by brightball »

Aurornis wrote: post #7

I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…

Scrum often has very subtle issues that snowball into chronic issues. I've never seen it done well outside of contract dev shops where they are literally negotiating and selling each sprint to a client.

https://news.ycombinator.com/item?id=17154355

Re: Scrum Sucks

#272

Post by therealdrag0 »

sequoia wrote: post #195

People who don’t use scrum or sprints or any of it, two questions: 1. Do you actually have very few meeting and all of them are meaningful and useful? 2. Is your work predictable and both devs and PMs have a reasonable idea of how much work is coming up and the nature of the work? I’ve worked on “no sprint” teams and I end up having several “weekly checkin” meetings for different projects, plus intermittent “stand up…

I do monthly sprints with just 3 stand ups a week and an extended mid month checkin. No other ceremonies. Planning is done ahead of time by leaders without every IC present. Design is done by ICs as part of tickets in a sprint like any other work ticket. Basically no retros or any other ceremonies and it works well. No points or ticket estimations or time tracking. All working great.

I sometimes wonder if some of the agile methods overly fetishize some kinda democracy which adds way too much bikeshedding and overhead. Whereas if you just provide sane leadership and planning. Everyone is happy to do their part without endless rituals.

Re: Scrum Sucks

#273

Post by Aurornis »

The_Colonel wrote: post #229
Aurornis wrote: post #141

Earlier quoted context omitted.

> It's not a "no true Scotsman" (scrumsman :)) if the counterexample is in fact not a Scotsman. Every bad Scrum/Agile situation I've been in has orchestrated by people who were convinced they were doing it "the right way" Every defense I've read has been from other people who weren't there who insist that it must be "the wrong way". If you define the "right way" such that it can only be good, then you conveniently di…

Let's do a thought experiment. Imagine you have the same organization, same people, but a different methodology or perhaps no methodoligy at all. Would things get significantly better?

I can't imagine how it could get any worse.

It became really difficult to push back on or change anything because the Program Managers would band together and brandish their Scrum certifications, Scrum books, Scrum podcasts, and other credentials to show that we couldn't argue with them. Unfortunately, it worked with management.

Wipe all of that away and let all of us work together toward a methodology that worked for everyone without Product Managers playing the Scrum card at every disagreement and I have no doubt it would have been better.

In fact, I have some proof: There were a few pockets of small teams that got to operate outside of the Scrum madness either because their tasks were thought to be too small or temporary, or because they existed in islands of the org chart that were free from the reaches of the Scrum people. These small teams ran circles around everyone else, but that would come grinding to a halt as soon as their projects got assimilated into the Scrum catastrophe.

Re: Scrum Sucks

#274

Post by Aurornis »

galangalalgol wrote: post #116
Cpoll wrote: post #82

Earlier quoted context omitted.

It's not a "no true Scotsman" (scrumsman :)) if the counterexample is in fact not a Scotsman. Whether it is or isn't depends on your feelings on scrum, but it's not a fallacy to try to defend the initial definition before it was co-opted by anyone with an Agile cert. "Hammers suck at driving nails." "You're holding a rubber mallet." "No true Scotsman!"

And agile methodologies are not agile by the definition. Agile is a set of relative values, not a methodology. The first being to value people and interactions over processes and tools. No process is agile, no process can be.

I hear these aphorisms a lot, but none of it actually matters.

Agile has been plastered over certifications, podcasts, books, conferences, trainings, and everything else for years. The people I referred to above had been through it all and brandished it like a weapon. You can tell me all day that it's not true agile but it didn't make an iota of difference to how things play out.

Judging by the comments, my experience is not unique.

Re: Scrum Sucks

#275

Post by sdiupIGPWEfh »

michaelt wrote: post #74
calvinmorrison wrote: post #53

Earlier quoted context omitted.

Until you're on 4 teams

If a person is in 4 teams, and they're not a full-time 'product owner' where going to meetings is their whole job, I'd say something bizarre is going on.

How many teams before you consider it bizarre? As a mere individual contributor / senior dev, I've only ever officially been assigned to a single team at once, but there are times when I'm juggling tickets on 3 different teams' Jira boards and attending 3 different standup meetings. Thankfully, I typically don't have to worry about sitting in on more than 2 teams at once, and I'm definitely an outlier. For me, this arose from joining a growing team before it split several times and also from predating all the current product owners.

Re: Scrum Sucks

#276

Post by olah_1 »

davidham wrote: post #176
olah_1 wrote: post #168

Correct me if I’m wrong, but Sprints only make sense for teams with more than, say, 4 engineers. Because a Sprint is fundamentally about estimating bandwidth. You look at the old Sprints and are able to average out some kind of true estimate of capability, right? But if you have a smaller team, everyone basically already knows what your bandwidth is.

I would say that a sprint is fundamentally about delivering a valuable Increment. Something useful, some kind of meaningful progress. You can start to use past performance as a way to estimate what you'll be able to do in the future, but only with a stable team that has been estimating its own work for a while.

The problem is, you don’t need a sprint system to do an incremental release.

Fundamentally, Sprints run parallel to incremental releases and are not supposed to be synced with them.

For example, a Sprint is once every 2 weeks. But the next product release could be determined whenever a certain feature is completed.

Re: Scrum Sucks

#277

Post by kevinmchugh »

ajmurmann wrote: post #270
kevinmchugh wrote: post #265

Earlier quoted context omitted.

I've never seen an empty backlog, but I've been in meetings the purpose of which is for an entire team to rubberstamp the order of the backlog. This is "grooming" or more recently "backlog refinement". You don't need to do this in kanban.

Don't you need to go over newly added tickets and ensure the tickets are clear, order makes sense, etc? Whenever we've skipped this some issues would emerge when tickets get picked up later. Depending on the project domain and if a PM or engineering lead wrote the tickets the issues would be either more about technical issues or misunderstanding of business requirements. > I've never seen an empty backlog How about a…

Tickets are often written imperfectly but that doesn't necessitate a standing meeting for the whole team imo. Make your pm and em hash them out, make the most informed engineer write the ticket, but don't make everybody watch.

If the top of your backlog is uselessly stale, you're spending too much time writing tickets in the distant past and not enough recently (or maybe congrats on your velocity?). A ticket that's so old it needs to be overhauled to be worked on was written prematurely. This is one of the things kanban is good at.

Edit to add: a team that's heavily reliant on a PM might not be a great fit for kanban? It's not for all teams, and is a natural fit for some

Re: Scrum Sucks

#278

Post by koonsolo »

Aurornis wrote: post #7

I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…

Why not bring this up in the retrospectives? Why not make your process leaner in the retrospectives? That's what they are for, no?

Self-organizing teams is at the core of agile. So I hate to say it, but if you don't self-organize as a team, you're doing it wrong.

The fact that you have to go to your VP to present hours says it all, your team is not empowered.

Re: Scrum Sucks

#279

Post by torginus »

The_Colonel wrote: post #243
torginus wrote: post #107

Earlier quoted context omitted.

Never in my life have I encountered anyone from the engineering side who spoke positively about scrum. It's always the consultants and scrum masters and their ilk who push the agenda. Never have I ever heard about any story about agile making things better.

I'm old enough to have extensive experience from before agile methodologies were in vogue and things are generally better with Scrum / Agile than they were before, ceteris paribus. Sometimes the process worked better, sometimes worse. It depends a lot on the company culture and people. The company I'm currently at has a very good process (SAFe). (I'm an engineer to clarify)

I also think there is a certain comorbidity of an organization pushing scrum heavily and other dysfunctions.

From what I've heard before my time, a lot of traditional organizations had a non-flat hierarchy and a set of 'bosses' - people in charge of personnel, planning, requirements, and technical decisions.

In 'modern' orgs this has been replaced by a 'matrix' structure with each team having a dedicated product owner, scrum master, line manager, requirements engineer, architect etc.

While the traditional org structure had some shortcomings, mainly having to do with the fact that if said boss didn't perform, then the team had no chance, and that so much institutional knowledge was locked up in said boss, that they were nigh-impossible to replace.

Modern management techniques are about replacing potential excellence with guaranteed mediocrity.

Re: Scrum Sucks

#280

Post by andrei_says_ »

h335ian wrote: post #196
andrei_says_ wrote: post #63

Earlier quoted context omitted.

I really like Dave Thomas’ talk Agile is dead long live agile. Dave’s name is listed as one of the creators of the agile manifesto. Basically, agile is an adjective. Anyone using it as a noun is selling snake oil. Yes, it is that bad - a whole industry built from the ground up to monetize a simple concept by enshittifying it into its very opposite. https://youtu.be/a-BOSpxYJ9M?si=tCvDcHYv7F77XbZ9 I also like Basecamp…

Been using ShapeUp for nearly a year now in an org of ~50 engineers. Let me start by saying, if you intend to adopt ShapeUp, spend a great deal of time reading and buying into their structure of teams. Aside from SIP/QA & KTLO work, they flatten the “Core Product team” and build ad-hoc teams for a pitch that has won at the betting table - for that cycle. Trying to maintain standing teams with domains of ownership is…

Thank you for this. My sense is that shapeup requires more trust than what a large org is used to. Eliminates the micromanagement and limits the risk to n weeks.
Post reply on HN