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

471–480 of 486 posts

Re: Scrum is a cancer

#471

Post by seadan83 »

ahtihn wrote: post #374
username332211 wrote: post #354

Earlier quoted context omitted.

> 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-qu…

> 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. I do not understand how this is possible. * Sprint planning: 2 hours * Sprint review: 1 hour * Sprint retro: 1 hour * Daily stand-up: 15min / day On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%. What…

Sprint planning is typically 4 hours [1]. I think there are further reasonable quibbles to be made that would revise that 7% number up to a reasonable 13% or 18%.

The 13% takes into account the time tax of context switching. 18% if we consider only (at best) 6 hours per day and meetings are taking away from that high productivity time (which is to say a greater proportion of time is spent around the coffee maker and not coding)

To go into detail, there is a tax to every meeting. With 13 scrum meetings this adds up fast. For me, as a remote worker, I stop everything 5 minutes before or else (for example) 1:57 is going to suddenly turn into 2:03 and then I'm late. Recovering from a meeting takes me about 10 minutes (plenty of resources state it takes 25 minutes to get back into a flow state once interrupted).

Thus, for me, the meeting tax of scrum meetings alone is 13*15 = 195 minutes. Further, there is a conflict as projects have their own required meetings (if the scrum meetings are the only meetings, then seemingly the team is just talking once a day and then not again - that sounds bad! So yeah, there are other meetings too).

Further, not all 80 hours are equal. Software development is a highly creative field, it's not an assembly line with interchangeable parts. If you have your developers in office for 90 hours instead of 80 you're not going to get 10% more on your story point velocity. Similar for 70 hours vs 80, eventually there is a point of diminishing returns.

By measures of how long I can pair program with someone, 5 hours is a pretty upper limit on how long I can stay in a high productivity state for one day. Time spent in meetings can take away from that high productivity.

Let's say a person can generously be in a high productivity state for 6 hours per day and that meetings take away from that time, then we are very reasonably at 10.75/60 => ~18%*

*I'll emphasizes we are talking scrum meetings only, and still not even taking into account prep time for the scrum meetings

[1] https://resources.scrumalliance.org/Article/scrum-events

"The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint."

Re: Scrum is a cancer

#472

Post by afro88 »

seadan83 wrote: post #464
afro88 wrote: post #356

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.

> and the business can rely on delivery dates for commercial and marketing? Agile/scrum is almost explicitly contrary to this goal. There is a chance every two weeks to change scope, requirements, direction. What happens when requirements change? Work is redone, new work is taken on, dates get pushed. Scrum does not provide predictability beyond one sprint, it is part of the point. The work of the next sprint is base…

I know, I said:

> I'm not saying scrum and agile achieve the above.

Companies abuse scrum to try and achieve the last 2 objectives. Sprints become commitments, sprints are planned out in advance, story points become days etc

Re: Scrum is a cancer

#473

Post by spc476 »

t43562 wrote: post #453
spc476 wrote: post #433

Earlier quoted context omitted.

First, there was major miscommunication on the part of the new management [1] and who I thought was my manager wasn't [2]. Second, I was raising the alarm that the "agile and scrum" methods weren't working, and got it raised to a VP of the company [3]. He was let go. Did I cause him to be fired? I don't know. All I know, the new VP just said "that's a shame" when I brought up my points. I knew then, it was time to go…

It sounds more to me like you could have just asked for meetings to end on time and quoted why they are meant to be held standing up.

No, it was more like before they pushed "Enterprise Agile with a side of scrum", the team I was on, for 10 years, produced code on time, with very few bugs and only two regressions to production (caught during deployment). Afterwards (bought out, new management), we kept missing our deadlines, bugs proliferated, and deployments became nightmares. The meetings were the least of the issues, but they weren't helping any.

Re: Scrum is a cancer

#474

Post by throwawaysleep »

bitwize wrote: post #442
throwawaysleep wrote: post #331

Earlier quoted context omitted.

Yep. I have come to love Scrum for the dysfunction it provides as a remote employee. I can sit in the background and do other things while not being expected to achieve anything.

Eyes are watching. Your manager is likely to bring up that you're not an active enough participant in meetings; and yes, it will count against you in your performance reviews.

Manager isn't in the Scrum meetings most of the time. Self managing team and all...

Re: Scrum is a cancer

#475

Post by rijoja »

adammarples wrote: post #365
IKantRead wrote: post #328

I still chuckle a bit when people get anti-scrum, because I've been around long enough when agile/scrum was the disruptive thing. Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against. One thing I thought was interesting was: > First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "S…

Critiquing Scrum in now way establishes you as an expert in teaching ML

Yes, that seems to be IKantRead's point.

Re: Scrum is a cancer

#476

Post by bitwize »

throwawaysleep wrote: post #474
bitwize wrote: post #442

Earlier quoted context omitted.

Eyes are watching. Your manager is likely to bring up that you're not an active enough participant in meetings; and yes, it will count against you in your performance reviews.

Manager isn't in the Scrum meetings most of the time. Self managing team and all...

Manager doesn't have to be in the meetings to become aware of problems you pose for the Scrum process. Multiple sets of eyes are watching.

Re: Scrum is a cancer

#477

Post by kypro »

eikenberry wrote: post #357
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 ha…

You're right. I had already got bad vibes from the interview by this point and started acting up a bit.

I was initially really interested in the company and made it clear early on that I really liked what they were doing and how I thought I could add value, but they started shooting me down assuring me the role I was applying for wasn't that interesting and that I'd mostly be a code monkey (obviously not in those exact words).

By the time they started asking about my agile experience and what I thought of scum I figured I didn't have much to lose being honest with them. It would have been in neither of our interest for me to pretend I might have been a good fit.

But yeah, generally I'll try to be mostly positive while finding something minor to be constructively critical about. I think that tends to strike the right balance between showing you can think for yourself without coming across as the type of person who will cause problems. Sounds like you've noticed the same thing.

Re: Scrum is a cancer

#478

Post by lpapez »

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 ?

Their view was that there was no problem, but rather that the new process was an improvement. I am not joking.

They said that we didn't measure the work before, so they had no visibility into how much the team does. But after introducing scrum, they were very happy to see that the team usually delivered around 20 story points per sprint, while the other teams in the company did around 10.

In my view, if we estimated tickets in old process as we did after introducing scrum, we would have been delivering around 60 points in two weeks through old process.

Re: Scrum is a cancer

#479

Post by lpapez »

siva7 wrote: post #314
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…

This wasn't scrum because talking to the costumer is the primary job of the Product Owner and not of the Scrum Master. PO is also a full time job and not some side hustle of a team lead or SM. Having a good Product Owner makes the difference between adopting scrum successfully or failing at this process. Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple -…

> Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.

How do you know no one was open to trying it? I specifically mentioned that I personally objected to scrum, but wrote nothing about other people.

What happened in fact was that people initially really tried their best ti cooperate, but it simply didn't work very well and crippled the team.

Re: Scrum is a cancer

#480

Post by lpapez »

karaterobot wrote: post #396
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…

Ugh, swapping out a successful development paradigm midstream sounds like somebody up the chain thinks change is the same thing as progress. In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our proces…

It never occured to me that the change can be framed this way, I will learn from this.

I thank you for this perspective kind stranger, truly.

Post reply on HN