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.
That’s exactly why I prefer a more kanban-inspired flow. We discuss new tickets weekly, estimate them with planning poker [0] and move some to “in focus”. We have WIP limits on focus, doing and for-review to limit the max concurrency and encourage pairing.
Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed.
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 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.
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", but this is frowned upon since it throws off the reports.
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.
All the overhead that occurs with Scrum / SAFe / Agile in general is absolutely terrible. Daily standups? Sprint planning? Retrospectives? Grooming meetings? Then there are additional, generally agenda-less team meetings on top of it. All these meetings, plus time lost to context switching, etc., probably adds up to 20 or 25% of the time.
One of the more interesting things I recently learnt about Agile (by listening to what Joe Justice did at Telsa was), that reaching the sprint goal appears to boost velocity. Thus, in the long run it's better to under-commit slightly than to over-commit.
Sadly, I can't find the source for this easily. It's probably somewhere in the hours of interviews Joe gave which are on YouTube.
My gut feeling is that there's still good value in frequent demos/checkpoints/etc. It does create a sense of urgency to complete tasks and lets the owner know that progress is really being made.
Besides undercommitting for the sprint, I've seen a lot of point inflation. Developers start padding their story point estimates to allow for extra time.
The worst case I ever saw was a team of five developers breaking down a feature request into very small stories with total points that would require the whole team's workload for two sprints. I completed all those stories by myself in three days. I'm good, but not that good. I suspect the team was so tired/afraid of being admonished by the Product Owner, they just kept padding and padding their estimates.
Of course, no one bothered to look at the cause of the problem behind the developers massively over-estimating required effort. "The Process" is always right, and the people are always wrong. Isn't that the first principle of the Agile Manifesto (sarcasm intended)?
I think showing evidence of your progress is an effective way to plan more realistically (evidence-based) than the wishful thinking I've seen.
The moment estimates are no longer without consequences you get this kind of behavior. I've done it too, in a place where I personally had to be present in a call with the customer to explain why I went 2 hours over the (someone else's) estimate. Your behavior changes after such a call.
The main point I was trying to get across is that team morale appears to be very important for the velocity. You don't get high morale by stuffing too much work into a sprint or making any single story important.
My main objection with Scrum is that people tend to take the rituals as gospel. Which is why I mentioned Agile rather than Scrum.
The problem with Sprints is that they come with fixed events and associated ceremonies. If your 2 week task is slipping by 2 days you have to answer why in the retrospective. If you remove the sprint deadlines and make the retrospective etc. adhoc and mostly dev team initiated it takes away all the pressure while keeping monitoring/measurements.
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 overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...
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.
My 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.
I'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.
Hiding 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.
Sorry, 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.
I still think you’ve set things up so that the direction for the whole team almost exclusively has to come from you.
If you could share this responsibility with the team so they know the context and outcomes desired by the business, you’ll have a larger pool of good ideas, including from folks who deeply know the code and push the roadmap from that perspective.
On the bi-weekly sprint planning - yes.
From what's actually on the backlog - definitely not.
Opportunity Team meetings (or stakeholder chats - lead devs, architects, support peeps etc) always cover the general direction we want to go and are where the ideas for the backlog come from.
Example of easy benefit is if we have two things we want the product to do - this is where you learn what the options are and more importantly the rough costs/impacts.
If something's going to cost 10x as much and require refactoring, I suddenly decide I don't want it as much as the other option.
Can also come up from mid-sprint from dev.
(Real example) I had a US to add a new button. Dev noticed there was an internal 'button framework' already in place (as somebody had some a good job in the distant past). She asked if I could add a new US for next sprint to continue this work, so she could extend this framework and allow us to publish it.
i.e. Focus on adding new controls to the config tool, and then delivering on the original US with a bit of config.
I had no idea this untapped potential even existed - but for 2 weeks effort of one person, my product now has a configurable UI.
Lost count of the number of issues where a customer query can now be answered with - Just add a new button/tab/menu (and then over time it's been easy to add contextual controls, make more tokens available to the target builder etc etc)
"Technical Debt" is often mentioned (hidden cost of a hacked together mess, increasing the cost of the next feature to be piled on top). What's satisfying are the "Technical Assets" like this - not just for me as I get a better product, but for the dev who can take pride in building something elegant and knowing this feature is theirs.
Your job as a product owner, as it relates to developers, is to be the customer so we dont have to waste time in phone tag. That meana you have to get inside the customers head and figure out what they want better than they know it and to take accountability when the team built what you thought the customer wanted but you fucked it up.
Why should that responsibility solely come from the product manager? Are devs incapable of their own good ideas if given a chance to understand the customer as well?
The product manager should be the overall decider, but the best products do not germinate out of a single person’s head.
The person you're responding to is not advocating that ideas are the responsibility of the PM, nor are they saying the PM should be the overall decider.
They are saying the PM is responsible for collecting information from the customer and bringing that information to the team in an efficient manner so the team can make decisions based on that information.
If the PM brings incorrect or inadequate information, the resulting product will be poor because the team will have made its decisions on the basis of that poor information.
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 gatekeeping because they are an always available customer.
> Why should that responsibility solely come from the product manager?
It should not, but the PM is accountable. GP put it nicely, effective PMs know better what customers want than customers themselves. This keeps iterations fast as PMs can immediately answer questions on trade offs instead of going back to the customers (who don’t know).
I am speaking from experience, and no, I am not superhuman. As a PM it is quite common to understand customers (meaning, customer use cases) better than they understand them themselves. The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’.
I did not say that a PM will understand any customer issue, and yes sometimes new research is needed, which is expensive and time consuming.
I do not see the link to the true Scotsman argument as in my view my description of a PM is not mythical or heroic but quite common at least in my area.
> The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’.
I agree to most of this. The team - by virtue of building and operating the software product catering for many customers - can often understand the customer usecases and solution better than any one customer. But it is the team, as a whole, where this expertise resides. Not one member of the team who happens to have a particular role and title.
> I do not see the link to the true Scotsman argument
By adding the word "effective" in:
> effective PMs know better what customers want than customers themselves.
you seemed to imply that any counterexample of a PM who is not doing this as not a true effective PM, and hence, not worth discussing.
> But it is the team, as a whole, where this expertise resides. Not one member of the team who happens to have a particular role and title.
Which is why I made the distinction between accountable and responsible. I totally agree that it’s the team as a whole that’s responsible for the output of the team, and that it’s essential that everybody on the team has a customer focus.
> you seemed to imply that any counterexample of a PM who is not doing this as not a true effective PM, and hence, not worth discussing.
In my opinion, the better a PM understands their customers, the more effective they are in their role. I had thought that this would be relatively noncontroversial. It certainly wasn’t a dig against a some subset of my profession. Virtually all PMs that I’ve worked with see this as core to their role.
Now I am curious, was there anything in the wording of my reply, or in your past experience working with PMs, that caused you to reply?
> Now I am curious, was there anything in the wording of my reply, or in your past experience working with PMs, that caused you to reply?
No, it is not anything you said specifically, Geert. But I have direct and indirect knowledge of PMs who adopt the "All the shipped features were my ideas, the bugs and tech debt were added by engineers" attitude. This thread too gave my that vibe.
I have written more of my opinions on the PM orgs at [1] and [2]. Happy to chat more, if you are interested - my email is on my profile.
The problem isn't arbitrarily keeping the customer away from the devs and replacing them with a PO. The problem is the customer is fucking busy doing business and supporting two other software initiatives. They don't have time. The devs can never get their hands on the customers time in enough quantity to be truly effective.
The PO is an always available customer.
And here's the wonderful thing about agile - if you happen to have an always available customer, you don't need a product owner
Wow, 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.
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.
Think 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.
The 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.
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.
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.
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.
Even 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.
That'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.
This still won't make a great company. I've seen companies work on great tech, but had no marketing or sales in place, so very few resulting customers. You build it and nobody shows up.
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.
In my experience, there's no architecture or methodology that can make bad engineers build good software. But there's definitely ways to ensure that good engineers end up making shit software.
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).
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.
Well, 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.
It 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.
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.
Which would be represented in OKRs. Honestly this article feels like using project management definitions without understanding where they are coming from.
Scrum 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.
In 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.
It'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.
Seems 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.
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!
"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.
This 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.
Yes 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.
Projects 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.
You 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.
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.