Earlier quoted context omitted.
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."
Scrum is a cancer
391–400 of 486 posts
Re: Scrum is a cancer
#392Earlier quoted context omitted.
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
How do you "prefer kanban"? Don't all these methodologies use kanban boards?
Re: Scrum is a cancer
#393Earlier 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…
Re: Scrum is a cancer
#394I 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 think it has a lot to do with how good estimates can be, and how much can be shared between the members of the team. The extreme situation where the tasks are all boring/predictable and everyone in the team can do everything probably works well with Agile (or any estimation-based religion, I suppose).
The problem is that in many situations, many tasks are not very predictable (because they involve novelty, risk, exploration, challenge), and not everyone is capable of doing everything. In that case the estimates are a big joke, and Agile is just bullshit.
Re: Scrum is a cancer
#395In 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…
Re: Scrum is a cancer
#396In 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…
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 process, and how long will the initial round of experiments last?"
Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.
Re: Scrum is a cancer
#397The new methodology was quickly pre-empted by middle managers as a new power tool, Scrum mostly replaced Agile because of all the weird cargo-cult rituals and sexy names.
My experience with it has been widely negative. People staring at the void during "standups", bullshit amplification, ticket misuse and misread by management.
Never seen any improvement from it, only overhead and demotivation.
Re: Scrum is a cancer
#398I got so tired of hating Scrum with passion, that I pulled a 179 and wrote a comic book about it.
In your honor for your courage and honesty, adrianmsmith, it's free, today only. All enjoy!
Re: Scrum is a cancer
#399Scrum is a good tool for a bad manager https://www.yegor256.com/2015/01/08/morning-standup-meetings...
> She already knows what she is working for, and she is motivated enough. When she finishes on time, organize a meeting and give her a $500 check in front of everybody. This is what a good manager uses meetings for.
Re: Scrum is a cancer
#400Earlier quoted context omitted.
Ah yes the defence: "The process failed because you didn't have enough project managers on board" No the process failed because it was fucking shit and everyone went somewhere else. The only good thing heavy processes are for are propping up employment statistics.
Heavy process is fine and necessary if you are building, say, a skyscraper or a nuclear reactor. Most of us are not.