Live data from Hacker News

Scrum Sucks

blog.mb-consulting.dev

111–120 of 298 posts

Re: Scrum Sucks

#111
I retired two years ago, but finally made peace with SCRUM in my final years by eliminating standing team meetings for retrospective / review / backlog.

Backlog - groom during long/medium term planning. Not everyone needs to be in the room for this, just leads. Use 1:1s to triangulate on issues that we're ignoring or under-resourcing.

Retro - on an infrastructure team, retros are already built into the incident management process.

Sprint review - start sprint planning by asking how'd the last sprint go. Did anything gunk up the works? Are there any promises we didn't keep? The rotating on-call and triage (secondary on-call) would fill us in on any active fires, or less us know if we can/should hand ownership of an issue to another team.

Re: Scrum Sucks

#112
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…

> 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 pretty efficient: you almost instantly knew who are you going to talk to later in the day, if need be, or what changes to look at.

Re: Scrum Sucks

#113
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…

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…

There should be a saying, to the effect of: no enterprise idea can survive intact if it doesn't include a space for consultants.

Agile probably would have ended a lot better if it had been as designed... plus a requirement that you had to hire an agile specialist to sit in a closet.

The agile specialist doesn't do anything but sit in the closet.

... but on the plus side, the agile specialist doesn't do anything but sit in the closet.

Re: Scrum Sucks

#114

It's interesting to speculate on why, if Scrum is so bad, everyone uses it? Is it because everyone is an idiot (e.g. management)? Or for some nefarious reason? Or maybe it isn't actually that bad? On one project I was on, there was a contractor company billing millions per year to create a React admin tool frontend. Many developers involved, Scrum master full-time, and so on. Tickets were created for small parts of f…

Because Developers are not the only stakeholders. Management and marketing needs to know when the next release will be. In a complex project it doesn't matter if you are ready to go with your part if someone else just merged in a new feature that is crash prone in situations they didn't think to test. In a complex project you may also depend on hardware being delivered at the same time. In a complex project there may be people planning when they can safely role this out to their system.

Agile works great for a small project where a few developers is all you need. However few in the agile manifesto seem to have thought about how to scale it to larger projects. That isn't to the manifesto is wrong - it very much fixes some real issues with previous project management. However some of those real issues were an intelligent response (not to be confused with good!) to even more complex issues that you cannot ignore just because they are causing issues.

Scrum is one of the few that thought about the large project problem, and so it appears at first you can scale it to larger projects. However now that we have tried it for a while I can safely conclude it isn't a great fix. I'm not even convinced Scrum is better than waterfall (waterfall has iterations - version 1.0, 2.0...), though scrum and waterfall get different things wrong with project management.

Of course the next question you should be asking is how do you manage a large project. I do not have an answer. I haven't even seen evidence that anyone has found a good answer despite many smart people facing the problem and thus thinking about it.

Re: Scrum Sucks

#115
post #82

Earlier quoted context omitted.

> the Scrum proponents will rush in and tell me that we were doing it wrong The "no true scrumsman" fallacy at work.

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

This. People love dunking on Scrum because they have colleagues and managers that wield it as a weapon (often in conjunction with JIRA, which, although not an especially simple or well-running piece of software, is really only as bad as you choose to make it). It's actually a very simple process that was designed as the _antithesis_ to a lot of the atrocities committed in its name (based on a reading of this thread).

If you have managers/PMs/TMs/HMs/BDFLs that can't see the forest from the trees and a corporate mandate to use Scrum (or Agile generally) then of course they'll pervert it to suit their own ends. Slow-moving organizations with complex incentive structures like the government and Fortune 500s are especially good at this. If you want to be upset with somebody then blame them. I've worked on teams where stand-ups were less than ten minutes long, we delivered every two weeks, and we had properly-specified Scrum Master and Product Manager roles and it worked swimmingly because we _actually did Scrum_, not "Scrum, but...".

Scrum is a prescribed process. It is not the performative act of dragging work items into Sprints in JIRA then using various Scrum terms for 5-hour-long weekly meetings.

Re: Scrum Sucks

#116
post #82

Earlier quoted context omitted.

> the Scrum proponents will rush in and tell me that we were doing it wrong The "no true scrumsman" fallacy at work.

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.

Re: Scrum Sucks

#117

Earlier quoted context omitted.

The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.

I saw this on my last job! I was already adding time to my work like an extra point or two here and there But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprin…

When I've used Story Points as the team manager, one of the things I made sure of was to completely avoid looking at any given team member's velocity, ever. I only cared about the team velocity, and only for the purpose of estimating risk to the timeline.

At the round-table people would report their retired points, and I'd add them to a running tally I kept on a piece of paper next to me. "2+1+0+5+2+2+8+0+1." Then I'd record the velocity for the week for the whole team, and we'd move on.

Re: Scrum Sucks

#118

Earlier quoted context omitted.

"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can r…

I love hearing "points aren't time but you can think of them like days"

My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating.

As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate.

We normally continue with guesses that are meaningless.

Re: Scrum Sucks

#119

Earlier quoted context omitted.

I saw this on my last job! I was already adding time to my work like an extra point or two here and there But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprin…

Scrum teams are self-managing, and point values are used for gauging your own team-workload. When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found. Personally: * Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding". *…

Meetings are long enough without people spending extra effort doing it right :)

Re: Scrum Sucks

#120

Aside: We need an alternate viewing filter for medium like how nitter is to X. Every time I open a medium hosted link it is just unbearable. Edit: The firefox reader view (F9) works very well at getting rid of Medium nonsense and making it clean.

Lately I've been realising just how many sites will not even show the main content without JavaScript enabled. You mean to tell me you need JavaScript to show me a blog post that's 90% text? Medium does surprisingly good without JavaScript, I can read comfortably without the nonsense.

Same could be said about logging in. Now that all my local shops manage a facebook page instead of a website, facebook nags me to hell and back to log in, and not even shows everything.
Post reply on HN