12 ms·
Great engineering teams focus on milestones instead of projects
- Jensson 5y agoIsn't this just scrum? Scrum is very popular.
- ProfMeowsworth 5y agoCame here to say that. The author spends a lot of effort to basically describe working in sprints.
- throwaway984393 5y agoIt's very similar to Scrum, with some nuanced differences. He mentions "do not work on incremental changes" and "do not focus on user stories", and instead "do construct small goals that achieve more general yet still concrete outcomes", and "do prioritize those goals". I think his advice suffers from the same problem Scrum does, which is that it's simultaneously too generic and too constricting for anyone to perform it correctly and get good value out of it unless they just happen to be really excellent at their jobs or have a great team leader.
- civilized 5y agoSeems like this field is very preoccupied with attempts to distill excellence into a formula. But the skill you need to do this approach well is "identifying doable tasks that make meaningful progress towards the overall goal", which basically just the entire skill of project management.
- roenxi 5y ago"Sprint" is a label. Someone needs to put a lot o effort into describing what a sprint actually is, or people will use the label on things that are not sprints.
- jadeforrest 5y agoHi, 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!
- monocasa 5y agoIt can not be Scrum. For instance if each milestone is a different length of time.
- kfarr 5y agoYes from experience over the past year working in PM, the sprint and milestones are very different things. Sprints are predictable and pre-scheduled. Milestones have an estimate but may easily slip from one sprint to another.
- vngzs 5y agoThis is a good point. Scrum's sprint length inflexibility frequently means over or under-allocating time on projects, which messes up metrics (e.g., ticket completion per sprint) ... but is otherwise irrelevant to the work itself. This leads to organizations making sub-optimal choices that help with scrum, but don't help with work.
- Kinrany 5y agoScrum is about well-defined as Object-Oriented Programming, and people have strong and incompatible opinions about it. Discussing whether something is Scrum on the internet is pointless.
- deleted 5y ago[deleted]
- bmitc 5y agoIn my experience, scrum isn't used to focus on milestones. The focus has always been on "how long is this going to take?" and just uses supposedly well-defined, small tasks as pawns to get there. There may be milestones implicit there, but the entire focus is totally on when features will be done.
- deleted 5y ago[deleted]
- goldcd 5y agoI'm not disagreeing with the article, I'm just wondering what painful 'project' oritentated piece of work the writer has had to endure when it crashed into their life. To my mind there are products and milestones as maybe a point releases within a product - Agile/Scrum. I've suffered many systems over the years, but this is the one that makes the most sense - and maybe most importantly demarcates responsibilities. Projects are something external to this procress, product management (i.e. me) need to deal with it - a spanner in the works of what we were all happily orchestrating. "A project" is a demo we need to make next week, or a customer requirement the next release needs to address. It's something the product needs to deal with - and PM decides whether this should impact dev. It's the job of PM to sort out the backlog/timeline of the product so it hits the new eternal "project" requirement. Dev shouldn't even have to be aware the project exists - they'll maybe see their backlog change and just have to deliver on that as normal. Obviously the reality is that they're aware of the project once PM has accepted it, and you ask them to change their course - but dev shouldn't directly care.
- goldcd 5y agoI now just realize I'm describing Agile..
- ec109685 5y agoHiding things like “projects” from devs and keeping them isolated and working through their backlog blissfully unaware of the travails of the PM seems awfully top down. A PM should bring the team together, collaboratively work on what should be in the backlog, and provide enough context to the whole team so they can self organize and holistically deliver maximum value to the consumer. 10 heads are far better than a single godlike PM sorting everything out.
- goldcd 5y agoSorry, definitely wasn't saying "hide projects from devs" As PdO I see my job (and also that of my partner Dev Manager) as sheltering dev from the shit churning shit above and my sole purpose as providing backlog/semi-coherent guidance. My downward job is to make sure every 2 weeks some contiguous stories get created and I sign off on their completion on the way back up - and if my requests match what I get back, I have the joy of absorbing any corporate wrath. I'm a "shit-umbrella" Positive part of the job is when something hits me I can't deflect, I can cash in a few of my 'hopefully not-a-cunt' credits from the team, explain why I'm changing backlog mid-sprint, throw myself at their mercy, explain the issue etc etc - and collectively provide a better result than'agile' could officially provide.
- XorNot 5y agoProjects are things that are easy to put on my resume. Milestones, unless they look "project like" are a harder (though not impossible) sell. They complicate the narrative. When I'm moving on, the thing I want to be able to talk about is what I accomplished or helped accomplished that delivered value. At the end of the day when you're being hired you're basically selling one of two possibilities: things will get done and you will profit, or I will keep things earning you profit.
- qwertyuiop_ 5y agoIf 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.
- siva7 5y agoWhich would be represented in OKRs. Honestly this article feels like using project management definitions without understanding where they are coming from.
- jaderubick 5y agoI’m the author. No, not intending programs. Milestones are smaller than projects in my definition.
- ablekh 5y agoThe core argument in the post makes no sense to me at all. Projects and milestones are orthogonal concepts.
- jadeforrest 5y agoCan 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.
- ablekh 5y agoWell, firstly, milestones is a standard term and even in this article the author points to the expected definition (reference to Wikipedia article). His "special version of milestones" does not imply another definition, but rather just some specific attributes / requirements / expectations for milestones to be used. Secondly, the author presents project and milestones as a dichotomy ("Most engineering organizations focus on delivering projects. They should focus on milestones instead." - emphasis mine), whereas, in fact, you cannot define milestones outside of the context of a project. Thus, it is not an either/or situation, but rather one where both concepts simply exist. One more note: while both concepts are orthogonal, they are not fully independent; meaning that milestones must belong to a project and a project can have milestones.
- deleted 5y ago[deleted]
- faangiq 5y agoGreat engineering teams have great engineers. Nothing else matters.
- onion2k 5y agoThis 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.
- vanusa 5y agoThe 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.
- tomwojcik 5y agoThat'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.
- _y5hn 5y agoEven 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.
- daguava 5y ago
- synergy20 5y agoThis 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.
- vanusa 5y agoThis is just Agile/Scrum to me People were doing milestones decades, generations, centuries before "Agile" came along.
- sys_64738 5y agoThink of driving from point A to point B. A project is completing the journey. A milestone is like a major stopping point or identifying landmark that is unique and distinct. A mile marker is like a sprint story.
- jaderubick 5y agoA milestone == a mile marker. That is where the term came from. https://en.m.wikipedia.org/wiki/Milestone https://en.m.wikipedia.org/wiki/Milestone I think the term is rather unimportant. You could also use the term epic.
- wizardofmysore 5y agoGreat engineering teams focus on problems over products or milestones.
- jadeforrest 5y agoHi, 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.
- rk06 5y agoah, but will your mediocre team become a great engineering team by focusing on milestone, instead of projects? Nope, they won't.
- vanusa 5y agoNo, but we'll all become incrementally better by understanding the difference between necessary (what the article said) and sufficient (what you said it said).
- rk06 5y agoThe 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
- vanusa 5y agoThe article clearly didn't claim it was "sufficient". So I'm not sure what you're driving at, here.
- amcoastal 5y agoI 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.
- jaderubick 5y agoI’m the author. Most teams don’t work in this way in my experience. The key is how “milestone” is defined in the article.
- AlphaWeaver 5y agoWow, 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.
- xedrac 5y ago> 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.
- onlyrealcuzzo 5y agoAt 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...
- ignoramous 5y ago> Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... This is but a different kind of a rat-race?
- onlyrealcuzzo 5y agoCode quality should be handled in review. If you're deliver buggy code, then thay should be addressed as the bugs come up. Is that something that should've been caught in integration tests? Why did it pass review then? As long as it's not a pattern, it's not a problem. If something super severe happens - that's an organization-wide problem...
- strzibny 5y agoThat sounds like a horrible place to work!
- 5y ago
- black_13 5y agoYou know there is no I in team. I couldnt give a shit for team work or working with others even effectively I behave marginally and do enough to get along. I show up on time at meetings say the correct and currently fashionable buzz words but I focus on my own personal education and profitless side projects.
- leecommamichael 5y agoMy high-functioning teams rarely had an extensive backlog, but many loose notes of what a long-term strategy could look like. We had 1 mission at a time that we were gunning down— the outcomes of which were motivating, in/validating and gave us closure on an swath of planning and theory. I see some similarity between these properties and the author’s idea of a milestone.
- lbill 5y agoThis piece puts into words the way I manage personal projects!
- smugglerFlynn 5y agoIf your projects are running without any milestones defined, I have very bad news for you and the managers you hire.
- nyc111 5y agoIt seems NASA understands the value of milestones https://blogs.nasa.gov/webb/2021/12/24/key-milestones-after-liftoff/ https://blogs.nasa.gov/webb/2021/12/24/key-milestones-after-...
- mbrodersen 5y agoIt takes NASA 1 year to make a minor UI change and 1 day for SpaceX. According to astronauts who have worked for both organisations. So I am not sure that NASA is a good role model for how to run things.
- vladstudio 5y agoThe ideas in the article are similar (in a good way) to Shape Up by Basecamp [0]. I once got so inspired by it I translated it into Russian, just to better understand what's written :-) If you're intereseted in the topic, I highly recommend investing some time and reading it. [0] https://basecamp.com/shapeup/webbook https://basecamp.com/shapeup/webbook