4 ms·

I disagree with most of the major criticisms here. I think it is a valid description of an experience using scrum half-heartedly, but not an argument against it

I disagree with most of the major criticisms here. I think it is a valid description of an experience using scrum half-heartedly, but not an argument against its purpose or value. Points, for example, the argument is based on the premise that teams are obsessed with points. What if the teams use points as a framework to discuss complexity? I have worked in scrum groups where if something was given a large point value it would be questioned and "split" to break the job into component tasks that could be done by separate people simultaneously (or some now some later). Long meeting times with the wrong people in the meeting? That's a managerial issue and has nothing to do with scrum. Writing stories is the main art of scrum and without good stories it is pointless. A story can be written to encourage a developers to improve quality of a codebase, share knowledge with another team, or take time to learn themselves. A really good story would encourage these things and also deliver customer value. Any system for managing software development hinges on good communication. SCRUM's main advantage to me is that it provides continuous opportunities for face to face communication. If you fail to take advantage or engage with those opportunities then it won't work, but I bet another "framework" wouldn't either.

tootie 10y ago
This is my experience also. Points are complexity and high complexity tasks are most definitely to be addressed by breaking down stories. Dependencies are also easily addressed by setting a Definition of Ready. Don't accept a story if the dependencies aren't met (be that APIs, environments, designs, whatever). Simple. Planning/grooming we do in one hour. You good story writers is all. I once had a planning last 12 hours because the product management was so awful. If your team sucks, no process will save you.
- joe8756438 10y ago
  Exactly. A good agile, and by extension SCRUM, process allows the developers to influence how things get done. If the way stories are written are leading the team to write unmaintainable code, change the way the stories are written. Or talk about why the problem exists in the first place and take action to fix it. Again, it all comes down to communication. If nobody wants to talk to each other, SCRUM is not going to help. As with all of these posts, they're extremely lacking in alternatives. Of course SCRUM won't work for every team, or even every project for the same team. But it provides a way for the team to evaluate and adjust how to best accomplish their goals in a straightforward and (if done right) low friction way. I think it's taken for granted how much effort is alleviated by adopting SCRUM. Just think how difficult it would be to develop an alternative process for every team, every project, every new person to join one of those teams or projects. Everyone has their own way of doing things, standardizing on a few universal goals aint a bad thing.
gmarx 10y ago
Perhaps but this could be viewed as the "no true scotsman" thing. My main objections to Scrum are a) you need to shoehorn things into user stories that are not naturally expressed that way (as a user I would like all relevant data in the database associated with standard ontology?) b) In a special domain (healthcare) it requires good developers with some level of domain expertise and I find this rare c) (and this is a management issue) people think you can remove important aspects of the methodology (e.g. colocation of resources) and have it still work
- monknomo 10y ago
  I feel like specialized domains in general require devs with domain expertise. Maybe waterfall with unusually good specifications can use cog-like devs, but the few times I've seen that done it didn't turn out very well.
  - gmarx 10y ago
    Agreed
nawitus 10y ago
> Long meeting times with the wrong people in the meeting? That's a managerial issue and has nothing to do with scrum. If scrum tends to lead with long meeting times with the wrong people then scrum certainly should include safeguards against that. Otherwise we need "x+scrum" framework which includes these safeguards. I don't think scrum should fix every problem "in management", but "meeting management" should be a core scrum issue to deal with.
pc86 10y ago
> Long meeting times with the wrong people in the meeting? That's a managerial issue and has nothing to do with scrum. Even with two-week sprints the majority of your last day is entirely meetings between the review and retrospective. In my experience one-month sprints are more common, especially in large enterprises and government, and you will literally have 7 hours of meetings on that final day if you follow the Scrum handbook. Long meetings are built into Scrum.
xorblurb 10y ago
> A story can be written to encourage a developers to improve quality of a codebase, share knowledge with another team, or take time to learn themselves. A really good story would encourage these things and also deliver customer value. Show that to a people unfamiliar with the Scrum church and it will say that sentence is meaningless. And well, it is, in an absolute way. A story is just that: a story. Maybe it can help to put your son to sleep, but I doubt you need to invent a brand new vocabulary to discuss about software architecture and technical debt, and I doubt you can do anything brillant by only using a few examples in a field that is even more driven by pure logic than maths. We are grown up. I don't want to work anywhere where I'm told stories and must get some points done by the end of the week. And this is not anecdotal: Scrum is a derivative of a manufacturing framework. I'm doing engineering.

tootie 10y ago

This is my experience also. Points are complexity and high complexity tasks are most definitely to be addressed by breaking down stories. Dependencies are also easily addressed by setting a Definition of Ready. Don't accept a story if the dependencies aren't met (be that APIs, environments, designs, whatever). Simple. Planning/grooming we do in one hour. You good story writers is all. I once had a planning last 12 hours because the product management was so awful. If your team sucks, no process will save you.

joe8756438 10y ago
Exactly. A good agile, and by extension SCRUM, process allows the developers to influence how things get done. If the way stories are written are leading the team to write unmaintainable code, change the way the stories are written. Or talk about why the problem exists in the first place and take action to fix it. Again, it all comes down to communication. If nobody wants to talk to each other, SCRUM is not going to help. As with all of these posts, they're extremely lacking in alternatives. Of course SCRUM won't work for every team, or even every project for the same team. But it provides a way for the team to evaluate and adjust how to best accomplish their goals in a straightforward and (if done right) low friction way. I think it's taken for granted how much effort is alleviated by adopting SCRUM. Just think how difficult it would be to develop an alternative process for every team, every project, every new person to join one of those teams or projects. Everyone has their own way of doing things, standardizing on a few universal goals aint a bad thing.

gmarx 10y ago

Perhaps but this could be viewed as the "no true scotsman" thing. My main objections to Scrum are a) you need to shoehorn things into user stories that are not naturally expressed that way (as a user I would like all relevant data in the database associated with standard ontology?) b) In a special domain (healthcare) it requires good developers with some level of domain expertise and I find this rare c) (and this is a management issue) people think you can remove important aspects of the methodology (e.g. colocation of resources) and have it still work

monknomo 10y ago
I feel like specialized domains in general require devs with domain expertise. Maybe waterfall with unusually good specifications can use cog-like devs, but the few times I've seen that done it didn't turn out very well.
- gmarx 10y ago
  Agreed

nawitus 10y ago

> Long meeting times with the wrong people in the meeting? That's a managerial issue and has nothing to do with scrum. If scrum tends to lead with long meeting times with the wrong people then scrum certainly should include safeguards against that. Otherwise we need "x+scrum" framework which includes these safeguards. I don't think scrum should fix every problem "in management", but "meeting management" should be a core scrum issue to deal with.

pc86 10y ago

> Long meeting times with the wrong people in the meeting? That's a managerial issue and has nothing to do with scrum. Even with two-week sprints the majority of your last day is entirely meetings between the review and retrospective. In my experience one-month sprints are more common, especially in large enterprises and government, and you will literally have 7 hours of meetings on that final day if you follow the Scrum handbook. Long meetings are built into Scrum.

xorblurb 10y ago

> A story can be written to encourage a developers to improve quality of a codebase, share knowledge with another team, or take time to learn themselves. A really good story would encourage these things and also deliver customer value. Show that to a people unfamiliar with the Scrum church and it will say that sentence is meaningless. And well, it is, in an absolute way. A story is just that: a story. Maybe it can help to put your son to sleep, but I doubt you need to invent a brand new vocabulary to discuss about software architecture and technical debt, and I doubt you can do anything brillant by only using a few examples in a field that is even more driven by pure logic than maths. We are grown up. I don't want to work anywhere where I'm told stories and must get some points done by the end of the week. And this is not anecdotal: Scrum is a derivative of a manufacturing framework. I'm doing engineering.