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.
Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed.
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 completing tasks within the scrum" (regardless of the fact the task will take as long as it takes, and same SM/PO/Manager has been ignoring the problems mentioned in the daily stand-up).
Or, they mark that task as "complete", but make a new story for the remaining testing/bug fix/additional requirements work. They eventually have to deal with the fact their burndown chart is almost flat, since they're creating a half point of work for every point they close.
They also have people who complete their tasks early, but don't want to bring in another story, because that's "a violation of Scrum". Or they're worried about not being able to complete it by the end of the iteration and going through the previously-mentioned problem.
And no amount of bringing this up in retrospectives will change anything. In the scientific method, if your hypothesis fails in reality, you reject the hypothesis and search for another. In IT project management, when your process fails in reality, most people apparently prefer to reject reality.
Just admit you're doing Kanban and stop causing the problems created by arbitrary deadlines created by your iterations.
My team tried ad hoc meetings. We wound up not having the meetings. We now just stick to the sprint schedule, at the behest of our manager.
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.
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...
This is but a different kind of a rat-race?
It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts.
Which assumptions are behind that statement?
Does the team have uniform experience working in a single product? That statement feels more applicable here.
Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.
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.
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.
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.
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.
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.
People were doing milestones decades, generations, centuries before "Agile" came along.
https://en.m.wikipedia.org/wiki/Milestone
I think the term is rather unimportant. You could also use the term epic.
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.
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.
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.
Or companies that had no support/customer service, so engineers are constantly getting interrupted. We get cranky real quick when this happens too many times.
Or companies with poor product management, so engineers waste time building the wrong thing. This goes on despite our objections, only to have it thrown all away in a month or two.
Great engineers are necessary, but not sufficient, for a great tech company.
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
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 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.
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!
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.
