Comment by amarkov | Hacker News Reader

Comment by amarkov | Hacker News Reader

Respectfully, I'm not sure the author understands what he's talking about. He's arguing for the no-op process where engineers determine all their own tasks and priorities - and I mean, I'd like that too. But there's a fundamental difficulty in aligning each engineer's personal goals with those of the company, and some amount of management or organizational design has to go towards addressing it. Engineers won't just naturally align with the organization if nobody rewards us for doing so.

> Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on?

> Are they required to present burn down charts that show that they are on target to finish?

> Are they required to do bi-weekly sell-off meeting to justify their activities?

These things are in fact the primary responsibilities of managers and product owners.

Engineers won't just naturally align with the organization if nobody rewards us for doing so.

Hoes does Scrum reward the engineer for such alignment?

edit: grammar

Theoretically, Scrum is a way to say 'work on this, because it's what aligns with the organization'. But, of course, whether it really does or not depends on who is implementing it and how.

Scrum telling you how to align with the organization is not rewarding the engineer in any way. Orthogonal concerns.

How does Scrum reward the engineer, in a way that it does it better, and more profoundly, than other methodologies?

When you let engineers run around doing our own thing, we never have to show that the work we're doing is the most productive use of company time. We just have to show that it plausibly could be. Nobody will hesitate to reward the well-liked engineer with a cool sounding project, even if other things would really be more important.

As the author noted, Scrum solves this problem by making number of story points completed the primary tool for a team to measure its productivity. If the cool-sounding project isn't important enough to take other items out of the sprint, there's no way to offer a post-hoc justification for doing it anyway. It has no story points, so work on it is considered non-productive.

It makes it pretty easy for an engineer to understand what is needed to achieve success, communicate about obstacles in order to get assistance, and have transparency about how their work fits into the larger organization.

Reply on news.ycombinator.com