Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Great engineering teams focus on milestones instead of projects

rubick.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Great engineering teams focus on milestones instead of projects

#51

Post by andruby »

xedrac wrote: post #40

> Estimating one to three weeks of work is easy So a slightly more flexible sprint? I personally hate sprints - they tend to be inflexible and sometimes force you to make the wrong compromises. They are typically filled with many disparate tasks that often require you to context switch back and forth repeatedly. If you under estimate the time some tasks take, the numbers paint you as a weak performer. Those who game…

That’s exactly why I prefer a more kanban-inspired flow. We discuss new tickets weekly, estimate them with planning poker [0] and move some to “in focus”. We have WIP limits on focus, doing and for-review to limit the max concurrency and encourage pairing.

Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed.

[0] http://pokershirt.io

Re: Great engineering teams focus on milestones instead of projects

#52

Post by sovietmudkipz »

blackoil wrote: post #46
xedrac wrote: post #40

> Estimating one to three weeks of work is easy So a slightly more flexible sprint? I personally hate sprints - they tend to be inflexible and sometimes force you to make the wrong compromises. They are typically filled with many disparate tasks that often require you to context switch back and forth repeatedly. If you under estimate the time some tasks take, the numbers paint you as a weak performer. Those who game…

The problem with Sprints is that they come with fixed events and associated ceremonies. If your 2 week task is slipping by 2 days you have to answer why in the retrospective. If you remove the sprint deadlines and make the retrospective etc. adhoc and mostly dev team initiated it takes away all the pressure while keeping monitoring/measurements.

That system of ad hoc meetings probably works for a team who works well together. Any system can work for a team that works well together.

My team tried ad hoc meetings. We wound up not having the meetings. We now just stick to the sprint schedule, at the behest of our manager.

Re: Great engineering teams focus on milestones instead of projects

#53

Post by nickforr »

yodon wrote: post #30
ec109685 wrote: post #27

Earlier quoted context omitted.

Why should that responsibility solely come from the product manager? Are devs incapable of their own good ideas if given a chance to understand the customer as well? The product manager should be the overall decider, but the best products do not germinate out of a single person’s head.

The person you're responding to is not advocating that ideas are the responsibility of the PM, nor are they saying the PM should be the overall decider. They are saying the PM is responsible for collecting information from the customer and bringing that information to the team in an efficient manner so the team can make decisions based on that information. If the PM brings incorrect or inadequate information, the res…

How does the PM know better than devs about whether or not they’re bringing the right information and not inadvertently summarising something incorrectly that’s technically important? Gatekeepers are generally inefficient longer-term.

Re: Great engineering teams focus on milestones instead of projects

#54

Post by geertj »

ec109685 wrote: post #27
arcbyte wrote: post #21

Earlier quoted context omitted.

Your job as a product owner, as it relates to developers, is to be the customer so we dont have to waste time in phone tag. That meana you have to get inside the customers head and figure out what they want better than they know it and to take accountability when the team built what you thought the customer wanted but you fucked it up.

Why should that responsibility solely come from the product manager? Are devs incapable of their own good ideas if given a chance to understand the customer as well? The product manager should be the overall decider, but the best products do not germinate out of a single person’s head.

> Why should that responsibility solely come from the product manager?

It should not, but the PM is accountable. GP put it nicely, effective PMs know better what customers want than customers themselves. This keeps iterations fast as PMs can immediately answer questions on trade offs instead of going back to the customers (who don’t know).

Re: Great engineering teams focus on milestones instead of projects

#56

Post by A_non_e-moose »

onlyrealcuzzo wrote: post #41
xedrac wrote: post #40

> Estimating one to three weeks of work is easy So a slightly more flexible sprint? I personally hate sprints - they tend to be inflexible and sometimes force you to make the wrong compromises. They are typically filled with many disparate tasks that often require you to context switch back and forth repeatedly. If you under estimate the time some tasks take, the numbers paint you as a weak performer. Those who game…

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

> If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts.

Which assumptions are behind that statement?

Does the team have uniform experience working in a single product? That statement feels more applicable here.

Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.

Re: Great engineering teams focus on milestones instead of projects

#57

Post by tomwojcik »

vanusa wrote: post #35
faangiq wrote: post #28

Great engineering teams have great engineers. Nothing else matters.

The history of the industry is littered with the carcasses of counterexamples. A great team is defined by what it actually, in fact, creates (which is determined by many factors). Not by the sum of the potentials of its contributors.

That's an interesting point, but I'd say you cant really compare the greatness of a project if its a different industry for example Saas, social media, Indie game but you can compare teams that created these products.

Re: Great engineering teams focus on milestones instead of projects

#58

Post by _y5hn »

vanusa wrote: post #35
faangiq wrote: post #28

Great engineering teams have great engineers. Nothing else matters.

The history of the industry is littered with the carcasses of counterexamples. A great team is defined by what it actually, in fact, creates (which is determined by many factors). Not by the sum of the potentials of its contributors.

Even for FOSS, teams actually have to market, sell and maintain their product too. Doesn't matter if you built the greatest thing ever if nobody knows about it or recommends it. Often, organic growth just can't beat the competition, especially if you want to make money.

Re: Great engineering teams focus on milestones instead of projects

#59

Post by arcbyte »

nickforr wrote: post #53
yodon wrote: post #30

Earlier quoted context omitted.

The person you're responding to is not advocating that ideas are the responsibility of the PM, nor are they saying the PM should be the overall decider. They are saying the PM is responsible for collecting information from the customer and bringing that information to the team in an efficient manner so the team can make decisions based on that information. If the PM brings incorrect or inadequate information, the res…

How does the PM know better than devs about whether or not they’re bringing the right information and not inadvertently summarising something incorrectly that’s technically important? Gatekeepers are generally inefficient longer-term.

You're attributing gatekeeping to the wrong place here. The customer is the gate and the customer's unavailability is keeping the gate shut.

The PO reduces that inadvertent gatekeeping by being always available with customer insights so the devs don't twiddle their thumbs or worse, build thr wrong thing, because they were guessing what the customer wanted in the absence of actually talking to them.

The PO reduces gatekeeping because they are an always available customer.

Re: Great engineering teams focus on milestones instead of projects

#60

Post by arcbyte »

ec109685 wrote: post #27
arcbyte wrote: post #21

Earlier quoted context omitted.

Your job as a product owner, as it relates to developers, is to be the customer so we dont have to waste time in phone tag. That meana you have to get inside the customers head and figure out what they want better than they know it and to take accountability when the team built what you thought the customer wanted but you fucked it up.

Why should that responsibility solely come from the product manager? Are devs incapable of their own good ideas if given a chance to understand the customer as well? The product manager should be the overall decider, but the best products do not germinate out of a single person’s head.

The problem isn't arbitrarily keeping the customer away from the devs and replacing them with a PO. The problem is the customer is fucking busy doing business and supporting two other software initiatives. They don't have time. The devs can never get their hands on the customers time in enough quantity to be truly effective.

The PO is an always available customer.

And here's the wonderful thing about agile - if you happen to have an always available customer, you don't need a product owner

Post reply on HN