
Hard deadlines are not user-first - jatins
http://jatins.gitlab.io/me/why-deadline/
======
ozmbie
In my experience when people focus too much on sprint deadlines, they miss the
purpose of sprints.

Timed sprints exist not for the benefits of managers, but for the benefit of
developers. They exist so that the development team has a shield against
managers making last-minute decisions and changing priorities without notice.

If the focus and discussion is regularly on short term deadlines, then the
developers are not driving the process, the managers are. It means that
sprints are seen as a management methodology and not a development
methodology. And then everyone has a hard time.

Managers who think this way know they’re not “allowed” to make mid-sprint
changes so instead they focus on the end/deadline.

The managers should be spending their energy supporting the team and figuring
out what the priorities are for the next sprint(s). If they’re spending their
mental energy on deadlines then they’re doing everyone involved a disservice.

~~~
strictfp
Sprints exist so that both management and devs can realize that there is more
work than there is time. It forces devs to be focused and scope their work. It
forces management to prioritize and scope down as well.

Keeping the deadline of the sprints is supposed to force management and devs
to agree on reasonable scopes, such that the output of the dev team becomes
predictable with time.

This enables devs to get trusted by management, breaking the poisonous
relationship.

~~~
hrktb
> This enables devs to get trusted by management

I am curious about that “trust” part. In your model what happens when
management doesn’t trust devs ? do devs trust management ?

~~~
HereBeBeasties
Define "trust". As an industry I think we often talk about the wrong things
here. People look at this from the point of view of controlling IT &
developers (controlling costs, deadlines, functionality, etc.) when really
everyone should be looking at it instead from the point of view of maximising
value to the business. That's what Agile is really all about - it should
really be about trusting that people will make good decisions based on the
currently available info (which will likely be different than when you started
the project), do good experiments, and find good compromises. This is
especially true if unforeseen delays to a team's work has a knock-on effect on
other people (which a good manager will try hard to decouple and avoid,
deliver incrementally to lower the risk, or at least include healthy
contingency for).

IMO, you should only really care about imposing deadlines as an answer to the
question "how much time is it worth investing in solving this problem?" If the
scope of the solution becomes larger than expected, and it starts to look like
it won't pay off, abandon it and start doing something else instead. You had a
good experiment which was entered into in good faith based on the data
available at the time. That's the nature of experiments. Learn your lessons
and try the next one.

Trusting that your teams have good plans that fail early and incorporate fast
feedback loops is generally the only real way to make sure that they have
realistic scheduling/deadlines for those plans and that they are likely to
generate real value. It amazes me how many people in management seem to put
their efforts and emphasis mostly on scheduling the plans, rather than the
plans themselves. I guess it's easier to come up with estimates for things,
than it is to come up with good strategy and business value
propositions/justification.

I really recommend reading "A Seat at the Table" by Mark Schwartz (ISBN
9781942788119) for a good exploration of how agile meets management trust
issues, budgeting and longer term planning, and how to try to break down the
barriers between "IT" and "the business" (when in most modern companies, IT
_is_ the business).

~~~
hrktb
Very good points.

Reading the comments, I think what I was bugging is the notion that would give
a task not trusting it would be done.

People point at micro-management as an effect, because it basically means
providing more limited tasks with limited risks.

But I think in the long term the direction we tend to take for people we don’t
trust is to set penalties (bad evaluations, demoting, firing included).

In that sense, in average there should only be people you trust at the
appropriate levels of an org, so I am not sure it is important to focus on
gaining trust as it builds up just by doing ones job.

That’s where I like your idea of management trusting a plan, more than
focusing on the team.

------
bauerd
>An ideal solution to this would have been to just go talk to the stakeholders
- product/sales team - ask them if the delay could be potentially customer
losing. And if it is, by all means put in the extra hours, work those
weekends.

Strongly disagree, it's not on the shoulders of developers to ensure faulty
promises can be kept. I will for sure not sacrifice weekends, this is far from
ideal

~~~
wpietri
Definitely. That's phase 2 of the world's worst game. Phase 1 being "Please
give us an unbiased estimate, but we will yell at you until it's the number we
like." Under those conditions, working weekends is just feeding the beast.

I do think it can be ok to work extra hours to seize an unusual opportunity or
deal with some truly unexpected problem. (E.g., the destruction of the World
Trade Center in 2001 required a lot of tech people to scramble.) But that has
to be balanced by something good for the workers and painful for the business,
like an equivalent amount time off or significant overtime pay.

But workers shouldn't have to spend their spare time making up for managerial
incompetence and malpractice.

~~~
granshaw
I like bringing up this barometer the next time I'm asked to work weekends:

"Did a bomb go off in our datacenter? No? It can wait then."

~~~
bob33212
I was lucky enough to see management get caught in their bullshit during one
of these "hard deadlines" when I was just out of school. They said that
December 1st was the deadline and that if we didn't get the release out we
would lose millions in revenue. People run around like crazy until the end of
November when we realize the EULA document is just a place holder and that
Legal has not given us the new EULA. All of a sudden the deadline is mid
January when we expect to get the new EULA.

~~~
jrochkind1
What drives me crazy about this is how it shows that some employees are
expected to bust their asses to meet deadlines, but others (legal) are not --
oh, if legal won't be done in time, we'll just move the deadline, no problem.

While some people -- healthily or not -- are willing to bust their butts (with
or without extra compensation) when they think everyone is in it together, it
will generally kill morale and willingness to do such when you realize when
_someone else_ 'doesn't have time', the deadline is moved, it's only _you_
expected to work evenings and weekends and extra hours to meet the deadline.
Why is your work-life balance less important than theirs exactly? (Only
because they can get away with it...)

And while not always as stark as your example, people are often shown this
_all the time_ , that not everyone's inconvenience is in fact treated equally,
that the "deadline that can't be missed" really only applies to some people,
and is moved for others.

------
kerkeslager
One thing I've noticed on a lot of teams is that sales/product believes their
own hype and overestimates the importance of their software in people's lives.
There's this belief that customers/users are waiting impatiently for features
when 99% of the time, they're just not. Yes, features _affect_ users, but
often users don't know what features are coming, because they just don't care
enough to know.

Software I use every day: Firefox, Slack, Vim, MacOS, Python, Bash, GCC,
Android, StrongLifts 5x5 App, Gmail, Google Docs, Google Maps, Simple
(Banking) App, VLC.

All of these (except maybe Vim?) have released some significant features in
the past year. Of these features, I only knew about a few Python features that
were coming before they came, and none of them were ones where I was thinking
"I can't wait for this to come out! If this doesn't come out soon I'm
switching languages!"

On the contrary, features take a long time after they come out for me to learn
how to use them and for them to affect my decision making. In fact, my initial
reactions to new features are much more likely to be _a liability_ than to be
an asset to the software company. I'm considering switching away from Simple
because their expenses update doesn't really fit my needs, since as a
freelancer I'm not paid on a regular schedule. And I'm _definitely_ switching
away from MacOS since their deprecations have broken some tools that are key
for me. If they had taken more time, maybe someone would have noticed the
problems and avoided them.

Sure, early on things are different: first-to-market advantage is real. But
for _most_ of the lifetime of a project, you aren't releasing killer features.
You're releasing incremental changes that have a much higher chance of
_losing_ you users than of _gaining_ you users (in the short run, at least).
Never releasing isn't an option--death by stagnation is a thing--but releases
should be done with painstaking attention to detail rather than urgency.

~~~
nullspace
This is fairly controversial. Is there any example of a startup that actually
made it by employing this strategy?

One of the truisms I've heard and have always followed is you need to release
something you're embarrassed about, because that's the quickest way of getting
user feedback, and understand if a user actually _wants_ that feature, and if
it's actually worth spending time improving that feature.

It's easy to waste valuable capital paying attention to details that the user
does not really care about.

EDIT: I've noticed that most of the software you posted here is very well
established, most > 10 years. I'd be surprised if any of them follow "agile"
by the books.

~~~
kerkeslager
> Is there any example of a startup that actually made it by employing this
> strategy?

Is there any example of a startup that actually made it by releasing features
that were broken or poorly thought out?

Is there any example of a startup that actually failed because they released
features a week or a month after an internal deadline?

Do we have enough insight into the internal strategy of enough companies to
make any claims about this at all?

Your argument is basically looking at existing startup culture, but realize
that most startups that use a fail fast strategy do exactly that: fail. I'm
not saying that's causal: I think success is hard and there's a myriad of
reasons why startups fail. But I don't think we can look at the fraction of
startups that have succeeded and point to this one element of their strategy
and say, "This was a necessary component of their success."

I'm not looking at the whole industry because I don't think there's enough
representative data there. I'm looking at my own experience as a user and
noticing, "Hey, I actually don't even know what features are planned for _any_
of the software I use, yet I'm still using it. So maybe future features don't
have anything to do with why I use software. And maybe other users are
similar."

Let me ask you: can you name 5 features that you're looking forward to in the
software you use? If those features take a year longer than expected to
materialize, do you think you'd switch to a competitor? That's rhetorical: I
am sure some HN people can answer those in the affirmative, but I'm also sure
that's not the norm.

> One of the truisms I've heard and have always followed is you need to
> release something you're embarrassed about, because that's the quickest way
> of getting user feedback, and understand if a user actually _wants_ that
> feature, and if it's actually worth spending time improving that feature.

Sure, but then you don't know if the user doesn't want the feature because
it's not useful, or because it's badly implemented since you didn't spend time
to get it right. You're collecting data faster, but you're also confounding
the data so that you don't know what it means.

> It's easy to waste valuable capital paying attention to details that the
> user does not really care about.

Agreed. One of the details I'm saying the user does not really care about is
whether your feature is released today or three months from now.

> EDIT: I've noticed that most of the software you posted here is very well
> established, most > 10 years. I'd be surprised if any of them follow "agile"
> by the books.

...which is a pretty damning statement about '"agile" by the books'.

I'll say what I've said before many times: the entirety of agile is contained
on this page: [https://agilemanifesto.org/](https://agilemanifesto.org/) .
"Agile by the books" is an attempt to make money off a successful strategy,
but you can't sell six lines of text, so people write books on how they
implemented agile, which if you understand agile, is fairly useless for
understanding how YOU should implement agile. If you really grok those
principles, then it's really clear that releasing early to get user feedback
doesn't follow the principles:

 _Individuals and interactions over processes and tools_ The deadline is a
process rule that you're prioritizing over literally every individual in this
situation.

 _Working software over comprehensive documentation_ Releasing broken software
so you can document user response doesn't follow this principle.

 _Customer collaboration over contract negotiation_ Customers should be
involved _long_ before you're releasing features.

 _Responding to change over following a plan_ The deadline is the plan. The
fact that the feature isn't ready by the deadline is the change that you need
to respond to.

~~~
powowow
In my last job we were sufficiently sophisticated users of AWS that we
routinely had conversations with product managers to learn if specific
features were on the roadmap, and if so, if there was an ETA. We had these
conversations because we were debating whether we wanted to write a solution
of our own, or if we wanted to wait for a generalized one to be released.

That said, the product managers generally left us with information such as
"this is actively being worked on", "this is planned work in the upcoming
quarter, but it could change", "this is on the roadmap without a date", and
"this is not on the roadmap". No specific dates promised, but it was still
good enough for our purposes.

I hope they weren't using our requests to push for specific dates, internally.

------
mikekchar
There are 2 normal ways to do things: work until you achieve the functionality
you want and release it when that happens or work until an arbitrary date and
release whatever you have at that point. Surprisingly, as a developer I always
prefer the latter. As a coworker of mine if fond of saying, the time you know
the most about the project is when you are finished. The time when you know
the least is when you are starting.

By choosing to release "whatever we can do" at a certain time it encourages
you to make difficult prioritisation decisions as the "deadline" approaches.
Are we _really_ OK with releasing with just this functionality? Maybe we
should axe X and replace it with Y since we don't look like we are going to
get both. Maybe Z is an even better compromise that we didn't realise was an
option at the beginning of the project.

If you try to hit functionality, it allows the organisation to avoid
rethinking its planning decisions. We aren't releasing until the ideas we had
6 months ago are _all_ implemented exactly as we envisioned it back then. By
the way, why is it taking so long?

Of course trying to hit both at the same time is just a recipe for disaster.

~~~
secondo
Exactly this, and what a lot of less senior developers don’t understand is
that the fixed timeline is actually a defensive mechanism for the development
team. If the date is fixed the functionality has to be variable and the best
people to assess what fits or not is the development team who thus can be in
control of their own planning.

~~~
hobs
No, for many managers the fact that the deadline is fixed means they can death
march you for all the functionality they decide needs to be complete at that
date.

The idea that adding additional process to manage your managers is laughable
at best.

~~~
gowld
Manager can't hold your fingers and force you to type code. Agile's short
sprints mean that managers learn in 4 weeks instead 16 that death marches
don't work. Managers can be managed as much or little as reports are.

~~~
hobs
I know currently of several companies being managed into the dirt by people
who dont learn no matter the scheduling mechanism or level of machiavellian
maneuvering by their employees.

So no, you cant manage your boss, you can inform them, maneuver them, help
them, cajole them; but at the end of the day you cant get them to change their
behavior if they truly don't want to(and they can just fire you for being too
annoying.)

~~~
shantly
In the current environment one can get away with a lot of push-back because
managers with any fraction of a clue know if they piss you off too much you'll
be giving them your notice, new job in hand, in a few weeks, if not days. That
won't last—which is why if we're going to organize for better leverage against
abuse in bad times, now'd be the time to do it, but I guess enough people've
been convinced unions will impoverish them that we're not gonna, maybe next
boom, see y'all then—but for now it's pretty nice.

------
latchkey
At Pivotal, I learned that having sprints is silly. They have the concept of
one week iterations instead. The PM just keeps a rolling backlog of stories
and devs just pick the next one off the top. Dev's are responsible for
pointing the stories and the sum of those points averaged over time (usually
2-3 weeks) become velocity.

Just keep the velocity as consistent as possible and things work out for the
best. If the PM wants a story moved up the list, then they can see how much
work will fit into an iteration and how it will affect schedules.

All of this is managed in their homegrown, but publicly available tool called
Pivotal Tracker. You can read the website documentation for a more thorough
explanation. Once I learned this methodology and started practicing it like a
religion, deadlines went away and PM's could estimate due dates many weeks in
advance. It was a life changing experience that I highly recommend at least
giving a shot at your own workplace.

~~~
meerita
Hi, PM here. I ditched scrum long time ago with the team and setup 1 week
cycles. We meet on monday, to kick off and see results at friday. We managed
to keep executable development cycles, so from my part, i tend to ask for less
every single weekend because that's how I get most of the results, and keep
moving. In the end, it's better than seeing results every 2 weeks and some
major results in a month or so. I preffer to move quickly, and iterate those
"mini-sprints" in case one went wrong.

~~~
KZeillmann
This sounds like Scrum with one week sprints.

~~~
meerita
we don't do retrospectives, groomings, estimation of stories, etc.

------
keyP
I find being transparent with my team makes it a lot easier. There are
internal deadlines and external deadlines. Former are internal ones which have
no real consequence if missed and just keep a development rhythm (e.g. weekly
iteration, monthly release, quarterly roadmap update catchup etc...).

The other type comes from third parties, generally, such as clients or the
board. Once you separate these two types of deadlines, I find my engineers
more understanding about having to meet external ones whereas blurring
internal and external into one "deadline" simply causes people to either
burnout or lose faith in management because everything is marked as urgent.

~~~
Cthulhu_
I've found most deadlines I've worked with to be internal. The only exceptions
to that however was legislation dates; Cookie walls and GDPR, new laws for
stock trading on an European level (forgot the name), things like that. These
are things for which your company can be fined heavily for. Other deadlines
are likely to be of the "we'll start earning money later" variety.

~~~
ozim
Those are BS as well. No one is going to fine company on day 1 of a new law.
GDPR was effective 25 may 2018 but companies still had half of a year to
implement it.

Basically if you prove you are working on it I bet they will let you off the
hook.

------
vbtemp
I think Agile is the heart of the problem. It is a cargo cult that brings
predictability to software projects by ensuring that it's always a dumpster
fire, that everyone's stressed, and that everything takes longer than
estimated. Eating up "tickets" and crapping out code is not how you quickly
deliver software to customers and iterate in the face of changing needs. It's
so sad there are generations of developers being raised thinking "Agile" and
playing absurd, time-wasting games with "issues" is how to build software.
Agile is to the 2020s what the Bobs in "Office Space" was to 2000: "Trendy"
corporate management absurdity and fury signifying nothing.

The alternative to Agile is Software Engineering, where you do important
things like assess your requirements and capabilities, identify how to
validate those requirements are functioning properly and support your business
requirements, promote testing and QA to a first-class citizen. Most
importantly to always have functioning software that is reasonably
demonstrated to be correct. That way you release with confidence, people take
pride in their work, and the product, team, and schedule all become quite
pleasant.

~~~
tootie
Engineering-first culture is almost always the wrong idea. It's product-first
or nothing. The entire point of agile is prioritization based on business
value. Everything always takes longer than estimated regardless of how you
manage your project. That's actually a core tenet of agile and one that
stakeholders (and budget holders) have the hardest time accepting. Having
worked in this industry before agile was prevalent, I can assure you it was
never better than this in the past. QA as first-class is a pretty core
principle as well. The point of things like Scrum is meant to be visibility
and alignment rather than prediction, but impatient people are guaranteed to
ruin your life no matter what.

~~~
Pigo
I'm sure I don't have the wealth of experience you fine people have. But I've
been in enough teams and companies to see that whatever methodology is being
embraced, it seemed like the X factor was always what kind of people are
practicing it. If someone likes always being in meetings, you're going to be
in a lot of meetings. If you're on a team with smart people you enjoy working
with, with open lines of communication, then the rest just seems to fall into
place as long as everyone is doing their job.

Then again I never worked for Hooli.

~~~
tootie
Yeah, this is actually my same observation. High-functioning teams were
naturally agile even before it was called that. Defining and formalizing agile
practices is a way for people who've never experienced it to know what success
looks like.

------
commandlinefan
> So the developer, being a developer, pulls a couple all nighters, maybe
> works over the weekend and does get it done.

And does minimal testing, skips documentation, adds some tech debt, copies-
and-pastes code rather than doing proper code reuse - because the deadline is
the only thing thing being measured.

------
clumsysmurf
At the company I work for, our yearly performance reviews are based partially
on the metric "Complete 90% of uninterrupted development sprints with no carry
over." What I see most of the time, is developers hurrying towards the end of
the sprint to meet this arbitrary deadline, choosing the easiest path A
instead of the correct path B. Now the project has been run like this for
years, you can imagine how much tech debt has accumulated.

~~~
signal11
This is a good example of Godhart’s Law (“When a measure becomes a target, it
ceases to be a good measure”) in action.

There are better ways, but it requires enlightened management.

~~~
signal11
Sorry for the typo: it's _Goodhart 's_ Law, not Godhart.

------
bluGill
I think pretty much everybody is missing an important point of deadlines:
money. If you are not done by the deadline you are dead. Management (with
marketing) has a good idea of what will sell, fail to make the deadline and
the product won't make money in the market and should be canceled early. This
is the point of estimates: to decide early if the project is worth paying
anyone to work on. (or course once you are part way in the project sunk costs
become an issue)

Note a result of this is deadlines are not something you should come close to:
a break-even project isn't worth your time to develop, so there should be
plenty of slack in the schedule to cut into before hitting the point of no
profit.

~~~
commandlinefan
> to decide early if the project is worth paying anyone to work on.

Yes, we know that’s what you think. We keep trying to explain to you that
you’re living in a fantasy world where software development can be predicted
accurately in significantly less time than it takes to just do the work. I
understand why you WANT that to be true, but wanting something to be true
doesn’t make it true, to the frustration of MBAs all over the world.

~~~
shantly
I do think well-functioning development processes & teams, with good
integration with business is something every company wants, but very few
companies are willing to pay for, and most just _cannot accept_ that they're
opting out of what they claim they want by not paying enough, so they try to
get it anyway.

Why's it expensive? I think people who are capable of building and managing
such teams, and dragging organizations into a set of processes that truly
work, exist at a rate of about 1/1000 the demand for them. Meanwhile the
people who can discern useful practices from useless ones or good
implementation from bad are similarly rare and overlap largely with that same
group, leading to an ecosystem of development practices that's almost entirely
snake oil and wishful thinking, and where almost no-one can tell when they're
looking at one of those 1/1000 folks who've got the knowledge and skills to
make it work if you give them the authority, or some delusional schmuck or
huckster.

The best most companies can do is to learn to live with a ton of uncertainty
and work humanely and effectively with that, and few achieve even this lesser
outcome, which tends to come with its own (lower) costs in hours and less-
than-ideal predictability that many orgs just _can 't_ accept they _have to_
pay to keep things running even sort-of smoothly.

------
sudeepj
> just go talk to the stakeholders - product/sales team - ask them if the
> delay could be potentially customer losing

In my experience, sales team rarely have any incentive to help out here. They
almost always say that delay will create problems and they quantify in terms
of dollars e.g. If X is not done by this date we will lose Y dollars. That Y
number is almost made up to make things more urgent.

Actually, I have seen sales blaming lack of sales numbers on engineering
because the delivery was "too" late.

~~~
pm90
Agile works well when you’re working in a win win kinda relationship. What you
describe happens more often than I am willing to admit.

What helps here is if you hold Business Value meetings with real people
involved and try to reason relative priorities of stories. This is the fuzzy,
social aspect of Agile development but I suspect it’s really the core idea
behind the whole thing: it forces people to talk in person and empathize more,
hopefully building up cooperative relationships rather than extractive ones.

If the stakeholders continue to be sociopaths though, you can either chose to
give in and do whatever they say or lie. Both options break the spirit of the
thing. Frequently there’s a 3rd invisible option where you use back channels
to pull some influence. Which also defeats the purpose of Agile...

------
jake_morrison
There is a fundamental relationship between schedule duration, amount of work
and quality.

If estimates were all accurate, then the amount of work and the sprint
duration would be the same. It inevitably takes more work than estimated, so
something has to give.

If you constrain the duration and the scope of work, then quality will vary.
If you constrain the duration and allow overtime, then you get a mini crunch
time every two weeks. Some bosses think that people will slack off unless they
are given pressure, so they like this situation.

A better way is Kanban. It's more or less Scrum where quality is the thing
that's fixed. If the task is going to make more time than originally
estimated, either you let it take more time or reduce the size of the feature,
i.e. implement a simpler version of it.

~~~
commandlinefan
> If estimates were all accurate

then every level of management between the devs up to the CEO could be
replaced with a spreadsheet.

------
29athrowaway
This is what Steve Jobs has to say about project managers:
[https://youtu.be/rQKis2Cfpeo?t=116](https://youtu.be/rQKis2Cfpeo?t=116)

~~~
winrid
Well that hits home pretty hard. I didn't know Steve Jobs did these kinds of
interviews, thanks.

~~~
29athrowaway
Another gem: Steve Jobs on sales and marketing,
[https://youtu.be/-AxZofbMGpM?t=21](https://youtu.be/-AxZofbMGpM?t=21)

------
loopz
Talking to "product managers", managers and various stakeholders everyday, the
problem is at the times when these otherwise good people are disconnected to
the rest of the organization and have no operational clue. Then they will
demand deadlines, push dates backwards, do all sort of non-intentional self-
sabotage to the org. They might get their thing done, badly, while hurting the
rest of the organization and creating unhealthy competition. When goals are
accomplished, they often are unable to even get the value out of the thing
they wanted in the first place. These same people won't be able to prioritize
when given the choice, and basically just want it all now, again like little
toddlers, with checklists!

So what do you do? Only healthy thing is to push back, give explanations for
what is required before work can begin and have good relationships with all
parts of the org yourself. Insulate the toddlers. If they need a PM, they
gotta provide a budget.

------
viach
> We'd still be doing MVC in frontend apps if someone at Facebook didn't miss
> a deadline.

After working with React for some tine I'm not so sure the good old Mvc is a
bad thing, not always at least.

~~~
steve_g
That line stuck out for me too.

Is MVC as a pattern really all that bad for the majority of web apps?

~~~
viach
I think it depends on what kind of code mess you prefer - client side or
backend. I personally prefer to mess up on the backend, feels much more
comfortable to me to fix it up and write tests.

------
thrownaway954
deadlines exists because managers believe that the team will focus to
accomplish the goal. the reality is that _most_ managers are lousy at
estimating the amount of time a given task takes and _most_ developers are
cowards to stand up to a manager and tell them this. _everyone_ sucks when it
comes for planning for the unexpected. in the end, all deadlines do is cause
unnecessary stress and disappointment for _everyone_ involved.

i'm no different and have been caught up in this game more times than i can
count, yes, i suck too. later in life i've come to determine, that whatever
deadline i have in my head, i just extended by a factor of 2.5. if i think it
will take a month, i say two and half months. that is more than enough time to
not only get the project done, but also deal with anything that crops up
unexpectedly. my serenity is worth more to me than looking good or being a
hero.

~~~
HereBeBeasties
IME, if the manager is primarily coming up with the estimates, rather than the
team, you're doing it wrong. (And are doomed to an eternal cycle of blame,
stress and lack of trust.)

~~~
commandlinefan
You don’t know how this game works. Of course the devs come up with the
_initial_ estimates - they have to, or else it wouldn’t be possible to blame
them when they end up delivering “late”. But those initial estimates are
always “negotiated down” to whatever looks best on the manager’s quarterly
bonus review - they might not be brilliant at designing products or
scheduling, but they’re geniuses when it comes to re-stating things so that
they sound different but are actually the same until you finally get tired of
arguing with them (I mean, it’s tricky to argue with somebody who decides
whether you get paid or not) and agree to whatever they say and just
disappoint them later.

~~~
HereBeBeasties
We tend to try to do any vaguely longer term/important estimation as a team
exercise, which ends up with people talking each other's estimates up, not
down - you explore the problem space more effectively as a team and a lot of
"but what about X" stuff comes out of the woodwork then.

If you have a manager who sets your team up for pressure and failure by
artificially revising your estimates down, without cutting the scope of the
work, then personally, I would find a new manager. Source: Am a manager.

------
Arrezz
I have been struggling with scope creep for deadlines at my work, I am a
junior dev and I have a product owner that means well but changes requirements
several times and increases scope mid sprint. How do you push back against
this in a nice and reasonable manner?

~~~
commandlinefan
There’s an old saying: “people will forget what you said, people will forget
what you did, but people will never forget how you made them feel.” It’s
supposed to be inspirational, but it’s actually depressing because it’s so
accurate. How do you put it into action as a dev? Never argue. Ever. If you
argue, you’ll lose the argument anyway (you have no power), and they’ll just
remember you as the person who was argumentative. If they say, “can you add AI
to this product by Friday?” You say, “yeah, sure, let me look into that.” In a
sane, rational, just world, everybody would be working together on a shared,
common vision, and they’d realize that by giving you herculean tasks with
impossible deadlines that nobody could achieve they’re actually hurting
themselves as much as (if not more) than they’re hurting you, but the grim
reality is that that isn’t the world we live in. If they add scope, just shrug
and accept it. Don’t kill yourself with nights and weekends trying to meet
their deadlines either - just say, unapologetically, “I was able to do ___ and
I’m still working on ___”.

------
mlthoughts2018
> “ There is another problem with locking your sprints. Say you get a new
> customer ask, it's a potentially trivial but low priority bug. The developer
> could fix it in a day. But you follow The Process TM, the task gets added to
> your team's backlog, maybe gets picked couple sprints down the line and does
> get fixed. But you lost the opportunity to delight the user!”

Nope. That context switching will cost you more on average than sticking to
the process. And most often you’ll be wrong about the time estimate, or the
customer will be wrong about actually wanting that feature, etc., making the
context switch even worse and more costly.

------
ChrisMarshallNY
I tend to take a fairly dynamic approach to design.

In many cases; especially where you have heterogenous projects, done by multi-
disciplinary teams, dated milestones are pretty much required. You have to
have some thing, by some time. I worked like that for many years, as part of
massive, multi-national teams.

But these days, I have the "luxury" of generally working alone, or as a member
of a casual open-source team that doesn't have any specific deliverable
deadlines.

What I do, is define what "done" looks like, and set some very fuzzy
milestones. At each of these inflection points, I reexamine the work I'm
doing. In some cases, I decide to bin the whole effort, and either rewrite it,
or simply scrag it, and move on to the next in the FIFO. In other cases (less
often than I'd like), I am ahead of expected schedule, or the functionality of
my work is better than expected. Boo-Ya. Go Me.

The important thing for me, is that I have a solid idea of a deliverable. It
may not be associated with a date, and may be subject to revision, but it
exists. At some point, the project needs to be released.

That may require some compromises, and it will require some tedium, like
signing and provisioning, as well as producing marketing copy and graphic
assets. That's part of what you need to do to have shrink-wrapped releases.

A lot of times, I can put off some of the sexier stuff for a 1.1 release.

------
terryf
The essay is just a long winded way of saying the quote from Eisenhower:
"Plans are worthless, but planning is essential"

Which is of course a short winded way of saying that the article makes a lot
of sense. We for example have sprint goals - these are things that the team
commits to actually getting done during the sprint. Then there are tasks in
the sprint which may or may not overlap with the sprint goals and may or may
not get done during the sprint.

It's always about trade-offs.

------
saas_sam
Reading HN comments makes it sound like engineers think they're the only ones
in a company who have to deal with deadlines. It's kind of hilarious. Go ask
your sales team how they cope with hard deadlines of closing a specific dollar
amount every quarter based on the presupposition that 1. the product delivers
what it says without major issues, 2. competitors don't come out with feature
or pricing changes that blindside you, 3. other departments (marketing)
delivering them enough interested contacts to talk to... and 100 other things.
Not to mention the main "stakeholder" in play for them -- the customer -- is
ACTIVELY trying to deceive the salesperson in order to get the best deal for
themselves. Like, they will literally lie and say they intend to sign a
contract with you by end of quarter to get the salesperson to go the extra
mile for them. With zero intention of actually following through... Yet the
sales team gets it done every quarter. And if they don't? 2 bad quarters in a
row = expectation is you're out of a job.

~~~
crashedsnow
I don't think the main point being made is that deadlines are a PITA, I think
it's that the trade-off is unmeasured. Successfully meeting a sales deadline
looks the same as signing the same contract after the deadline (other than the
deadline), but the argument for deadlines in software being bad is that they
materially erode quality and long term viability (shortcuts, tech debt, bugs,
usability). The product delivered within the deadline is materially worse than
the one delivered after. The problem is that it's hard to attribute these
issues to "deadlines" although the intuition is that they are a major cause.

~~~
saas_sam
> Successfully meeting a sales deadline looks the same as signing the same
> contract after the deadline (other than the deadline)

This is so far from the truth. I encourage you to spend more time with your
sales team and even your stakeholders who are buying $100k+ software from
vendors. There are so many parameters of a deal that go beyond contract
signature date. Deliverables, SLAs, roadmap commitments, length of contract,
legal definitions, opt-out conditions, payment terms, pricing, and more. Deals
aren't just "on time" or not, they vary greatly in terms of quality. And that
quality largely determines your company's ability to hire more engineers. Or
fire them. ;-)

Bad deals happen when you're down to the wire and have to get it done on time
or people will lose their jobs. Not unlike bad software. Work in the real
world has deadlines. The people doing the work will always advocate for the
loosest deadlines (or none at all, as is often the case with engineers). The
people who need the work done will always advocate for the fastest turnaround.
Without these checks and balances, the work just does not get done fast enough
or well enough to stay competitive.

------
gregdoesit
The post is solid on criticising sprint deadlines, but doesn’t give many
suggestions on what works better. Except for this:

> Another idea is to experiment with more elaborate probabilistic ways of
> setting shipping estimates rather than gut based estimates.

In my experience, teams setting estimates and holding _themselves_ accountable
is a great way to go with multiple benefits. This is why I’m a big fan on
estimating software projects with a few ground rules [1].

Sprints and deadlines could be a tool to get here - as with a bunch of things,
context, people and culture matter just as much as processes do.

Iterating and learning from iterations is how good software is produced, with
a team that is motivated and continuously growing.

[1] [https://blog.pragmaticengineer.com/yes-you-should-
estimate/](https://blog.pragmaticengineer.com/yes-you-should-estimate/)

~~~
hcarvalhoalves
One estimation method I found good and worked at a risky project in my job
(involved a regulator, they love deadlines) was:

1\. Do the usual breakdown of tasks and point game to get relative difficulty
estimates

2\. Calculate the std dev points for each task instead of just averaging. The
assumption is that this is valuable information about how uncertain developers
are about the task, so we don’t want to throw it away.

3\. Create happy-path and worst-case scenarios considering +-1sigma and
+-2sigma

4\. Prioritize tasks by deviation, to remove the most uncertainties at the
beginning of the project

With this you start w/ a more realistic view of the uncertainty of the
project, and it’s supposed to converge to the avg as the project goes.

------
GoToRO
Deadlines are for managers. If developers need to be aware of the deadlines
then the managers are not doing their job.

~~~
keyP
I don't quite agree here, developers need to have an idea of what they're
working to so they can manage their own implementation time. If you don't make
developers aware, you put too much control in the manager's hand which isn't a
good thing here (unless you're referring to a developer lead but even then,
individual developers should have an idea of when they need to complete by).

------
bordercases
Out of all of the factors that could potentially cause poor software (along
with the "software disenchantment" as discussed in another recent thread),
deadlines stand out as the most concrete and immediate driver of the decisions
I take that may result in poor software quality. At least it's the one I can
consciously acknowledge as influencing me more than once.

I'll have to improve my efficiency at developing software anyway, but this
article has given me more confidence that I can pace the promises I give to my
clients as to when features will be delivered.

------
shrimpx
This article has beef with artificially imposed internal deadlines, not
deadlines in general.

A deadline can be for a ton of legitimate reasons, like delivering a signed
contract by the agreed upon date.

------
taf2
The only deadline I set are for customers. That is either internal customer
because they asked can it be done by x day and I either answered yes or no. Or
an external customer because I got on a phone call or someone in sales/support
indicated an opportunity or at risk customer.

Ok fine and sometimes I set deadlines because I’m like OMFG how have we not
done this yet. Let’s get it done by x day. For example upgrading framework x
to latest version y

------
indigodaddy
What was so wrong with the author’s chosen article title that it had to be
manually sanitized? I get that HN admins may not like the snark, but it’s the
author’s title, it’s his snark, his tone, his article, and by sanitizing the
title, you are basically making an editorial decision on his article.

~~~
dang
The HN guidelines call for changing titles that are misleading or baity. That
one was baity, so we replaced it with representative language from the article
body.

Generally we err on the side of preserving articles' original titles and
favoring authors above everyone else! But not when the title breaks that
guideline.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
s17n
If it weren't for deadlines I would never do anything, pretty sure I'm not the
only one.

------
walterkrankheit
This goes for external (outgoing deadlines) as well as for internal. When you
don't tell the world to expect exactly this on THIS day, they won't be
unhappy. They'll simply be happy when it happens - and happens correctly!

------
pm90
This is a very well written article. TLDR: don’t be too steadfast with sprint
deadlines, keep them fuzzy and understand how missing them will impact
stakeholders before committing to working over the weekend to meet them.

Many Scrum Fanatics, especially the ones holding various Certifications, will
scream bloody murder at the idea of tampering with their precious sprint. But
the sprint is a fucking artificial construct that was meant to be fuzzy. If it
isn’t good at representing how software is delivered you can either change the
sprint or try to force your team to sync with it.

Unfortunately I’ve seen the agile processes be misused in many ways because
it’s inherently so fuzzy and ill defined. It doesn’t really make much sense to
bikeshed over minutiae but to focus on the outcomes and tinker liberally with
the process to suit your teams style. Just keep your stakeholders informed of
the changes.

------
adrianmonk
Well, they are user-first... _if_ you look at humans as resources and managers
as users.

------
crmrc114
Part of me wonders if the Author works for Amazon, because that sounds totally
like Amazon.

------
maury91
I don't want to criticize but you spell critic wrong on the first period:
"crtitic"

Pun intented.

------
jillesvangurp
I've done a lot of scrum like projects in the past 15 years. I say scrum like,
because absolutely nobody does it "by the book". And if you do, you are doing
it wrong because you are being rigid and dogmatic. Every agile manifesto
signee will tell you that (I've heard several of them talk about this). I meet
a lot of "you are doing it wrong" types. You know the type. Self styled
agilists that throw the book at you and seem to love having lots of post its
stuck on their walls that provide the illusion of progress in the absence of
exactly that.

These days, I prefer Kanban style processes for several reasons. Most
importantly, the practice of ignoring new requirements for two weeks (aka.
doing a sprint) is not sustainable in most projects I'm on. It's just not a
thing. Stuff changes all the time, deal with it now instead of in two weeks.
Another reason is that I prefer continuous deployment and automating PM
reviews away so we don't block shipping stuff over somebody's opinion. Sprint
deadlines are utterly meaningless from a release point of view if you release
multiple times per day. If it's better than what we have then merge and ship
it ASAP. If it's obviously broken, obviously fix it now ASAP and don't wait to
have a meeting about it in 2 weeks. Do that multiple times per day. Have
responsible processes to ensure bad stuff gets caught before it is merged. It
works. Shipping early means you catch stuff early and get feedback from real
users rather than opinionated PMs and managers detached from reality. Also
people stop throwing things over the fence when they are confronted with the
consequences of what they did right away. It forces them to think end to end,
a quality that I find is often missing with engineers because they are being
shielded by layers of management.

Finally, I work with remote developers a lot these days. Anything involving
telcos or meetings is downright painful; especially if you add language and
cultural barriers. Having full day scrum ceremonial crap is just not something
I have a lot of patience for. Doing that over a hangouts meeting is just an
exercise in futility.

Kanban of course does not stop you from having regular planning meetings,
estimation sessions, retrospectives, etc. All that can still work and if it
adds value to your team, by all means keep on doing that. IMHO it makes less
sense in distributed teams and those require more asynchronous approaches. I
find decoupling what we do from when we do it in a Kanban style to be helpful.
If the backlog is getting too short, add more stuff and add it in the priority
you want things fixed. Don't allow your team to lose focus (aka. multi task)
and set concrete goals. Have breakout meetings when things need clarification.
Don't pile on too much work in too much detail until it is ready to get done.
Doing CD means you can specify changes in terms of what you have in production
and how you want things changed. I find that injects a sense of reality that
just stops a lot of BS. from ever happening.

------
hyfgfh
More 4 year to make Mickey Mouse public domain or the law extent the period
again.

