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

81–90 of 93 posts

Re: Great engineering teams focus on milestones instead of projects

#81

Post by theonething »

andruby wrote: post #51
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

Would be great to have job board specializing in companies that do kanban (and are anti-scrum, sprint, etc)

Re: Great engineering teams focus on milestones instead of projects

#82

Post by mavelikara »

geertj wrote: post #54
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.

> 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).

> effective PMs know better what customers want than customers themselves.

Please don't attribute superhuman skills to any particular team member.

For modern products valuable enough to be worth building deliberately, nobody knows what the market wants.

The team has hypothesises which they validate with software releases. The PM is accountable for these experiments.

Also, the use of the word "effective" in the quoted sentence is a setup for a No True Scotsman.

Re: Great engineering teams focus on milestones instead of projects

#83

Post by roeles »

scottlilly wrote: post #66
andruby wrote: post #51

Earlier quoted context omitted.

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

I'm also a fan of using Kanban for most corporate line-of-business development. In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum. At the end of the iteration, they have a unfinished tasks and one of two things happens. The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to comp…

One of the more interesting things I recently learnt about Agile (by listening to what Joe Justice did at Telsa was), that reaching the sprint goal appears to boost velocity. Thus, in the long run it's better to under-commit slightly than to over-commit. Sadly, I can't find the source for this easily. It's probably somewhere in the hours of interviews Joe gave which are on YouTube.

Re: Great engineering teams focus on milestones instead of projects

#84

Post by scottlilly »

roeles wrote: post #83
scottlilly wrote: post #66

Earlier quoted context omitted.

I'm also a fan of using Kanban for most corporate line-of-business development. In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum. At the end of the iteration, they have a unfinished tasks and one of two things happens. The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to comp…

One of the more interesting things I recently learnt about Agile (by listening to what Joe Justice did at Telsa was), that reaching the sprint goal appears to boost velocity. Thus, in the long run it's better to under-commit slightly than to over-commit. Sadly, I can't find the source for this easily. It's probably somewhere in the hours of interviews Joe gave which are on YouTube.

My gut feeling is that there's still good value in frequent demos/checkpoints/etc. It does create a sense of urgency to complete tasks and lets the owner know that progress is really being made.

Besides undercommitting for the sprint, I've seen a lot of point inflation. Developers start padding their story point estimates to allow for extra time.

The worst case I ever saw was a team of five developers breaking down a feature request into very small stories with total points that would require the whole team's workload for two sprints. I completed all those stories by myself in three days. I'm good, but not that good. I suspect the team was so tired/afraid of being admonished by the Product Owner, they just kept padding and padding their estimates.

Of course, no one bothered to look at the cause of the problem behind the developers massively over-estimating required effort. "The Process" is always right, and the people are always wrong. Isn't that the first principle of the Agile Manifesto (sarcasm intended)?

Re: Great engineering teams focus on milestones instead of projects

#85

Post by icedchai »

sharken wrote: post #72
icedchai wrote: post #67

Earlier quoted context omitted.

I have seen much of these problems with Scrum, as well. Redefining "complete" so we can book the points, but actually finish it in the next sprint is very, very common. Finishing early, starting on a future story, but the scrum master asking you to not bring that story into the current sprint, in case you don't finish it, is also a frequent occurrence. My view is "if I don't finish it, it rolls over, so who cares", b…

It's the same issue with SAFe, with the added cost of many additional meetings that provide little value. Redefining "complete" or letting a story roll over, e.g. the estimate for finishing it was wrong, seems to indicate something doesn't work as it should. Breaking down a project into milestones sounds like a great idea, i totally agree that project management could use an alternative.

All the overhead that occurs with Scrum / SAFe / Agile in general is absolutely terrible. Daily standups? Sprint planning? Retrospectives? Grooming meetings? Then there are additional, generally agenda-less team meetings on top of it. All these meetings, plus time lost to context switching, etc., probably adds up to 20 or 25% of the time.

Re: Great engineering teams focus on milestones instead of projects

#86

Post by geertj »

mavelikara wrote: post #82
geertj wrote: post #54

Earlier quoted context omitted.

> 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).

> effective PMs know better what customers want than customers themselves. Please don't attribute superhuman skills to any particular team member. For modern products valuable enough to be worth building deliberately, nobody knows what the market wants. The team has hypothesises which they validate with software releases. The PM is accountable for these experiments. Also, the use of the word "effective" in the quoted…

I am speaking from experience, and no, I am not superhuman. As a PM it is quite common to understand customers (meaning, customer use cases) better than they understand them themselves. The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’.

I did not say that a PM will understand any customer issue, and yes sometimes new research is needed, which is expensive and time consuming.

I do not see the link to the true Scotsman argument as in my view my description of a PM is not mythical or heroic but quite common at least in my area.

Re: Great engineering teams focus on milestones instead of projects

#87

Post by andruby »

theonething wrote: post #81
andruby wrote: post #51

Earlier quoted context omitted.

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

Would be great to have job board specializing in companies that do kanban (and are anti-scrum, sprint, etc)

That’s actually a good idea.

Re: Great engineering teams focus on milestones instead of projects

#88

Post by mavelikara »

geertj wrote: post #86
mavelikara wrote: post #82

Earlier quoted context omitted.

> effective PMs know better what customers want than customers themselves. Please don't attribute superhuman skills to any particular team member. For modern products valuable enough to be worth building deliberately, nobody knows what the market wants. The team has hypothesises which they validate with software releases. The PM is accountable for these experiments. Also, the use of the word "effective" in the quoted…

I am speaking from experience, and no, I am not superhuman. As a PM it is quite common to understand customers (meaning, customer use cases) better than they understand them themselves. The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’. I did not say t…

> The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’.

I agree to most of this. The team - by virtue of building and operating the software product catering for many customers - can often understand the customer usecases and solution better than any one customer. But it is the team, as a whole, where this expertise resides. Not one member of the team who happens to have a particular role and title.

> I do not see the link to the true Scotsman argument

By adding the word "effective" in:

> effective PMs know better what customers want than customers themselves.

you seemed to imply that any counterexample of a PM who is not doing this as not a true effective PM, and hence, not worth discussing.

Re: Great engineering teams focus on milestones instead of projects

#89

Post by geertj »

mavelikara wrote: post #88
geertj wrote: post #86

Earlier quoted context omitted.

I am speaking from experience, and no, I am not superhuman. As a PM it is quite common to understand customers (meaning, customer use cases) better than they understand them themselves. The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’. I did not say t…

> The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’. I agree to most of this. The team - by virtue of building and operating the software product catering for many customers - can often understand the customer usecases and solution better than any one…

> But it is the team, as a whole, where this expertise resides. Not one member of the team who happens to have a particular role and title.

Which is why I made the distinction between accountable and responsible. I totally agree that it’s the team as a whole that’s responsible for the output of the team, and that it’s essential that everybody on the team has a customer focus.

> you seemed to imply that any counterexample of a PM who is not doing this as not a true effective PM, and hence, not worth discussing.

In my opinion, the better a PM understands their customers, the more effective they are in their role. I had thought that this would be relatively noncontroversial. It certainly wasn’t a dig against a some subset of my profession. Virtually all PMs that I’ve worked with see this as core to their role.

Now I am curious, was there anything in the wording of my reply, or in your past experience working with PMs, that caused you to reply?

Re: Great engineering teams focus on milestones instead of projects

#90

Post by roeles »

scottlilly wrote: post #84
roeles wrote: post #83

Earlier quoted context omitted.

One of the more interesting things I recently learnt about Agile (by listening to what Joe Justice did at Telsa was), that reaching the sprint goal appears to boost velocity. Thus, in the long run it's better to under-commit slightly than to over-commit. Sadly, I can't find the source for this easily. It's probably somewhere in the hours of interviews Joe gave which are on YouTube.

My gut feeling is that there's still good value in frequent demos/checkpoints/etc. It does create a sense of urgency to complete tasks and lets the owner know that progress is really being made. Besides undercommitting for the sprint, I've seen a lot of point inflation. Developers start padding their story point estimates to allow for extra time. The worst case I ever saw was a team of five developers breaking down a…

I think showing evidence of your progress is an effective way to plan more realistically (evidence-based) than the wishful thinking I've seen.

The moment estimates are no longer without consequences you get this kind of behavior. I've done it too, in a place where I personally had to be present in a call with the customer to explain why I went 2 hours over the (someone else's) estimate. Your behavior changes after such a call.

The main point I was trying to get across is that team morale appears to be very important for the velocity. You don't get high morale by stuffing too much work into a sprint or making any single story important.

My main objection with Scrum is that people tend to take the rituals as gospel. Which is why I mentioned Agile rather than Scrum.

Post reply on HN