Ask HN: Do developers have positive experiences with Scrum?
18 comments
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.
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 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.
As a practical matter, what was actually done differently at the place where it worked?
I’d say the biggest difference was:
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.
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.
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.
Hm... All this to say—no—I've never had a positive experience with it.
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
This sounds like a better approach. https://basecamp.com/books/shapeup
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....
https://github.com/rayfrankenstein/AITOW/blob/master/README....
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.
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.
Since you mentioned SAFe I assume your company is not small, I have never met a good way to really be Agile in bigger companies (there might be rare counter examples, I know)
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.
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.
> 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.
And if you don't hire like that, don't worry, scrum will quickly turn all your engineers into that as well.
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.
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.
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.
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.
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.
Agile/Scrum/etc are not meant to be positive for developers. They are meant to control developers.
Are there individual contributors here who have had positive experiences? What were the conditions that allowed it to function well, or what proactive things did you do to make it work?