Do developers have positive experiences with Scrum?

I worked at several startups that used a simple Kanban board - no standups, no ticket sizing, no sprints, no nothing - just a simple list of tasks and their status. All of them ended up adopting Scrum at some point, and all of them ended up less efficient, with developers wasting time with useless standup meetings, bikeshedding over ticket sizes, and wasting time breaking down a ticket into a dozen smaller tickets.

This never made sense to me. It was obviously an inferior system, so why did they want us to adopt it? Until I suddenly realized that the advantage of Scrum is not to make developers move faster, but to minimize distrust. Without Scrum you may have deveopers moving faster, but you may also have developers slacking and taking too long to complete simple tasks. With Scrum, management at least has the illusion that this cannot happen by forcing you to fulfill a preallocated amount of work every sprint.

Nowadays I see the rigidity of their Scrum process as a measurement of how much management trusts their developers, and how much they are willing to slow down their developers in order to trust that they are actually working.

I’ve had good experience with actual Scrum, as described by The Scrum Guide (https://scrumguides.org/scrum-guide.html).

I have had terrible experiences with bastard scrum: Standups as manager reports, sprints as death marches, stories without a definition of ready or done, stories added during the sprint, no backlog refinement, etc.

In my experience many companies doing “scrum” are actually doing daily manager reports and weekly top-down deadlines of fixed scope, while calling these “standup” and “sprints”.

In my 15-year career I’ve only worked with one company doing real Scrum, and all the companies doing bastard scrum were startups.

I will say the general _idea_ of scrum is alright, but the moment it's used to gauge team "progress" it ceases to be a good measure anymore. Most of the time, it's just used to navel gaze and/or instead of asking for direct feedback from teams, managers will use it as a crystal ball to try to divine what "blockers" the team is facing.

Hm... All this to say—no—I've never had a positive experience with it.

I liked the theory, and have been disappointed with a few companies' implementation. Generally speaking they tried to focus on 100% accurate estimates, which proved hard given the maturity of the team.

One company did SAFE, which worked reasonably well. I loathed the quarterly PI day, but I guess it had value. After a year I felt monotony creep in. Retrospectives didn't yield that much improvement. This was broken through by an improvement kata.

Having said all that, I am currently burned out from my company trying to execute a project with changing scope and fixed non-negotiable deadline as a waterfall project. I look back favorably on most half-baked scrum practices of the past. Especially when an agile coach was present for long periods of time.

All the teams I've been on that moved to Scrum have definitely been less productive using Scrum. I'm sure it can work but I don't think it has many benefits for actually shipping features.

This sounds like a better approach. https://basecamp.com/books/shapeup

The first time I expirienced Scrum rituals I thought I'm inside the Idiocracy movie, or playing some tech-themed LARP game.

In my anecdotal expirience the same org moved from mini-waterfall to Scrum now required order of magnitude more people to work on a project with a fraction of complexity (e.g. equivalent to a single component/service under mini-waterfall).

Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.

If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.

Here's what many developers will actually say about agile and scrum when their managers and scrum masters are out of earshot:

https://github.com/rayfrankenstein/AITOW/blob/master/README....

I had really good experience with Scrum in a small product team inside a big company, but the team acted as a startup inside a company, had a lot of freedom, schedules were flexible and budgets were large.

Then I had decent experience with scrumban in a team at one of the giants, but again we were lucky to be delivering utility products and not to end customers so we had a lot less dependencies.

Scrum is like communism. A good idea that doesn't work in reality. It's good on paper.

Perhaps I never experienced a proper scrum team as the places that I worked always tried to follow a rigid process full of control and bottlenecks caused by some brainless managers.

For me scrum is always bad but not all of it is bad.

I like planning poker and refining tasks together with others. I don't believe that the found estimates are worth anything, but I like the refining part as the tasks will be better defined in the end.

The daily standup is ok, but I just want to talk to the other devs and no management. Most standups were about making your work visible to management and this is wrong use of standup meetings. Making different person hold the meeting is preferable.

Also I don't see a point in having a scrum master which is some person which is not one of the developers. Anyone can send meeting invites. I don't care if the person has a scrum master diploma. Fuck off already.

Finally.. Kanban work so much better without all the bureaucratic waste of time.

Most of companies I used to work to use good parts of SCRUM and disable not interesting from a process. For myself, every ritual for people is a driver, it makes stages for every participate, even they ignore or hate it. Ritual is game from Jungian Theory Game System.

Although defenders of Scrum often include Product Owners, Scrum Masters, and managers due to their responsibilities, positive experiences aren't exclusive to them. Developers, engineers, and QA testers can find value too. Clear communication, collaborative dynamics, and well-defined tasks contribute to success. Embracing iteration and participating in regular retrospectives also enhance the methodology's effectiveness for individual contributors.

Moreover, for more insights, consider consulting TechnBrains' developers as a further guide: https://www.technbrains.com/services/hire-developer/

Agile/Scrum/etc are not meant to be positive for developers. They are meant to control developers.