Hacker News Reader

Comment by vannevar | Hacker News Reader

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them.

How exactly does agile prevent you from talking to your teammates and getting feedback from them?

If I have a full and well-groomed backlog waiting for me at my desk, what's there to talk about? Sure, you can, but the the whole point of the PM is to take that off your shoulders and the parent is saying he doesn't want that lifted from him.

A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.

Sure, but the PM is there for a reason and the PM has roles. There is overlap with what developers can be doing, but we are trained/encouraged to punt to the PM for such decisions, questions, and suggestions.

I get it, but it's now how I do my best work, proxying questions and discussions through a gatekeeper.

We do agile, but also use Slack and email, and walking across the room. If your organization is actively discouraging communication within the team unless it goes through the PM, that's bizarre. On the other hand, if the PM is acting as a gatekeeper with customers, that's not unusual. The reality is that you can't have everyone on the team talking directly to the customer, for a whole host of good reasons.

Regarding decision-making, that can be a problem---some PMs and product owners are micromanagers, hamstringing their team. But they would be micro managers with or without agile.

IME the PM works best when acting as a shield from random questions or future things or other not-important-this-instant distractions, but shouldn't block direct clarifying questions or feedback from you to a stakeholder. I'd keep them in the loop, but the ones I've worked with haven't wanted to just be a glorified "I deal with the goddamn customers so the engineers don't have to!" middleman for basic things like that.

As a tech lead in a Scrum team, this shield causes more problems than it solves in my experience. We often get questions missing context or find out about a decision too late to provide meaningful input on a technical level.

Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.

> Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.

Scrum processes are just a way to ensure that no stakeholder, including team members, is left out of those talks, left in the dark, or left unheard. Having a clique single-handedly and unilaterally dictating changes without communicating them or listening to any stakeholder doesn't serve anyone's interests. That's how projects fail.

A good team knows how and when to share information.

True. Scrum is a floor, not a ceiling. Nothing prevents the team from going above and beyond the daily standup and the sprint review in terms of communication, and I've never been on a team that didn't communicate a lot more than that. But doing that standup every day ensures that there is at least a minimum of communication, every day.

I'm pretty sure that when he says "the rest of the employees" he means what Scrum calls stakeholders, not members of the development team.

Reply on news.ycombinator.com