4 ms·

Retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience. The concerns are documented but forgotten before the m

Retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience. The concerns are documented but forgotten before the meeting is over. It's as if it's a religious ceremony. It seems that you have to take desperate measures and be very convincing, which shouldn't be necessary in a high trust setting. One shouldn't have to repeat the same things over and over. It's the PO's job to take notes, and if they don't want to act on it, it's their project that will burn. No skin off my back. The best thing I can do is to have it documented once in writing an email, with a Bcc to my own personal address for legal reasons. I shouldn't have to work extra hard to convince someone of what's necessary. I certainly don't get paid enough to do it. It is disrespectful to me, and similarly to you, if the other person is difficult to convince. If the management wants to torpedo the company, it's what is deserved.

dwoldrich 2y ago
> Retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience. Even on the urgent stuff? If the pain is excruciating, coming out of retro, stories get added to stop the bleeding in the following sprint on every Scrum team I've ever been on. Are there never any action items with owners or stories written coming out of retro on your teams? You should try that. > I certainly don't get paid enough to do it. It is disrespectful to me, and similarly to you, if the other person is difficult to convince. Not if your ideas are bad/misguided/counter-productive. Do you know your ideas are good? How do you know? One can't tell if they are misinformed, hallucinating or off the rails. If you can't tell, then your PO and team certainly can't tell, especially on complex problems. So some arguments take time to develop, you sharpen your argument with new data, or maybe the thing you were all worked up was your mind playing tricks. It happens all the time. I think it's very easy to get defensive and angry when it feels like you're losing face in front of your team. Getting pushback is normal, especially when trust is low or resources are sparing. Just keep a cool head and wear down the resistance. It's not losing face if you are always acting in good faith when discussing issues you want to see addressed on the project. You're actually stronger in the team's eyes if show commitment to the team even after embarrassments. You're not a robot and you'll make lots of mistakes.
- OutOfHere 2y ago
  > stories get added You must be new to this. Even when stories get added, they never get prioritized, and just sit in the backlog forever. > sharpen your argument with new data Why should I care. If they want me to present ten times the necessary evidence, it is not me who is at fault. I have to cover my liability, which is to document the issue in writing, with proof that I documented it. Beyond that, there is no reason for me to care if the project or company perishes. It would in fact be better for the company to perish if they don't pay attention to what is said. These are structural problems that for some reason you can't seem to get your head around. They require a structural solution. The current structure is one of deception, of deceiving others up and down the chain, as well as oneself. Also, "wearing down the resistance" is what toddlers do to their caretakers. If I was getting paid a million dollars, I'd put up more of a prolonged argument, but I am not.
  - dwoldrich 2y ago
    But why should anyone your team and the Product Owner form a consensus around your ideas? Maybe all of your ideas and your approach to work stinks. Specifically: how do you know your ideas are correct and not hallucinations or misinformed when you get grumpy that no one listens to or respects you?
    - shrimp_emoji 2y ago
      [dead]
    - OutOfHere 2y ago
      I am really not saying they should, but it would help if they did because the project fails after a year due to the overwhelming burden of the disorganized legacy. Note that it's not just me on the project; it's also a lot of other non-senior team members that aren't really capable of handling the legacy without introducing serious bugs. You're thinking in an over-constrained framework where there are just two choices -- either to form a consensus or to reject the ideas. If instead you take a higher view, you will see that giving senior engineers ownership and freedom allows the management to see if the engineers sink or swim. The technical lessons will then be more apparent.

dwoldrich 2y ago

> Retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience. Even on the urgent stuff? If the pain is excruciating, coming out of retro, stories get added to stop the bleeding in the following sprint on every Scrum team I've ever been on. Are there never any action items with owners or stories written coming out of retro on your teams? You should try that. > I certainly don't get paid enough to do it. It is disrespectful to me, and similarly to you, if the other person is difficult to convince. Not if your ideas are bad/misguided/counter-productive. Do you know your ideas are good? How do you know? One can't tell if they are misinformed, hallucinating or off the rails. If you can't tell, then your PO and team certainly can't tell, especially on complex problems. So some arguments take time to develop, you sharpen your argument with new data, or maybe the thing you were all worked up was your mind playing tricks. It happens all the time. I think it's very easy to get defensive and angry when it feels like you're losing face in front of your team. Getting pushback is normal, especially when trust is low or resources are sparing. Just keep a cool head and wear down the resistance. It's not losing face if you are always acting in good faith when discussing issues you want to see addressed on the project. You're actually stronger in the team's eyes if show commitment to the team even after embarrassments. You're not a robot and you'll make lots of mistakes.

OutOfHere 2y ago
> stories get added You must be new to this. Even when stories get added, they never get prioritized, and just sit in the backlog forever. > sharpen your argument with new data Why should I care. If they want me to present ten times the necessary evidence, it is not me who is at fault. I have to cover my liability, which is to document the issue in writing, with proof that I documented it. Beyond that, there is no reason for me to care if the project or company perishes. It would in fact be better for the company to perish if they don't pay attention to what is said. These are structural problems that for some reason you can't seem to get your head around. They require a structural solution. The current structure is one of deception, of deceiving others up and down the chain, as well as oneself. Also, "wearing down the resistance" is what toddlers do to their caretakers. If I was getting paid a million dollars, I'd put up more of a prolonged argument, but I am not.
- dwoldrich 2y ago
  But why should anyone your team and the Product Owner form a consensus around your ideas? Maybe all of your ideas and your approach to work stinks. Specifically: how do you know your ideas are correct and not hallucinations or misinformed when you get grumpy that no one listens to or respects you?
  - shrimp_emoji 2y ago
    [dead]
  - OutOfHere 2y ago
    I am really not saying they should, but it would help if they did because the project fails after a year due to the overwhelming burden of the disorganized legacy. Note that it's not just me on the project; it's also a lot of other non-senior team members that aren't really capable of handling the legacy without introducing serious bugs. You're thinking in an over-constrained framework where there are just two choices -- either to form a consensus or to reject the ideas. If instead you take a higher view, you will see that giving senior engineers ownership and freedom allows the management to see if the engineers sink or swim. The technical lessons will then be more apparent.