3 ms·

> Retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience. Even on the urgent stuff? If the pain is excruciat

> 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
    > it would help if they did because the project fails after a year due to the overwhelming burden of the disorganized legacy It's always someone else's fault with you. It's always someone else's goof. It's a mystery why no one listens to you. Over a full year of disorganization where you are a powerless contributor and a non-lazy victim and those unfair tyrants deserve to crumple and fail at the end of it? I'm not buying what you're selling, hyperbole or not. To answer my own questions: There is no mechanism to self-check your cognition for viability. Only other people (the team) can check your ideas in the moment with agreed-upon evidence/track record as a long-term proof. Because you need others to validate your strategies and designs, which are likely flawed, you need to work harmoniously with others. Therefore, you need to ingratiate yourself to them and respect them so you can influence them and you'll eventually get your way with the team if you're any good. It's called being a team player.

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
  > it would help if they did because the project fails after a year due to the overwhelming burden of the disorganized legacy It's always someone else's fault with you. It's always someone else's goof. It's a mystery why no one listens to you. Over a full year of disorganization where you are a powerless contributor and a non-lazy victim and those unfair tyrants deserve to crumple and fail at the end of it? I'm not buying what you're selling, hyperbole or not. To answer my own questions: There is no mechanism to self-check your cognition for viability. Only other people (the team) can check your ideas in the moment with agreed-upon evidence/track record as a long-term proof. Because you need others to validate your strategies and designs, which are likely flawed, you need to work harmoniously with others. Therefore, you need to ingratiate yourself to them and respect them so you can influence them and you'll eventually get your way with the team if you're any good. It's called being a team player.