Live data from Hacker News

Scrum is a cancer

twitter.com

381–390 of 486 posts

Re: Scrum is a cancer

#381
post #374

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…

At my previous job, the "daily stand up" never lasted less than 30min, and often times went to 2 hours. Also, I didn't just have one "daily stand up" but two! One with multiple teams, and one with just our team because our manager really wanted to silo our work and ignore as much as possible other teams (especially QA for some bizarre reason).

Yes, we weren't doing "scrum" right, but like communism, no one does it right.

Re: Scrum is a cancer

#382
post #353

Earlier quoted context omitted.

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

This is the crux of the issue. A CIO once asked me what I thought was the most important factor for a software project to be successful. I told him good requirements. The CIO proceeded to lecture me with Agile you don’t really need requirements. I thought he was full of shit. It is the same thing as answering a question in the SAT exam. If you don’t know the question (requirement), how can you answer the question? Th…

Real Communists use Gantt charts. Henry Gantt's colleague Walter Polakov brought "scientific management" to Soviet 5 year plans.

Re: Scrum is a cancer

#383

Earlier quoted context omitted.

I honestly can't tell, because you don't have a history of joke comments and didn't include a /s. Is this intentional parody, or did you miss OP's closing line? > Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)

His point is not exactly invalid though? If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail? Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time ju…

> if you go into something with the intention of 'this sucks' and then do not even want to make it work

we can rephrase this as "the serum didn't work because you didn't have faith in it."

Re: Scrum is a cancer

#384
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 ?

> how did management respond when the progress slowed

Rule number 1: management is never wrong. The progress did not slow down.

Re: Scrum is a cancer

#385
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 ?

Standard playbook in this situation is everyone involved saves face by blaming the team who were driven out, then they adjust to the new normal and everyone forgets they were ever able to build and ship software.

Re: Scrum is a cancer

#386

Scrum means different things to people. To one manager scrum was a 30 minute sit-down chat in the conference room. To another manager was 2 minutes stand in the hallway. To another manager was a waste of time and he will come to each dev cube and get a gist of what we were doing. A software development is only a team only in name. If developers like to help each other and talk to each other without having to be round…

The common thread is that scrum always prioritizes the time of the managers over the time of the people producing the work.

Re: Scrum is a cancer

#387
I think Scrum is a transitional phase. It is a solution to the problem of having a dev team shared between multiple business functions.

The dev team keeps getting yanked around and interrupted. So every two weeks you get all the business people in a room and you have them make a list of things that the dev team will work on this cycle. Then the dev team can execute in peace. The Scrum Master's job is to protect the dev team. The Product Owner's job is to get the business people to converge on the prioritized list of work.

In a healthy organization, Scrum is much less useful. Scrum combines three different cycles: defining work, executing work, and reviewing work. In a flow-based process like Kanban, you can split them up.

The product manager builds a prioritized backlog of work, and the dev team estimates tasks to help do business ROI calculations. It's a collaboration between product and development.

The dev team implements tasks from the backlog one by one. You can batch up work to make a release, deliver incrementally, or use tools like feature flags. You evaluate whether features are effective working based on metrics.

Re: Scrum is a cancer

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

This is an apt observation. Anything negative. Even if true. Even if it doesn't reflect on you. They want someone socially aware enough that they can say negative things without saying anything negative. There's a nuance. "I understand where they're coming from. There's definitely situations where that is preferred", translates to "I disagree totally but it's their prerogative so I'm not going to worry myself too much with that decision."

It shows experience with people and ability to read between the lines.

Re: Scrum is a cancer

#390

Earlier quoted context omitted.

I honestly can't tell, because you don't have a history of joke comments and didn't include a /s. Is this intentional parody, or did you miss OP's closing line? > Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)

His point is not exactly invalid though? If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail? Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time ju…

I can't tell if you are saying Scrum socks when people hate it or when people are enamored with it. I guess it will work if everybody is casually indifferent?
Post reply on HN