ah, but will your mediocre team become a great engineering team by focusing on milestone, instead of projects? Nope, they won't.
Great engineering teams focus on milestones instead of projects
31–40 of 93 posts
Re: Great engineering teams focus on milestones instead of projects
#32I 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.
Re: Great engineering teams focus on milestones instead of projects
#33Great engineering teams have great engineers. Nothing else matters.
This is the "build it, they will come" argument. It doesn't work.
The idea is that if you put a bunch of great engineers in a room they'll make a brilliant product. Except they never do. They make something very clever, that does something brilliantly, but it's almost always the wrong thing. Engineers don't like talki g to customers, or discovering requirements, or running user focus groups. They want to build what they believe people need, which is very often not what people actually need. And they take far too long to do it because they're focused on perfecting the tech things instead of shipping.
Engineering teams need product managers, a QA team, technical writers, customer success people etc. Some engineering teams also need project managers too if they're no good at self-organising.
Re: Great engineering teams focus on milestones instead of projects
#34ah, but will your mediocre team become a great engineering team by focusing on milestone, instead of projects? Nope, they won't.
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).
Re: Great engineering teams focus on milestones instead of projects
#35Great 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.
Re: Great engineering teams focus on milestones instead of projects
#36Wow, a lot of negativity here! I found the article to provide quite a helpful mental model.
Agile processes definitely provide some of the structure mentioned here, but I've found that they lack sufficient guidance on the optimal size of work chunks- this article provides a compelling case for work chunks (milestones) of a specific size, and that alone is quite valuable to me as a concept.
Re: Great engineering teams focus on milestones instead of projects
#37This is just Agile/Scrum to me, which, if used right, is very effective, but it's not easy to do it correctly in practice over long period of time.
This is just Agile/Scrum to me
People were doing milestones decades, generations, centuries before "Agile" came along.
Re: Great engineering teams focus on milestones instead of projects
#38Great engineering teams have great engineers. Nothing else matters.
Hundo-P false. You can build the best space-age cat-shit box, have an intern set a price of $29.99 and tank a company.
Re: Great engineering teams focus on milestones instead of projects
#39ah, but will your mediocre team become a great engineering team by focusing on milestone, instead of projects? Nope, they won't.
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
Re: Great engineering teams focus on milestones instead of projects
#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 system by over estimating every task are viewed as super achievers, even if their actual value contribution is far lower. I think if you take away the metrics aspect of sprints, it actually becomes more useful.