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

211–220 of 298 posts

Re: Scrum Sucks

#211

Post by al_borland »

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…

On the opposite extreme, our teams use Jira, kind of structure it like Scrum, but don’t do any of the actual planning. It’s complete chaos and we have a similar level of meetings, maybe more, with everyone trying to figure out what’s going on and when things will be done. The go-to is a 30-60 minute daily meeting with each individual project manager for each project. Sometimes there are 3 project managers working on different aspects of the same project, so we have 3 hours of meetings (spread throughout the day) to give the same updates 3 times. Of course, there is no update, because all we do is attend meetings to provide updates.

Occasionally our Scrum Master will put an actual scrum meeting on the calendar, but then talks about whatever he wants, and it never moves the ball forward from an organizational point of view. A retrospective would go a long way; we’ve never had one of those. I bring that up often, as the 1 meeting we should have, if we only have 1 meeting.

I tracked my time meticulously for several years, and when I used it to point out how horrible the current environment is, I was told I was doing too much and should be much my lazy about the tracking, to the point where it becomes meaningless.

Re: Scrum Sucks

#212

Post by convolvatron »

bluGill wrote: post #114
adrianmsmith wrote: post #59

It's interesting to speculate on why, if Scrum is so bad, everyone uses it? Is it because everyone is an idiot (e.g. management)? Or for some nefarious reason? Or maybe it isn't actually that bad? On one project I was on, there was a contractor company billing millions per year to create a React admin tool frontend. Many developers involved, Scrum master full-time, and so on. Tickets were created for small parts of f…

Because Developers are not the only stakeholders. Management and marketing needs to know when the next release will be. In a complex project it doesn't matter if you are ready to go with your part if someone else just merged in a new feature that is crash prone in situations they didn't think to test. In a complex project you may also depend on hardware being delivered at the same time. In a complex project there may…

Management and marketing needs to know when the next release will be and what will be in it. Cutting things up into two week segments, and religiously opposing any attempt to plan together as group or come with rough schedules undermines engineerings ability to interact meaningfully with those people.

Sales people, investors, and customers really don't care about how good you are about meeting your scrum targets or how many fictional story points you're able to get through.

Re: Scrum Sucks

#213

Post by shortlived »

tilwidnk wrote: post #147
bluGill wrote: post #84

Earlier quoted context omitted.

I have long abandoned scrum for Kanban. I don't care about sprints, and getting things done by the end. Just give me (or since I'm the team leader now often I'm the one giving) the next thing to work on and when it is done I'll start the next. Nobody cares about what you got done this sprint, they care about what what got into the next release. Next release includes a lot of manual testing as despite a very great aut…

Agreed, Scrum is a death march. Kanban is the way.

Yeah, you are doing it wrong if scrum is deadlines. I've worked with people who had to pull all nighters to get all sprint content done before the sprint closes. I'm using it more as a window to do some cheap analysis on our progress.

Re: Scrum Sucks

#214

Post by shortlived »

SCdF wrote: post #197
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…

Yeah, it won't work without a stable team. And that may be okay in a true agile environment but I've always had a manager who wants some type of estimate/high level schedule.

We do T-shirt sizes mapped to numbers, because recording effort in numbers lets you get an avg etc...

Re: Scrum Sucks

#215

Post by steveBK123 »

lowercased wrote: post #46
rightbyte wrote: post #14

Earlier quoted context omitted.

The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.

"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can r…

Also don't forget story point Goldilocks.

We don't create 1 point stories, you need to roll this up with another story! Hey we don't do 13 point stories, you need to break that one up! 8 points? you sure that isn't a 5? 2 points, 3 points.. what's the difference just mark it as a 2.

OK so basically we just have 2s & 5s then? Amazing.

Re: Scrum Sucks

#216

Post by inanutshellus »

ed_elliott_asc wrote: post #119
inanutshellus wrote: post #93

Earlier quoted context omitted.

Scrum teams are self-managing, and point values are used for gauging your own team-workload. When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found. Personally: * Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding". *…

Meetings are long enough without people spending extra effort doing it right :)

Sharpen the saw, man.

It's a one-time conversation (per new team configuration) that makes every conversation thereafter fast.

My team's pointing sessions are lightning.

Even when you do have a new team member that wants to discuss a "0.5-vs-5" point disparity, you explain the above in less time it took to read it and get back to work.

Re: Scrum Sucks

#217

Post by cableshaft »

CharlieDigital wrote: post #52
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…

> everyone meeting This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup) I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't…

> Big red flag is there is a daily all hands standup

Something I've seen for the first time at my current project is instead of a daily standup, there's a daily thread to report what you've been doing in Slack instead. And then as long as there's nothing people want to go over, the actual standup meeting is skipped. We sometimes go a 2-3 weeks without an actual stand up call. It's pretty nice. Even if not, the calls are only scheduled twice a week anyway.

Much better than the 20 person in-person daily standups in the conference room, better get there early if you want to have a chair, at 8:15am every day, like a previous job.

Re: Scrum Sucks

#218

Post by RaftPeople »

ajmurmann wrote: post #123
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 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…

> but I fail to understand what the alternatives looks like besides Waterfall or chaos.

What I've seen pretty much my entire career (early 80's) for projects is just a straightforward process of up some front planning, phased design+dev, management of tasks through a regular (weekly or twice weekly) low overhead process (what's ready for next step, where are challenges), etc.

The key is having an experienced technical leader to guide the process. Typically, PM's don't have enough detailed technical experience to really understand how to make this stuff work.

Re: Scrum Sucks

#219

Post by nine_k »

a_square_peg wrote: post #183
nine_k wrote: post #140

Earlier quoted context omitted.

Re-reading http://agilemanifesto.org/ (which is ridiculously short) and comparing it to an "agile practice" around you is very eye-opening. Some companies actually practice agile development, and it works. They are small, nimble, and have very little process. But then they grow...

Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.

Kanban came from elsewhere. The word comes from post-war Japanese car factories, but the principle is older. Kanban boards were physical boards, with tokens representing various machines' or workers' availability, and the presence of things to work on. It's more a work-scheduling mechanism for known, understandable, repeatable work.

https://en.wikipedia.org/wiki/Kanban

Re: Scrum Sucks

#220

Post by Eliah_Lakhin »

It would be interesting to attempt an analogy between software development processes and parallel computations. Let's analyze which job tasks are atomic, parallelized, depend on read or write operations with common shared data, and the costs associated with setting up new job tasks.

It is likely that we would discover that the majority of programming tasks are not parallelized and are costly to set up, especially if frequently switched between job workers. This is because programmers need to delve into the problem domain, the existing code base, the API, and various other factors before commencing an actual task implementation.

Assuming that task workers are fully fault-tolerant ("no bus factor"), the optimal design would involve dividing the code base into loosely coupled modules, possibly organized into a hierarchy, with each module's management entrusted to a single worker (programmer). To mitigate the fault factor, we might have substitutional task workers dedicated to critical modules.

Regarding other task types, such as manual testing, these are usually less expensive to set up, do not require write access to the code base, and can be efficiently implemented by worker groups not bound to specific code modules.

This approach should be scalable and could effectively contribute to product quality. However, it necessitates the business being run and owned by programmers, and more crucially, earning revenue directly from end users who value product quality—a major success factor for the business.

There are successful examples of businesses following this model, including many indie game development studios and some software product businesses. The scarcity of such examples in the broader business community is attributed to the fact that the majority of funds today come from large corporations and ultimately from governments. This system undermines the free market, impacting everything in software development, from product quality to development methodologies.

Post reply on HN