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 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.

1) A product owner that articulated clear and granular user stories with acceptance criteria, and kept them prioritized. Sprint planning was quick and easy as a result, and developers had freedom to design and implement the story within those constraints.

2) A good engineering manager (scrum master) that insulated the team from pressure from product owner, and ensured product backlog was well articulated and sprint backlog was reasonable and practical.

Both of these things are clearly described by The Scrum Guide and how scrum should work.

This can be boiled down to trust: Is the company a high-trust environment where people are respected, or a low-trust environment where people are treated as machines. Sadly in my experience, most of this industry is the latter.

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

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

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

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.

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.

And if you don't hire like that, don't worry, scrum will quickly turn all your engineers into that as well.

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.

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.