Live data from Hacker News

Scrum Sucks

blog.mb-consulting.dev

201–210 of 298 posts

Re: Scrum Sucks

#201

One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.

[Waterfall](https://leadinganswers.typepad.com/leading_answers/files/ori...) was an incremental design process directly in opposition to the hirearchial process that it's commonly conflated with. That's the paper that coined the term Waterfall, note the contrast between the final Waterfall process from the traditional process (figure 10). "Documentation Driven Development" is basically Royce's Waterfall under a different name.

Waterfall has the following 5 requirements/steps:

1. Design first. It'll get replaced (see step 3), but is needed for requirement 2.

2. Document the design. This defines what you're building (this time around) and the tests.

3. Do it twice (build a MVP, test, refactor & replace it as requirements become clear based on customer feedback, update the design & docs & tests, use those tests for the improved version).

4. Plan, control, and monitor testing.

5. Involve the customer.

Requirement 3 is what makes Waterfall inherently an incremental iterative process.

Re: Scrum Sucks

#202

Earlier quoted context omitted.

I personally strongly dislike a lot of aspects in SCRUM (individual commitments stick out especially, together with the entire role of Scrum Master), but am not sure I see an alternative for some form of agile (without the TM), that is adjusted to the individual team's needs, for the vast majority of teams. Whenever I read these criticisms, a lot of it rings true, but I fail to understand what the alternatives looks…

The obvious alternative to scrum for many teams who wish to be agile is something based on kanban.

How do you refine features? How do you discuss team improvement measures? How does prioritization happen if you're working on a product?

The answer might be simple for small teams, but a lot more complex for larger teams, where the result might look eerily close to Scrum. One difference would be that meetings will take place infrequently and only "as needed", where I wouldn't trust most teams to recognize their needs.

Re: Scrum Sucks

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

Every meeting only has 1-5 people talking, regardless of how many people are in it. Especially if they're remote. Sometimes a large meeting with many listeners is ok, but the same 16 people meeting every day is a waste of time.

Re: Scrum Sucks

#204

I've seen it suck even worse when trying to manage large X-Ops organizations. Something about the work, let's call it DevOps for the sake of simplicity, simply does not seem to lend itself well to the scrum methodology. Often priorities will shift rapidly even during the course of 1 working day, issues are vaguely defined and poorly scoped by nature (AZ1 cannot reach AZ2, plz fix ASAP), and the work is extraordinaril…

Operations is operations and fits well into the kanban system. Business operations should consider embracing kanban. Work comes in, work goes out, repeat.

Scrum (with sprints and things) should exclusively be used for New Product Development and Pre-Launch iterations. Using it for operations/ongoing work/enhancements is broken from the start.

"Waterfall" as defined by these articles is mostly a strawman.

Standups only work if someone is in-charge enough to keep them on track.

Re: Scrum Sucks

#205
post #95
post #58

The term scrum comes from rugby, and it has nothing to do with organization. It's literally when something goes wrong, pack everyone together and get the ball moving again. Symbolically, obviously, ball=project. The problem, like everything these days, is corporatism. Things have been added to the old development model to create positions for knowledgeless managers to do nothing and make money. Agile means fast witho…

The real purpose of the scrum in rugby is to tie up half of the players (the forwards - the backs are not in the scrum) when restarting play. Literally to remove the forwards from the play after a restart, by having them all bound together with their arms twisted around each other. Then, when the ball pops out, the field of play is nice and empty for a few seconds and some running rugby can take place, while the forw…

To expand the analogy further the scrum, in modern rugby, is the worst part of the game and has gone through several iterations the last couple of decades to reform it as it often ends in a stalemate or arbitrary penalty to one side (as good as a coin flip), or worse: a head injury.

The approach has seen the game settle with "Crouch, Bind, Set", which seems to be a good compromise. And yet the hooker always, always ALWAYS, puts the ball in crooked and yet never gets called up on it.

In other words, it's all a big waste of time and energy.

(We're using agile at work, daily standups and retros, and it seems to be working)

Re: Scrum Sucks

#206
Scrum is really useful for exploration and innovation work, things that may not even involve programming.

In general I think sticking to Scrum for Software Engineering is overkill, or maybe the 2 week sprints are too short.

I've had much happier engineers and product owners when working in Kanban, a steady stream of work with as few meetings as you can manage is much better for SE work, it is harder to get it up and running though, and can take some time to bed in.

Re: Scrum Sucks

#207
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 personally strongly dislike a lot of aspects in SCRUM (individual commitments stick out especially, together with the entire role of Scrum Master), but am not sure I see an alternative for some form of agile (without the TM), that is adjusted to the individual team's needs, for the vast majority of teams. Whenever I read these criticisms, a lot of it rings true, but I fail to understand what the alternatives looks…

My biggest pet peeves are (a) when mature software or mature organizations pretend they are a three person startup and refuse to document anything and have meetings all day (b) when product owners say f the existing architecture or tech debt and literally tell you to rip out everything and install a new tech stack because it is agile.

These morons know nothing and bark out orders based on their agile bonafides which is nothing more than snake oil. A magical cure all irrespective of the problem you are trying to solve.

Re: Scrum Sucks

#208
post #144
post #49

Earlier quoted context omitted.

The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work. If the aggregate of the sprint planning, backlog refinement, retro and dailies is more than 10% of the total time (eg 1 full day out of a 10 day sprint) for most of the team then something bizarre is going on. If the everyone is losing 50% of their time to agile things then your proc…

It’s funny how every team I have worked on that embraced scrum was impressively broken in the exact same way.

Interesting, I never experienced a team broken by Scrum. Just a retro, planning, demo, 15min daily and that's about it. Lots of other meetings, yes, but none of them due to Scrum, but rather complex company processes.

Re: Scrum Sucks

#209
post #112

Earlier quoted context omitted.

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?

It absolutely can be, that's how my team does it.

I've also seen teams update wikis for their daily standup.

Re: Scrum Sucks

#210
I'm a scientist that through a lateral career move has ended up doing something akin to software development. This means for the last few years I have attended daily scrum meetings for the project I'm working on.

Perhaps it's my inexperience with software development, or maybe it's specific to the company I work for, or the people on my team, but but I find the entire process a gigantic waste of time and mental energy. How does everyone else deal with this? Is there a better way that will help me not dread attending my standup?

Post reply on HN