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

Scrum is a cancer

twitter.com

Post reply on HN
Print view View original

351–360 of 486 posts

Re: Scrum is a cancer

#351

Post by rawgabbit »

channel_t wrote: post #302

I haven't done a ton of Scrum in my career, but my observation of it, in concept at least, is that it's supposed to be sort of like training wheels for agile, which seems innocuous enough. What I have found particularly horrifying about some orgs adopting it is that the agile part (the part that's trickier to execute) gets thrown out the window in favor of what is basically waterfall with sprints, and then people eat…

That is reality. Agile made a straw man out of waterfall. In reality, no one practiced waterfall the way the Agile Manifesto claimed that it did. In reality scrum is waterfall with a new name. There I said it. Now I will face the agile inquisition.

Re: Scrum is a cancer

#352

Post by dylan604 »

systems wrote: post #327
lpapez wrote: post #274

In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…

I am curious, how did management respond when the progress slowed did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important what happened ?

this would be an example to be studied in future classes of business school if this resulted in a change like you would hope for. otherwise, it's business as usual, and no, the changes you seek would not happen.

i'm obviously turning this into a hypothetical

Re: Scrum is a cancer

#353

Post by Zigurd »

Zigurd wrote: post #347
notjoemama wrote: post #286

Earlier quoted context omitted.

I thought agile “fixed” waterfall because waterfall had all this effort go into a product only to get feedback at the end, which to me sounds like a failure of product not engineering. By having tighter feedback loops it was promised less man-hours would be spent. My impression is it’s changed what the man-hours are spent on. It’s harder to get an elegant architecture over 2-3 years of agile as opposed to waterfall w…

This "waterfall had all this effort go into a product only to get feedback at the end" was Winston Royce's own diagnosis of the problem with the waterfall model he formalized. That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile. You are also spot on that you can start an Agile project and find your architecture is a pile of…

Here is Royce's statement on his own waterfall model's risks:

I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

Re: Scrum is a cancer

#354

Post by username332211 »

lpapez wrote: post #274

In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…

> I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).

And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.

In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.

Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.

Re: Scrum is a cancer

#355

Post by dylan604 »

tasubotadas wrote: post #339

I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams). The remaining teams just needed Kanban. Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would for…

I'm one that prefers Kanban myself. List each task, be able to group those tasks, move those tasks to whoever needs them, move those tasks to QA or wherever finished tasks go. So, I prefer Trello over Jira any day

Re: Scrum is a cancer

#356

Post by afro88 »

What's the alternative, where devs are motivated and productive, the team can react to the market quickly, and the business can rely on delivery dates for commercial and marketing?

I'm not saying scrum and agile achieve the above. But what does? Seems like a 3 things pick 2 situation, and the 2 that get picked will time and again be the last 2.

Re: Scrum is a cancer

#357

Post by eikenberry »

kypro wrote: post #309

I got rejected from a job recently and I strongly suspect it was because I went on a rant about how awful scum was against my better judgement. Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don't care what you think of scrum (though they may phase their questions like this) they simply want to kno…

> I went on a rant

I think that sums up why you got rejected. Over the years I've found anything negative said during an interview process works against you. I really noticed this when I had a job I hated and some of that kept creeping into my interviews with me saying something about it (varied from rant to a few comments) and I was interviewing for a few months... I noticed this and consciously edited it out and had 2 offers in the next couple weeks. I've noticed it more subtly after that and have sense tried to make sure I stay 100% positive in my interviews.

Re: Scrum is a cancer

#358

Post by bitwize »

palata wrote: post #278
idkyall wrote: post #273

I think there's a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter. But, that's besides the point. Scrum doesn't exist to make developer's lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings. Scrum, imo, exists so that management and busines…

> devs have basically always felt like our time is being wasted in meetings. I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time". Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers". No…

Scrum practitioners often spout weird propaganda. I once remarked that a programming task might be time-intensive, and difficult to accomplish quickly in a process as meeting-heavy as Scrum. The Scrum Master then linked me to a FAQ item on some pro-Scrum web site which purported to assure us that Scrum teams spend far fewer hours per week in meetings compared to other teams. She might've had a point, albeit a small one, if:

* standups were limited to 15 min/day (all Scrum teams I'd been on took 30 min, minimum, to do standup)

* we actually had 1 hour retro, planning and refinement meetings (retro, the most useful meeting, was actually 1.5h, planning and refinement could take 2h)

* POs did not feel free to schedule arbitrary additional meetings to keep up with the increasing backlog. SAFe specifies a quarterly, multi-day, division-wide planning meeting to align disparate teams during which all the work you intended to do for the next six sprints was scheduled on a big board. Of course there was never enough time to point and schedule six sprints' worth of work, necessitating a pre-planning meeting, and sometimes a pre-pre-planning meeting. Hours each.

Re: Scrum is a cancer

#359

Post by ineptech »

This looks like nothing but engagement bait for twitter's new monetization program. If I tweeted "Capitalism is cancer" or "Socialism is cancer" I'd get a lot of dumb responses too, but that wouldn't be evidence of anything except that constructive debate involves nuance and asking thoughtful questions and defining terms.
Post reply on HN