4 ms·

I don't know the author, but these complaints about ownership make me worry if they are not a team player. By "not a team player", I mean they can't easily sub

I don't know the author, but these complaints about ownership make me worry if they are not a team player. By "not a team player", I mean they can't easily subordinate themselves to the rest of the team's consensus, to the enterprise culture/standards, to the limitations of the legacy codebase, to their product owner's direction, or to the laws of physics. This programming stuff takes humility, and everything is hard to do. Non-team players make everything harder with the friction they add to every decision and the morale drain they put on the rest of the team with their sourpuss nature. I try to win these folks over with love and help them to add many small wins to their name, but they're often energy monsters and they quickly exhaust me. It's often a relief when they remove themselves from the team.

fmbb 2y ago
I don’t understand how you get from someone critiquing company ownership to believing they cannot play nice with consensus or be humble. There is no relation there.
- cauch 2y ago
  I think the link is that it is not at all uncommon to see someone who cannot play nice with consensus or be humble to blame everything on the company ownership. It is possible there is a company ownership problem sometimes. But the article conclusions seem to be presented to be valid all the time. I too had this impression reading the article. I would not have had this impression if the article was also mentioning that maybe sometimes a bad scrum implementation is the result of the software developers wanting to control everything while being uneducated on all the aspects that are slightly outside of their narrow field of expertise. This is common enough that there is a term for that: "engineer's disease", and that it was illustrated by a xkcd comic strip (1570)
- dwoldrich 2y ago
  Here's how I got there. Author doesn't like the way decisions are made so they think they should be the decision-maker. The team is supposed to make the decisions in Scrum. So, I feared that in reality, they're just not a team player and feeling a little powerless in that dynamic given all the pushback they may be experiencing. The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes. The Scrum Master is supposed to be the unblocker and master of ceremonies. In my opinion, the best SM arrangement is as a rotating role for analysts/developers on the team rather than a dedicated position. The Scrum Master needs to be involved with the actual work to understand what a blocker is. Rotating SM is actually becoming more common in the industry, as I understand it. The ideal Product Owner is the one neck to choke on the team for failure. The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Obviously, there are less-than-ideal PO's, and we can lament and complain about that separately, but author needs to better understand what a PO is in Scrum. I wonder if they think a Project Manager is the same thing as a Product Owner.
  - ath3nd 2y ago
    > The Scrum Master is supposed to be the unblocker and master of ceremonies. How about we throw the ceremonies AND the scrum master (and scrum along with it) out of the window and treat the developers like grown ups that can actually unblock themselves? How about we treat all the devs, all the time, like people who know how to say they are stuck, need help, or how to say NO? Why need to infantilize them? > The Scrum Master needs to be involved with the actual work to understand what a blocker is Wow, that means...literally every dev can be a scrum master. So, should the devs that are currently not the Scrum master suddenly lose their unblocking capability and sit around hopelessly while Scrum hero solves the bottleneck for them? > The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Oh, poor devs, needing a buffer, and somebody to tell them what the Business (capital letter, like the Church, cause it's an institution) wants. It's not like they can go and ask, god forbid a developer talks to a Business person directly. The outrage! > The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes. The author has a very substantiated gripes with both roles, as both the author and me (and many others) view these roles as useless management cruft. And the PO has to also be a subject matter expert, wow! They must have studied hard in the Subject Matter school (1 week online course) to acquire such skills! Wanna hear about my revolutionary idea? A development team consisting of...developers.
    - dwoldrich 2y ago
      I don't understand your hostility. Are my opinions hostile to you? I'm sorry if they were. I'm just sharing what I've learned. > Wow, that means...literally every dev can be a scrum master. Yes. And that's why if you take the training as a developer, you get "Certified Scrum Master" training. If you would stop trying to gotcha me, you would see this is an potential area of agreement between us. I don't think you have a proper sense for what a 'blocker' is in the context of Scrum. In a normal workplace and well-functioning team, blockers are few and far between so the SM shouldn't need to engage all that often anyways. Not all problems we encounter in the workplace are in code. Scrum has roles to own and manage the different kinds of problems. Scrum is also a flat hierarchy, it's fairly minimal. You're supposed to make things as simple as possible, but no simpler. I think you're over-simplifying. The 'Business' is capitalized because of English, but feel free to read my words with business all lowercase. I don't worship any man, bad look. Product Owners need to be subject matter experts or at least SME's in training. In my experience lead developers who try to also wear the PO hat sometimes have trouble getting their heads out of the minutae. If you have seen the opposite in your experience, then lucky you. > Wanna hear about my revolutionary idea? A development team consisting of...developers. When you get to know types of folks other than coders, you get to appreciate how they make important contributions to the project. I think you were trying to smash home a point here, but the world is bigger and more interesting than what you wish it was.
AnimalMuppet 2y ago
OK, but... The scrum people can also be non-team-players by not subordinating themselves to the team's consensus on appropriate methodology and level of ceremony. That adds friction, too. It's just that, since it's the "team players" pushing scrum, it's not obvious that they are in fact not team players. They're running over the team with their vision of teamwork, but they're not actually listening to the team protesting that it doesn't fit.
- dwoldrich 2y ago
  The "scrum people" you refer to are supposed to be the team itself, so it sounds like you're describing some scrummerfall-type organization. I agree ceremony would be largely meaningless and worthy of scorn in such a place. Can you describe a scenario you were involved with where these other people weren't listening to the team's protestations, or were you just giving a hypothetical? My favorite ceremony in Scrum is the retrospective because that's where we get to factor protests and pains into our backlog.
  - AnimalMuppet 2y ago
    I meant the Scrum Master. I personally have never experienced scrum done badly. But I'm pretty sure that there are people here who can give you plenty of examples.
    - dwoldrich 2y ago
      Thanks for being honest. Scrum is not a panacea, it's a form of agile that even big globo-corpo can appreciate and that's why it's so widely deployed. Low cost certifications and copy-cat'ism. If you run Scrum the way it's trained, it is only effective at directing the people and planning. The developers need to ensure that non-functional requirements around code quality, all the -ilities really, are factored into the work that the team does - you do NOT get that with Scrum. This is my biggest complaint about Scrum is its utter silence on development standards. It is important as developers that we establish what our standards are and hold ourselves to those standards. You could say that the place for that in Scrum is the Team Working Agreement (like house rules), but again, there's no guidance that "Developers shall define the standard of quality for their work products...", etc. https://www.scrum.org/resources/creating-team-working-agreement https://www.scrum.org/resources/creating-team-working-agreem... To be honest, topics like software testing don't real attention with any methodology other than eXtreme Programming, AFAIK.
OutOfHere 2y ago
When everyone is responsible for a project, when everyone owns it, it means that no one is responsible for it, that no one owns it, and therefore it is doomed to fail with about a 95% probability. As for the "product owner", they only control direction, and they are not actually vested in the success of the project beyond their immediate direction.
- dwoldrich 2y ago
  No, please read: https://www.scrum.org/resources/what-is-a-product-owner https://www.scrum.org/resources/what-is-a-product-owner
  - OutOfHere 2y ago
    I have worked with product owners. They categorically refuse all proposed refactoring work that developers find necessary. As a result, the project keeps piling on so much tech debt that it's doomed after two to three years. Moreover, they never suffer the consequences.
    - dwoldrich 2y ago
      Sounds like a retro topic. Real life isn't Dilbert, but I can see how we fall into its tropes. Ultimately, you're a professional, and shipping crap code is unprofessional. But when you inherited 90% legacy code, it's not like your team can instantly go to shipping non-crap. So, there has to be a gradual improvement in the team as you get the codebase under control. This is why retrospectives are my favorite Scrum meeting because I get to air my grievances in a constructive, supportive way where I secure action items for the next sprint for what I want done and backlog items for the future. If I am being told by my Product Owner I can't address tech debt, then I absolutely hammer home details in the retro when that tech debt bites us. And every single sprint, I will say the same things over and over, each time ratcheting up the severity, polite but firm. I get to say things like, "this is hurting our velocity, we are firefighting constantly, build times are ridiculous, we need to be logging more", etc. Ultimately, even sociopaths get tired of hearing the repetition. So they give you a story to go fix some tech debt. Let me tell you from experience, you had better KNOCK that first tech debt story out of the park. And, it had better be a story you can measure for awesomeness. "Weekly Saturday morning outage abated for first time in months", that kind of thing. You need to proclaim your team's success in improving things to whoever will listen in the organization to make the wins public. This is how you gain trust and get the next tech debt story to work on, positive reinforcement. Your story makes me sad though. It could mean that your PO didn't trust your team because maybe your system was fragile and every time you guys tried to fix things, it turned into a boondoggle. Not trying to insult you, I don't know your story, maybe your PO was a tyrant. I'm just relating learnings from my own past experiences that might apply to you. Like, if any developer on your team ever says in a team meeting "we don't know what's going wrong", the trust level goes down a peg and some PO's will immediately start to panic or die inside. You can't blame a PO for acting irrational or cold to the team after that happens. All I know is, every story you do in those low trust situations with regards to tech debt needs to be a win, it should be bite-sized with high confidence levels before you agree to take on the story. No big bang releasing anything. Always gain more confidence.

fmbb 2y ago

I don’t understand how you get from someone critiquing company ownership to believing they cannot play nice with consensus or be humble. There is no relation there.

cauch 2y ago
I think the link is that it is not at all uncommon to see someone who cannot play nice with consensus or be humble to blame everything on the company ownership. It is possible there is a company ownership problem sometimes. But the article conclusions seem to be presented to be valid all the time. I too had this impression reading the article. I would not have had this impression if the article was also mentioning that maybe sometimes a bad scrum implementation is the result of the software developers wanting to control everything while being uneducated on all the aspects that are slightly outside of their narrow field of expertise. This is common enough that there is a term for that: "engineer's disease", and that it was illustrated by a xkcd comic strip (1570)
dwoldrich 2y ago
Here's how I got there. Author doesn't like the way decisions are made so they think they should be the decision-maker. The team is supposed to make the decisions in Scrum. So, I feared that in reality, they're just not a team player and feeling a little powerless in that dynamic given all the pushback they may be experiencing. The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes. The Scrum Master is supposed to be the unblocker and master of ceremonies. In my opinion, the best SM arrangement is as a rotating role for analysts/developers on the team rather than a dedicated position. The Scrum Master needs to be involved with the actual work to understand what a blocker is. Rotating SM is actually becoming more common in the industry, as I understand it. The ideal Product Owner is the one neck to choke on the team for failure. The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Obviously, there are less-than-ideal PO's, and we can lament and complain about that separately, but author needs to better understand what a PO is in Scrum. I wonder if they think a Project Manager is the same thing as a Product Owner.
- ath3nd 2y ago
  > The Scrum Master is supposed to be the unblocker and master of ceremonies. How about we throw the ceremonies AND the scrum master (and scrum along with it) out of the window and treat the developers like grown ups that can actually unblock themselves? How about we treat all the devs, all the time, like people who know how to say they are stuck, need help, or how to say NO? Why need to infantilize them? > The Scrum Master needs to be involved with the actual work to understand what a blocker is Wow, that means...literally every dev can be a scrum master. So, should the devs that are currently not the Scrum master suddenly lose their unblocking capability and sit around hopelessly while Scrum hero solves the bottleneck for them? > The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Oh, poor devs, needing a buffer, and somebody to tell them what the Business (capital letter, like the Church, cause it's an institution) wants. It's not like they can go and ask, god forbid a developer talks to a Business person directly. The outrage! > The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes. The author has a very substantiated gripes with both roles, as both the author and me (and many others) view these roles as useless management cruft. And the PO has to also be a subject matter expert, wow! They must have studied hard in the Subject Matter school (1 week online course) to acquire such skills! Wanna hear about my revolutionary idea? A development team consisting of...developers.
  - dwoldrich 2y ago
    I don't understand your hostility. Are my opinions hostile to you? I'm sorry if they were. I'm just sharing what I've learned. > Wow, that means...literally every dev can be a scrum master. Yes. And that's why if you take the training as a developer, you get "Certified Scrum Master" training. If you would stop trying to gotcha me, you would see this is an potential area of agreement between us. I don't think you have a proper sense for what a 'blocker' is in the context of Scrum. In a normal workplace and well-functioning team, blockers are few and far between so the SM shouldn't need to engage all that often anyways. Not all problems we encounter in the workplace are in code. Scrum has roles to own and manage the different kinds of problems. Scrum is also a flat hierarchy, it's fairly minimal. You're supposed to make things as simple as possible, but no simpler. I think you're over-simplifying. The 'Business' is capitalized because of English, but feel free to read my words with business all lowercase. I don't worship any man, bad look. Product Owners need to be subject matter experts or at least SME's in training. In my experience lead developers who try to also wear the PO hat sometimes have trouble getting their heads out of the minutae. If you have seen the opposite in your experience, then lucky you. > Wanna hear about my revolutionary idea? A development team consisting of...developers. When you get to know types of folks other than coders, you get to appreciate how they make important contributions to the project. I think you were trying to smash home a point here, but the world is bigger and more interesting than what you wish it was.

AnimalMuppet 2y ago

OK, but... The scrum people can also be non-team-players by not subordinating themselves to the team's consensus on appropriate methodology and level of ceremony. That adds friction, too. It's just that, since it's the "team players" pushing scrum, it's not obvious that they are in fact not team players. They're running over the team with their vision of teamwork, but they're not actually listening to the team protesting that it doesn't fit.

dwoldrich 2y ago
The "scrum people" you refer to are supposed to be the team itself, so it sounds like you're describing some scrummerfall-type organization. I agree ceremony would be largely meaningless and worthy of scorn in such a place. Can you describe a scenario you were involved with where these other people weren't listening to the team's protestations, or were you just giving a hypothetical? My favorite ceremony in Scrum is the retrospective because that's where we get to factor protests and pains into our backlog.
- AnimalMuppet 2y ago
  I meant the Scrum Master. I personally have never experienced scrum done badly. But I'm pretty sure that there are people here who can give you plenty of examples.
  - dwoldrich 2y ago
    Thanks for being honest. Scrum is not a panacea, it's a form of agile that even big globo-corpo can appreciate and that's why it's so widely deployed. Low cost certifications and copy-cat'ism. If you run Scrum the way it's trained, it is only effective at directing the people and planning. The developers need to ensure that non-functional requirements around code quality, all the -ilities really, are factored into the work that the team does - you do NOT get that with Scrum. This is my biggest complaint about Scrum is its utter silence on development standards. It is important as developers that we establish what our standards are and hold ourselves to those standards. You could say that the place for that in Scrum is the Team Working Agreement (like house rules), but again, there's no guidance that "Developers shall define the standard of quality for their work products...", etc. https://www.scrum.org/resources/creating-team-working-agreement https://www.scrum.org/resources/creating-team-working-agreem... To be honest, topics like software testing don't real attention with any methodology other than eXtreme Programming, AFAIK.

OutOfHere 2y ago

When everyone is responsible for a project, when everyone owns it, it means that no one is responsible for it, that no one owns it, and therefore it is doomed to fail with about a 95% probability. As for the "product owner", they only control direction, and they are not actually vested in the success of the project beyond their immediate direction.

dwoldrich 2y ago
No, please read: https://www.scrum.org/resources/what-is-a-product-owner https://www.scrum.org/resources/what-is-a-product-owner
- OutOfHere 2y ago
  I have worked with product owners. They categorically refuse all proposed refactoring work that developers find necessary. As a result, the project keeps piling on so much tech debt that it's doomed after two to three years. Moreover, they never suffer the consequences.
  - dwoldrich 2y ago
    Sounds like a retro topic. Real life isn't Dilbert, but I can see how we fall into its tropes. Ultimately, you're a professional, and shipping crap code is unprofessional. But when you inherited 90% legacy code, it's not like your team can instantly go to shipping non-crap. So, there has to be a gradual improvement in the team as you get the codebase under control. This is why retrospectives are my favorite Scrum meeting because I get to air my grievances in a constructive, supportive way where I secure action items for the next sprint for what I want done and backlog items for the future. If I am being told by my Product Owner I can't address tech debt, then I absolutely hammer home details in the retro when that tech debt bites us. And every single sprint, I will say the same things over and over, each time ratcheting up the severity, polite but firm. I get to say things like, "this is hurting our velocity, we are firefighting constantly, build times are ridiculous, we need to be logging more", etc. Ultimately, even sociopaths get tired of hearing the repetition. So they give you a story to go fix some tech debt. Let me tell you from experience, you had better KNOCK that first tech debt story out of the park. And, it had better be a story you can measure for awesomeness. "Weekly Saturday morning outage abated for first time in months", that kind of thing. You need to proclaim your team's success in improving things to whoever will listen in the organization to make the wins public. This is how you gain trust and get the next tech debt story to work on, positive reinforcement. Your story makes me sad though. It could mean that your PO didn't trust your team because maybe your system was fragile and every time you guys tried to fix things, it turned into a boondoggle. Not trying to insult you, I don't know your story, maybe your PO was a tyrant. I'm just relating learnings from my own past experiences that might apply to you. Like, if any developer on your team ever says in a team meeting "we don't know what's going wrong", the trust level goes down a peg and some PO's will immediately start to panic or die inside. You can't blame a PO for acting irrational or cold to the team after that happens. All I know is, every story you do in those low trust situations with regards to tech debt needs to be a win, it should be bite-sized with high confidence levels before you agree to take on the story. No big bang releasing anything. Always gain more confidence.