4 ms·

Meh... All of these items are more or less misinformed so I'm just going to bring up one. > Because all product decision authority rests with the “Product Owne

Meh... All of these items are more or less misinformed so I'm just going to bring up one. > Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction. The product owner is part of the scrum team. She or he is responsible for the backlog but if she has trust in the engineers she can let the engineers add their own things to it. I think OP just works in a bad place.

prepend 8y ago
Right, I felt the same way. I think the accurate title for this post is “Why working for, with, and being an asshole is the wrong way to build software.”
- teunispeters 8y ago
  Oh I'm with that. "Why aren't I getting the attention, focus and control I want?" Especially credit. You get credit in the git logs etc. If you want visibility outside the team go start your own. I have worked in multiple companies that worked very well with this, in several different teams. Or to give a much more serious response : this article seems to be very unprofessional, about trying to defend unprofessional behaviour as "normal".
  - evfanknitram 8y ago
    What kind of 'credit' are you talking about? The scrum guide talks about roughly 1hour/week for the scrum team to show stakeholders (such as upper managers and customers) what has been done. Any engineer can at any time reach out to people in the company to demo what has been created, if there's interest. So I'm not sure what point you're trying to make with starting your own company if you want visibility outside the team.
kasey_junk 8y ago
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 8y 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 8y 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 8y 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 8y ago
I think OP just works in a bad place. Nailed it. My team's product owner is as much part of the team as any of the engineers. Her role includes balancing the need to deliver products with the need to build reliable and scalable software, and to make those arguments to other parts of the company on the team's behalf. Since we're all skilled professionals, we're able to trust each other to make good decisions, and if I say "we cannot proceed until we have done <necessary technical work>" then that is taken seriously and work is prioritised as required. I'm baffled by the awful environments that people apparently work in where this is not the case.
- organicmultiloc 8y ago
  I've never worked at a place where I've been allowed to say no, I think scrum working the way in which you describe is more the exception than the rule.
  - Izkata 8y ago
    The trick that apparently gets lost somewhere along the line is that you don't just say "no", you say "not yet, this first" or "can't, but can do this instead" or... Either give the product owner a reason and a way to work towards what they want, or an alternative that (hopefully) is just as good.
    - PaulRivers 8y ago
      No it's not lost. It gets the same though longer winded results of saying "no". The b.a. product owner complains to your manager that you're not a team player and you get into trouble with your boss. Even if that didn't happen you're never going to win, because the b.a.'s have no other job than playing this verbal judo, while you also have to spend your time getting conplex technical things to work. You're like someone who goes to a karate class twice a werk fighting against someone who's life is dedicated to training.
  - cbsmith 8y ago
    I'm not sure how any methodology would work in such an environment. It isn't the norm for any successful engineering team.

prepend 8y ago

Right, I felt the same way. I think the accurate title for this post is “Why working for, with, and being an asshole is the wrong way to build software.”

teunispeters 8y ago
Oh I'm with that. "Why aren't I getting the attention, focus and control I want?" Especially credit. You get credit in the git logs etc. If you want visibility outside the team go start your own. I have worked in multiple companies that worked very well with this, in several different teams. Or to give a much more serious response : this article seems to be very unprofessional, about trying to defend unprofessional behaviour as "normal".
- evfanknitram 8y ago
  What kind of 'credit' are you talking about? The scrum guide talks about roughly 1hour/week for the scrum team to show stakeholders (such as upper managers and customers) what has been done. Any engineer can at any time reach out to people in the company to demo what has been created, if there's interest. So I'm not sure what point you're trying to make with starting your own company if you want visibility outside the team.

kasey_junk 8y ago

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 8y 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 8y 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 8y 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 8y ago

I think OP just works in a bad place. Nailed it. My team's product owner is as much part of the team as any of the engineers. Her role includes balancing the need to deliver products with the need to build reliable and scalable software, and to make those arguments to other parts of the company on the team's behalf. Since we're all skilled professionals, we're able to trust each other to make good decisions, and if I say "we cannot proceed until we have done <necessary technical work>" then that is taken seriously and work is prioritised as required. I'm baffled by the awful environments that people apparently work in where this is not the case.

organicmultiloc 8y ago
I've never worked at a place where I've been allowed to say no, I think scrum working the way in which you describe is more the exception than the rule.
- Izkata 8y ago
  The trick that apparently gets lost somewhere along the line is that you don't just say "no", you say "not yet, this first" or "can't, but can do this instead" or... Either give the product owner a reason and a way to work towards what they want, or an alternative that (hopefully) is just as good.
  - PaulRivers 8y ago
    No it's not lost. It gets the same though longer winded results of saying "no". The b.a. product owner complains to your manager that you're not a team player and you get into trouble with your boss. Even if that didn't happen you're never going to win, because the b.a.'s have no other job than playing this verbal judo, while you also have to spend your time getting conplex technical things to work. You're like someone who goes to a karate class twice a werk fighting against someone who's life is dedicated to training.
- cbsmith 8y ago
  I'm not sure how any methodology would work in such an environment. It isn't the norm for any successful engineering team.