Live data from Hacker News

Great engineering teams focus on milestones instead of projects

rubick.com

71–80 of 93 posts

Re: Great engineering teams focus on milestones instead of projects

#71
post #59

Earlier quoted context omitted.

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 gat…

Yes - also there are many customers. PdO is a weighted amalgamation of them all.

Re: Great engineering teams focus on milestones instead of projects

#72

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…

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.

Re: Great engineering teams focus on milestones instead of projects

#74
post #39
post #34

Earlier quoted context omitted.

No, but we'll all become incrementally better by understanding the difference between necessary (what the article said) and sufficient (what you said it said).

The thing is correlation does not imply causation. The article says great teams does X. And implies that you should do X as well. But is doing X the necessary and sufficient requirements to become a great engineering team? In this case, no, it is not

The article clearly didn't claim it was "sufficient". So I'm not sure what you're driving at, here.

Re: Great engineering teams focus on milestones instead of projects

#75

I ignore so many of these nonsensical articles on here, but this one really got my goat. Is there someone out there that works on "projects" where the goals of the project are not delivering milestones? I'm probably just lost in the generic management babble.

I’m the author. Most teams don’t work in this way in my experience. The key is how “milestone” is defined in the article.

Re: Great engineering teams focus on milestones instead of projects

#76

If we stick to strict Project Management definitions, milestones are within a project. A program (representing a strategic goal) can contain multiple projects big and small. Perhaps the author wants to convey programs which map to company or divisions strategic initiatives.

I’m the author. No, not intending programs. Milestones are smaller than projects in my definition.

Re: Great engineering teams focus on milestones instead of projects

#77
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…

Hi, I'm the author.

This isn't a post about scrum vs kanban. It's primarily about the value of using a specific definition of milestone to encourage incremental delivery. And to highlight some of the benefits of delivering in this way.

Re: Great engineering teams focus on milestones instead of projects

#78
post #17

The core argument in the post makes no sense to me at all. Projects and milestones are orthogonal concepts.

Can you explain more? I don't see it that way, but it might be we're defining things differently. Milestones are defined in a specific way within the article, and in that way they don't seem orthogonal to me.

Re: Great engineering teams focus on milestones instead of projects

#79
post #2

Isn't this just scrum? Scrum is very popular.

Came here to say that. The author spends a lot of effort to basically describe working in sprints.

Hi, I'm the author. I'm not intending to describe working in sprints. You can implement the ideas behind this article with sprints, kanban, or something else entirely. Using sprints doesn't do what using milestones does.

So what I'm hearing is that that wasn't clear. Since a few people said that here, I'll make some edits to clarify. If you have any suggestions as to where the confusion is, I'd love to hear it. Thank you!

Re: Great engineering teams focus on milestones instead of projects

#80

Great engineering teams focus on problems over products or milestones.

Hi, I'm the author. Totally agree with you on this.

I do tend to focus on milestones first, because even if you're focusing on problems, using milestones to focus on what's next can sometimes be helpful. But if you can get to focusing on problems directly, that's even better.

For many organizations, there isn't the latitude to do so, so I've found this works within project-focused cultures better.

Post reply on HN