Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

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.

View on HN

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.

You don't simply say "no" in any workplace.

A well-functioning team is composed of skilled professionals. If you are being asked to do something, it is because someone else has a problem that needs to be solved. "No" is an especially unhelpful response to that scenario. Other approaches can work:

- "No, but how about this alternative idea?"

- "No, this prerequisite is required. How can we make that happen?"

- "Not without causing these other problems – let's decide if it's worth the tradeoff"

- "No, that idea is fundamentally impossible. Here's why."

If you work in an environment where engineers are never listened to, then it's a bad environment. But similarly, engineering requirements are not the only ones, and it's important to realise that quite often an engineer doesn't have all of the required information to make the correct long-term decision.

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.

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.

I'm highly suspicious that every time there is one of these threads, agile-consulting companies simply monitor the web for them and send a bunch of posters over to make up fictional srories about how agile is going great where they work.

I've never been in an environment where you could say no to the b.a.'s under agile either. And I've tried being more articulate as well and that just results in the same claims to your manager as "no" does that you're not being cooperative, a team player, etc.

I'm pretty sure after working several places that did agile that most of these "worked great for me" stories are made up.

I've never met another dev in real life who did something other than agile and preferred agile.

I'm not sure how any methodology would work in such an environment. It isn't the norm for any successful engineering team.

Reply on news.ycombinator.com