I quite enjoyed reading Scrum: The Art of Doing Twice the Work in Half the Time. It’s not the book that people are mad at, it’s the shitty implementation of what management thinks scrum is. Because they never read the book.
Thing is that when practically everybody ends up with a shitty implementation of scrum, maybe it is a problem with the methodology after all. At the very least this indicates that it’s hard to get right in practice. I’ve worked on teams with certified scrum masters who went through training courses, and it was still shit.
I think the methodology is fine and it certainly isn’t complex. It’s just difficult to start using it when the corporate culture isn’t able to adapt and change it’s structures, that’s the hard part. Also a topic in the book.
Scrum is “bottom up” and the scrum master doesn’t manage anyone or anything, they are there to serve the team and get rid of obstacles. The team is empowered. If there’s a “manager” for the team, that’s already a mistake. That role doesn’t exist in scrum.
It’s just difficult to start using it when the corporate culture isn’t able to adapt and change it’s structures, that’s the hard part.
Yeah but that’s almost every company ever. At what point do you blame the methodology then if it doesn’t work properly almost anywhere?
I feel like scrum and agile in general are almost religions at this point, just blind belief in a system you haven’t really seen work properly ever but you still believe in it.
I get your point and maybe there’s a better alternative to scrum that keeps the culture and structure intact.
I might be wrong here, but as I see it scrum is fixing problems by changing the team structure itself. If that structure is really the main issue, you can’t not make that structure change, call it scrum when it actually has nothing to do with it, and then blame your inability to adapt on the methodology you’re not using.
I don’t think you can truly change anything with these methodologies. At the end of the day most companies are still privately owned companies, and you as a developer will do what the owners and/or the managers tell you to do. The owners aren’t going to delegate important decisions to developers unless it’s a really technical thing. The part where “developers take control” in scrum is bullshit and always will be by necessity of how our economic system works.
I feel like Scrum and similar stuff just serves to obfuscate real material relations in the company that aren’t going to change no matter how many story points you assign to this or that or how many scrum masters you have. Also it makes micromanagement easier I guess.
I don’t read such books because they’re almost always written by “consultant” grifters trying to make money off of proselytizing the latest bullshit corporate fad. And it’s almost never based on actual data, just gut feelings and a few anecdotes. My own felt experience and that of my colleagues is enough to confirm that it’s all just corporate ideology bullshit.
You’ve never read the book in question… Because you think it’s filled with gut feelings and anecdotes… Which you know, because of gut feelings and anecdotes…
Okay different question then. Judging from your stance towards scrum, I’m assuming you have worked with it before and it didn’t go so well? What parts were terrible and how was it set up if I may ask?
Developers don’t take control in scrum. They are empowered to work autonomously, which is a big difference. Devs provide the complexity of stories and the PO decides in what order the team is tackling them.
Scrum doesn’t mean everyone just does whatever they feel like.
They decide how to implement it themselves is what I mean by that, the user story doesn’t give technical implementation details and it doesn’t give a specific solution. It gives you the problem and reason
I quite enjoyed reading Scrum: The Art of Doing Twice the Work in Half the Time. It’s not the book that people are mad at, it’s the shitty implementation of what management thinks scrum is. Because they never read the book.
Thing is that when practically everybody ends up with a shitty implementation of scrum, maybe it is a problem with the methodology after all. At the very least this indicates that it’s hard to get right in practice. I’ve worked on teams with certified scrum masters who went through training courses, and it was still shit.
I think the methodology is fine and it certainly isn’t complex. It’s just difficult to start using it when the corporate culture isn’t able to adapt and change it’s structures, that’s the hard part. Also a topic in the book.
Scrum is “bottom up” and the scrum master doesn’t manage anyone or anything, they are there to serve the team and get rid of obstacles. The team is empowered. If there’s a “manager” for the team, that’s already a mistake. That role doesn’t exist in scrum.
Yeah but that’s almost every company ever. At what point do you blame the methodology then if it doesn’t work properly almost anywhere?
I feel like scrum and agile in general are almost religions at this point, just blind belief in a system you haven’t really seen work properly ever but you still believe in it.
I get your point and maybe there’s a better alternative to scrum that keeps the culture and structure intact.
I might be wrong here, but as I see it scrum is fixing problems by changing the team structure itself. If that structure is really the main issue, you can’t not make that structure change, call it scrum when it actually has nothing to do with it, and then blame your inability to adapt on the methodology you’re not using.
I don’t think you can truly change anything with these methodologies. At the end of the day most companies are still privately owned companies, and you as a developer will do what the owners and/or the managers tell you to do. The owners aren’t going to delegate important decisions to developers unless it’s a really technical thing. The part where “developers take control” in scrum is bullshit and always will be by necessity of how our economic system works.
I feel like Scrum and similar stuff just serves to obfuscate real material relations in the company that aren’t going to change no matter how many story points you assign to this or that or how many scrum masters you have. Also it makes micromanagement easier I guess.
If you haven’t already, I’d encourage you to take a look and read the book. At the very least it’s some interesting stories being told.
I don’t read such books because they’re almost always written by “consultant” grifters trying to make money off of proselytizing the latest bullshit corporate fad. And it’s almost never based on actual data, just gut feelings and a few anecdotes. My own felt experience and that of my colleagues is enough to confirm that it’s all just corporate ideology bullshit.
You’ve never read the book in question… Because you think it’s filled with gut feelings and anecdotes… Which you know, because of gut feelings and anecdotes…
Okay different question then. Judging from your stance towards scrum, I’m assuming you have worked with it before and it didn’t go so well? What parts were terrible and how was it set up if I may ask?
Developers don’t take control in scrum. They are empowered to work autonomously, which is a big difference. Devs provide the complexity of stories and the PO decides in what order the team is tackling them.
Scrum doesn’t mean everyone just does whatever they feel like.
That means nothing to me. Just platitudes. I’ve never felt “empowered to work autonomously” in scrum.
They decide how to implement it themselves is what I mean by that, the user story doesn’t give technical implementation details and it doesn’t give a specific solution. It gives you the problem and reason
Sort of like communism
You misspelled capitalism there.
Touche