4 ms·

If OP worked in a “good” place where product managers & engineers trust each other to do those tasks, what value does Scrum bring? The process is there to acco

If OP worked in a “good” place where product managers & engineers trust each other to do those tasks, what value does Scrum bring? The process is there to account for the places where the people fail. If a requirement of a process is unfailing people then it’s not a valuable process.

evfanknitram 9y ago
Not sure if you are joking but unfailing people is no requirement of scrum. Scrum requires the people participating in the process to at least have some fundamental grasp of the process though. If the actors can't be bothered to learn this, then of course it won't work. If you don't know what values scrum brings over for example traditional waterfall, then the scrum handbook is a good place to start to learn.
- kasey_junk 9y ago
  I've worked on agile projects for 20 years. I was using agile before the manifesto was published. The opposite of 'not scrum' is not 'waterfall'. Further, I don't disagree with anything Ken Schwaber outlines in his writings on scrum. The problem is, on the ground, that is not what scrum is. Ken has been fighting that battle for at least 10 years. If the process is just as often implemented incorrectly as correctly, that is a failing of the process. And in this case that is the most damning thing you can say about scrum. More often than not, people do it wrong. I'm tired of that excuse.
  - evfanknitram 9y ago
    > The problem is, on the ground, that is not what scrum is. The companies I have worked on who claim to use scrum does not suffer from the issues OP brought up. So I question your statement. I also have >20 years experience. > If the process is just as often implemented incorrectly as correctly, that is a failing of the process. That's bs. That would be like putting a tractor driver in a Cessna and when the plane crash clamr that Cessnas are inherently unsafe to use. Yes, scrum requires buy in and some basic level of competence. If one or both of these are missing in an organization and they still say they use scrum then that can hardly be blamed on scrum.
matthewmacleod 9y ago
The process is there to account for the places where the people fail That's just wrong. It's there for lots of reasons – to help avoid failures and surprises, to deliver sustainable pace, to help make estimations, to ensure a common understanding of problems and challenges… the list goes on. Scrum doesn't require infallible people – it's just a tool to help avoid failures, which happen regardless of the skill of your team.
- kasey_junk 9y ago
  I’ve not found that to be the case. In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them. I’ve seen instances of all of the items the article claims being problems in practice. That was across a wide variety of teams & skill levels. I’ve also seen no evidence in the literature or research that backs up your assertions. I’ll concede some teams have benefited from scrum practices, but in the face of my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business. I’m certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn’t seen “real” scrum.
  - matthewmacleod 9y ago
    In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them. Why was Scrum added to these teams if they were already working? It's a tool to deal with problems. It's not something to use if another process is already working. I’ve seen instances of all of the items the article claims being problems in practice. I have found essentially the exact opposite of all the problems that are claimed to exist, and I've equally seen no research to confirm that they somehow destroy teams. my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business My experience directly contradicts that. Every Scrum-ish team I've worked with has had a pretty steady pace of development and produced good software. Some other processes have worked too; the worst I've seen are fake-agile-actually-waterfall processes. I’m certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn’t seen “real” scrum. There's no such thing as 'real Scrum' so I won't use that defence. A good process is one that works for the team and company. Scrum is not a universal solution; for extremely high-performing teams it's probably overkill; for bureaucratic teams it will crush everything. It's just another good tool to use where appropriate.

evfanknitram 9y ago

Not sure if you are joking but unfailing people is no requirement of scrum. Scrum requires the people participating in the process to at least have some fundamental grasp of the process though. If the actors can't be bothered to learn this, then of course it won't work. If you don't know what values scrum brings over for example traditional waterfall, then the scrum handbook is a good place to start to learn.

kasey_junk 9y ago
I've worked on agile projects for 20 years. I was using agile before the manifesto was published. The opposite of 'not scrum' is not 'waterfall'. Further, I don't disagree with anything Ken Schwaber outlines in his writings on scrum. The problem is, on the ground, that is not what scrum is. Ken has been fighting that battle for at least 10 years. If the process is just as often implemented incorrectly as correctly, that is a failing of the process. And in this case that is the most damning thing you can say about scrum. More often than not, people do it wrong. I'm tired of that excuse.
- evfanknitram 9y ago
  > The problem is, on the ground, that is not what scrum is. The companies I have worked on who claim to use scrum does not suffer from the issues OP brought up. So I question your statement. I also have >20 years experience. > If the process is just as often implemented incorrectly as correctly, that is a failing of the process. That's bs. That would be like putting a tractor driver in a Cessna and when the plane crash clamr that Cessnas are inherently unsafe to use. Yes, scrum requires buy in and some basic level of competence. If one or both of these are missing in an organization and they still say they use scrum then that can hardly be blamed on scrum.

matthewmacleod 9y ago

The process is there to account for the places where the people fail That's just wrong. It's there for lots of reasons – to help avoid failures and surprises, to deliver sustainable pace, to help make estimations, to ensure a common understanding of problems and challenges… the list goes on. Scrum doesn't require infallible people – it's just a tool to help avoid failures, which happen regardless of the skill of your team.

kasey_junk 9y ago
I’ve not found that to be the case. In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them. I’ve seen instances of all of the items the article claims being problems in practice. That was across a wide variety of teams & skill levels. I’ve also seen no evidence in the literature or research that backs up your assertions. I’ll concede some teams have benefited from scrum practices, but in the face of my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business. I’m certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn’t seen “real” scrum.
- matthewmacleod 9y ago
  In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them. Why was Scrum added to these teams if they were already working? It's a tool to deal with problems. It's not something to use if another process is already working. I’ve seen instances of all of the items the article claims being problems in practice. I have found essentially the exact opposite of all the problems that are claimed to exist, and I've equally seen no research to confirm that they somehow destroy teams. my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business My experience directly contradicts that. Every Scrum-ish team I've worked with has had a pretty steady pace of development and produced good software. Some other processes have worked too; the worst I've seen are fake-agile-actually-waterfall processes. I’m certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn’t seen “real” scrum. There's no such thing as 'real Scrum' so I won't use that defence. A good process is one that works for the team and company. Scrum is not a universal solution; for extremely high-performing teams it's probably overkill; for bureaucratic teams it will crush everything. It's just another good tool to use where appropriate.