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

Scrum Sucks

blog.mb-consulting.dev

Post reply on HN
Print view View original

191–200 of 298 posts

Re: Scrum Sucks

#191

Post by ajmurmann »

kevinmchugh wrote: post #150
ajmurmann wrote: post #123

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.

Which is another flavor of Agile which is what everyone is always complaining about. I'd take some form of Kanban any day over doing rigid Scrum by the book. Kanban needs a lot very similar meetings though. You still need to fill the backlog, discuss the tickets. If you were to do Kanban by the book as described by the Agile Alliance, you'd still do standups, retro under a different name etc.

Re: Scrum Sucks

#192

Post by ed_elliott_asc »

bee_rider wrote: post #157
ed_elliott_asc wrote: post #118

Earlier quoted context omitted.

My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating. As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate. We normally continue with guesses that are meaningless.

What would you do if they actually gave you a week to come up with an estimate? Start drawing Gantt charts? 1/4 seems reasonable for a day or two, but I dunno… it seems like there must be some constant factor?

I’d draw a lot and probably prototype as well - I suppose the main thing is that we never get to that as we estimate but don’t do “big design upfront”

Re: Scrum Sucks

#193

Post by porridgeraisin »

The real culprit is coming up with a bunch of metrics that fail to model the actual performance of people. It instead incentivises going after the metrics. The type of orgs likely to metric-ify just happen to overlap a lot with the people that prefer scrum or agile or whatever.

Re: Scrum Sucks

#194

Post by Viliam1234 »

Aurornis wrote: 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 was trained in Scrum, but the main thing I learned was that it is the opposite of what the "companies using Scrum" do. When I mentioned that in the company I worked at (the one that paid for my training), I was told that "we do Scrum differently here". They paid for my Scrum training just to tell me to shut up and do it the traditional way, only now I was supposed to call it Scrum, and the existing meetings had to be renamed using Scrum terminology. Oh, except for the retrospective (the part where developers provide feedback on everything, including Scrum itself), because retrospectives are a waste of time!

So it seems to me that the main reason why "true Scrum has never been tried" is that most companies never intended to actually try it. They just wanted the buzzword.

Re: Scrum Sucks

#195

Post by sequoia »

People who don’t use scrum or sprints or any of it, two questions: 1. Do you actually have very few meeting and all of them are meaningful and useful? 2. Is your work predictable and both devs and PMs have a reasonable idea of how much work is coming up and the nature of the work?

I’ve worked on “no sprint” teams and I end up having several “weekly checkin” meetings for different projects, plus intermittent “stand ups” that lack a clear focus, plus my manager discussing tactical matters in 1:1s and the work plan is still a clusterfuck where it’s hard to know what’s priority, what work is coming up, ensuring we have requirements clarified before starting work etc..

The biggest mistake I see people making with sprints is not understanding that you cluster your planning over 1-2 days then you have 2-3 weeks with basically zero meetings besides standup or working meetings like system design. The benefit of scrum is lots of heads down time, the cost is you’re not allowed to just book meetings Willy nilly whenever you want. Most places I’ve worked have wanted the benefit of sprints but not understood or been willing to pay the cost (no-meeting weeks). So it’s agile rituals plus whatever other meetings you already had, and of course that sucks.

I feel like agile processes are this boogeyman and people think “just get rid of them and we’ll be good!” but you need some process or else work is chaotic. So what’s the better process that works for you?

Re: Scrum Sucks

#196

Post by h335ian »

andrei_says_ wrote: post #63
Aurornis wrote: 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 really like Dave Thomas’ talk Agile is dead long live agile. Dave’s name is listed as one of the creators of the agile manifesto. Basically, agile is an adjective. Anyone using it as a noun is selling snake oil. Yes, it is that bad - a whole industry built from the ground up to monetize a simple concept by enshittifying it into its very opposite. https://youtu.be/a-BOSpxYJ9M?si=tCvDcHYv7F77XbZ9 I also like Basecamp…

Been using ShapeUp for nearly a year now in an org of ~50 engineers.

Let me start by saying, if you intend to adopt ShapeUp, spend a great deal of time reading and buying into their structure of teams. Aside from SIP/QA & KTLO work, they flatten the “Core Product team” and build ad-hoc teams for a pitch that has won at the betting table - for that cycle. Trying to maintain standing teams with domains of ownership is a very challenging way to adopt this process.

In my experience, unless the entire org is drinking the kool-aid - hard - you end up with 6w cycles of waterfall. Pitches morph quickly from “present your idea that we bet against” to “write up a detailed design doc, along with an Epic, backlog and all projected work” - then the org will just do the work they want (betting or no). Now your team is committed to delivering on your pitch - any other work just gets dumped on the wayside - unless you’re on-call of course.

As with any other incantation of an agile process, you can bastardize it to confusion, thinking you’re smarter, or “we’re adapting this to fit our org”.

Folks, this stuff is a discipline. You have to buy in, you have to learn the principles, you have to practice them - as described - until you attain some degree of mastery that you can adapt. This is not an individuals game, this is at the org level. The individuals must commit with the org to gaining mastery before customizing to your liking.

In spirit - there’s nothing fundamentally broken with Scrum or Kanban or ShapeUp or whatever. It’s really how you hold it - and yes you can shoot yourself and others in the face by holding it wrong.

Re: Scrum Sucks

#197

Post by SCdF »

shortlived wrote: post #27

The things I've taken from scrum and use at every team: - plan in 2 week chunks - estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev. - make sure you define what 'done' means, and make sure it relates to what exactly you are trying to measure (Eg just coding effort, work till feature can ship?, etc). This is probably the most tricky bit. - capture total…

> - capture total velocity every 2 weeks and eventually use the avg for future planning

I have never got to this stage. Someone is added to the team. Someone leaves the team. New team members get more knowledge. Old team members get sick or take a lot of leave. The focus of what you're working on moves from one part of the code base to another.

Every time you have to throw your velocity out the window because you're not the same team any more, and those metrics are for a different team that no longer exists.

You could argue points are useful as a discussion point to make sure there isn't some massive piece of complexity hiding in something (everyone says 3 points, the quiet person who knows the most about it says 13), but even tshirt sizing covers that imo, and regardless after that you should just throw them away.

Re: Scrum Sucks

#198

Post by stcredzero »

Viliam1234 wrote: post #194
Aurornis wrote: 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 was trained in Scrum, but the main thing I learned was that it is the opposite of what the "companies using Scrum" do. When I mentioned that in the company I worked at (the one that paid for my training), I was told that "we do Scrum differently here". They paid for my Scrum training just to tell me to shut up and do it the traditional way, only now I was supposed to call it Scrum, and the existing meetings had to…

So it seems to me that the main reason why "true Scrum has never been tried" is that most companies never intended to actually try it. They just wanted the buzzword.

Scrum is actually a cultural change. The methodology is just the surface stuff, like the buzzword.

It also doesn't actually happen at the company level, unless the company is quite small. It happens at the group level. I just thought of this: The Scrum that can be named, is not the true Scrum.

"Practicing" Scrum by following dictums in a book is sort of like practicing marriage by following dictums in a book. Those are just guidelines, and the reality is at a deeper level.

EDIT: Come to think of it, that can also be interpreted as: Therefore Scrum is broken as a methodology. It cannot be "followed" at scale. (Much as communism is broken as an economic system.)

Re: Scrum Sucks

#199

Post by kevinmchugh »

iLoveOncall wrote: post #106
Aurornis wrote: 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…

We did a planning exercise every sprint at work to see how much time people had to work on features once you removed meetings and other ceremonies, RTO, holidays, oncall, etc. We were tracking that per employee. Everything was fine for a few months and then I added a "total" column next to each row and it became apparent that we were spending close to 60% of our sprint on non-development related tasks. On 45 work-day…

Do I understand correctly that you're doing nine week sprints? That sounds extremely long to me. I have to think you're spending lots of time planning work that won't be done. When you plan a sprint, how often does the work at the end of the sprint actually get completed by end of sprint?

Say you plan to start the "add Foo button to Bar page" in week 7, do you actually do that? That would require some really strong estimation skills and a remarkably stable product and business environment. What's the point in the sprint where you're doing more unplanned work than planned? Or how much carry over work do you have?

Because if I was trying to plan nine weeks of work, I'd get it drastically wrong, and waste tons of time planning stuff we weren't gonna do.

I would make the next few sprints 4 week ones and plan to get down to 2 week sprints after the shorter pace starts to show it's strengths.

Or maybe you have 9 people doing 1 week sprints and that's how you got 45 days. In which case, whoops! I have no suggestions!

Re: Scrum Sucks

#200

Post by iLoveOncall »

kevinmchugh wrote: post #199
iLoveOncall wrote: post #106

Earlier quoted context omitted.

We did a planning exercise every sprint at work to see how much time people had to work on features once you removed meetings and other ceremonies, RTO, holidays, oncall, etc. We were tracking that per employee. Everything was fine for a few months and then I added a "total" column next to each row and it became apparent that we were spending close to 60% of our sprint on non-development related tasks. On 45 work-day…

Do I understand correctly that you're doing nine week sprints? That sounds extremely long to me. I have to think you're spending lots of time planning work that won't be done. When you plan a sprint, how often does the work at the end of the sprint actually get completed by end of sprint? Say you plan to start the "add Foo button to Bar page" in week 7, do you actually do that? That would require some really strong e…

Oh yeah no I meant 2 weeks sprints with a total of 45 days (ish, removing vacations) for the whole team. Sorry that wasn't clear.
Post reply on HN