by tyroh on 12/24/21, 11:00 PM with 89 comments
by xedrac on 12/25/21, 6:39 AM
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.
by leecommamichael on 12/25/21, 8:30 AM
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.
by goldcd on 12/25/21, 12:32 AM
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.
by AlphaWeaver on 12/25/21, 6:00 AM
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.
by synergy20 on 12/25/21, 2:33 AM
by amcoastal on 12/25/21, 5:11 AM
by sys_64738 on 12/25/21, 2:40 AM
by vladstudio on 12/25/21, 12:27 PM
by wizardofmysore on 12/25/21, 3:55 AM
by faangiq on 12/25/21, 3:53 AM
by rk06 on 12/25/21, 5:02 AM
by ablekh on 12/25/21, 1:46 AM
by nyc111 on 12/25/21, 12:13 PM
by qwertyuiop_ on 12/25/21, 12:56 AM
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.
by Jensson on 12/24/21, 11:55 PM
by lbill on 12/25/21, 8:50 AM
by smugglerFlynn on 12/25/21, 11:47 AM
by XorNot on 12/25/21, 12:55 AM
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.
by black_13 on 12/25/21, 6:57 AM