
Deadlines and sprints are bad for you - ingve
https://medium.com/@niant/why-deadlines-and-sprints-are-bad-for-you-7ee87be5d0f0
======
spenczar5
I think the author misses what the purpose of deadlines is. They are contracts
between organizations for when software will be available, which are used for
other organizations to make informed decisions without needing very tight and
constant communication. They're analogous to SLAs in service-oriented designs.

In a moderately large (say, 500+ employee) organization, deadlines are
essential to get anything done. Suppose, for example, you're overhauling a
billing system, making international tax calculations simpler. The finance
team is making a hiring decision: they need to get tax stuff calculated before
the end of the year; do they need to find consultants to help them with this,
or is the software going to be ready in time?

If your answer to them is "I can't tell you, we just do stuff on the kanban
board and don't think about deadlines," they're (1) going to be less than
thrilled with you, decreasing trust, and (2) unable to make their decision
effectively.

I don't think "there's only "stuff" to be done" is an adequate alternative to
deadlines and sprints if it doesn't address the reason organizations use those
tools. They're primarily tools for predictability and scaling outbound
communication about progress; I think the author mistakenly believes they're
supposed to be motivational tools. They're sometimes misused that way, for
sure, but that's not the whole picture.

~~~
lima
No, the idea is that you don't set hard deadlines for the team - they're
pointless. It results in unnecessary stress and work won't get done any faster
(maybe in the short term, but it's unsustainable).

Either the deadline is too short and your team has to work overtime, or it was
too generous and you lose efficiency.

The project manager, of course, still needs to be able to make an _estimate_
according the his team's velocity, which he can then communicate to other
business divisions.

See: [https://apenwarr.ca/log/?m=201712](https://apenwarr.ca/log/?m=201712)

~~~
Terretta
In fact, Scrum changed the word “commitment” to “forecast”.

[https://www.scrum.org/resources/commitment-vs-
forecast](https://www.scrum.org/resources/commitment-vs-forecast)

 _“One of the most controversial updates to the 2011 Scrum Guide has been the
removal of the term “commit” in favor of “forecast” in regards to the work
selected for a Sprint. We used to say that the Development Team commits to
which Product Backlog Items it will deliver by the end of the Sprint. Scrum
now encourages the Development Team to forecast which Product Backlog Items it
will deliver by the end of the Sprint. It may seem to be a simple wording
change, but in fact there are strong reasons behind it.”_

Pretty sure the Scrum folks are aware of needs of enterprises and their
deadline addiction.

~~~
lima
Yes - sprints can be a great estimation tool as long as they aren't mistaken
for a deadline or performance measurement.

In my opinion, it needs be more like drawing a (rough) "this is how far we
will get at the current velocity" line somewhere in the sorted backlog, rather
than a fixed set of tickets that you expect to get done.

Popular tool-driven "agile" workflows where you move tickets into a particular
sprint, followed by the admission of defeat at the next sprint planning
meeting when you failed to complete all of them, reinforce the idea of
"commitments" rather than "forecasts".

------
sklivvz1971
The author deeply misunderstands Scrum. They also misspell it as SCRUM but
that's another story...

Sprints are _timeboxes_ and not deadlines. Stuff is done at a "normal" pace
and it either fits (or does not) in that timebox.

Fundamentally, it does not really matter in itself. Noting down whether the
estimation was correct or not, though, is important.

The whole point is that a team is supposed to get more _predictable_ over
time. They learn how to estimate better, and having a fixed "box" to fill is a
very easy way to do so.

So: Scrum is a "scientific" way to reach a sustainable pace ("scientific"
meaning: based on objective, repeated measurements).

This is not to say that Kanban does not work. It's just way way harder to do
right, because measurements of how good a team is at having a sustainable pace
are not as intuitive and are easy to ignore for teams -- and ignore it they
do, unless they are very well disciplined.

But all of this is well know in the world of Agile, I remember talking about
this ten years ago. Perhaps an agile coach would truly help this person.

~~~
captainbland
As an aside, "sprint" (which obviously implies moving at the greatest speed
possible for a human on foot, pushing themselves to a point which cannot be
sustained for long distances) is pretty poor terminology for something meant
to represent something happening at a sustainable pace. I'm sure I'm not the
first or last person to point this out, though.

~~~
glhaynes
When I first heard the term “sprint” I thought it was surely being used so
they could later make some point like “since sprinting is of course
unsustainable, we introduce weeks of relaxation between them”... Nope!

~~~
dec0dedab0de
Me too. I actually proposed 3 day sprints at work Tuesday-Thursday. With
Monday and Friday being for meetings and nonsense. They laughed at me like I
was joking.

------
kerpele
I completely agree with this article. I've worked in scrum and kanban teams
and also lead both kinds at some point. To me kanban is by far the better
option for the exact reasons outlined in the article.

The point is that deadlines are bad for the people doing the work when they
can't influence the amount of work. Not that deadlines should be removed
completely, but they should be moved to a level where the amount of work can
be influenced, namely project/product management. They should then, completely
independently from the development team, adjust the backlog and/or deadlines
in case the project schedule starts to slip. If the deadlines are needed
because there are doubts that the dev team is not working as hard as they
reasonably can then there are bigger issues that any project management method
cannot fix.

~~~
kokokokoko
I find it interesting that in other building projects, like in construction,
almost all of the pressure and responsibility for meeting deadlines is placed
upon the project management. Not the ones doing the direct labor.

The reason for deadlines in software, they way they are used today, is simply
to get more hours out of a week from a software developer. Unlike in
construction, software developers do not get paid hourly, nor do they get
overtime pay. Abitrary micro deadlines coerce developers to work extra hours
which makes their cost per week for amount of work to go down.

In construction, if they made up an arbirary micro deadline that was too
short, the workers would get overtime pay at 1.5x their normal rate. Plus the
additional hours. So for them, a too short deadline makes their cost per week
for amount of work to go up.

We debate endlessly about all these estimates becase we're all pretending its
about things that its not. Its almost completely based upon getting more hours
per week per developer, as it makes the labor less expensive.

------
zdragnar
Kanban is appropriate for maintenance work, but I don't know of too many
companies that will invest in a project without at least a general idea of
"when will it be done?" and "how much is it going to cost to complete?"

Sprints are about accountability. Estimates are supposed to change based on
new information, the understanding being that things change- priorities,
desired outcomes, designs, sick time, and so forth. Short sprints are designed
to surface new information as quickly as possible, rather than waiting until
the project is 90% "complete" timeline wise but only 40% effort wise.

The Dilbert comic shows a false equivalence; management's expectations are
simultaneously deadline, cost and feature driven. There is no management
technique that can account for all three of those; not even Kanban.

~~~
doctorpangloss
> management's expectations are simultaneously deadline, cost and feature
> driven. There is no management technique

I suppose when the product you're making is, say, advertisements, because you
merely arbitrage, you can satisfy all of those at the same time.

The more interesting point of view is, "The kinds of software businesses you
want to get into require no management at all."

~~~
zdragnar
It is entirely reasonable for management to set an expectation for two of the
three between deadline, cost and features. The whole point of agile, as I
understand it from "Uncle Bob", is that as professionals, developers are
expected to provide information and guidance based on their professional
opinion. Not only does agile help ensure accountability, but also acts as a
continuous feedback cycle for developers to provide new context, information,
and ideas as they surface.

I did in fact work at a company that was something of a dev shop for marketing
agencies, and it was pretty miserable at times, because they inevitably
expected contracts that held to all three. Cost was typically the one thing we
could get them to budge on as new information came up (i.e. this necessary
feature wasn't accounted for) though who actually ate the cost depended on
negotiations.

I don't think I would enjoy working in a business with no management at all,
to be honest. There are things that I am good at, and there is a definite
perspective from which I view things, and the same applies to good managers,
and there is not a complete overlap between the two. On top of that, they deal
with problems that, often as not, I'd rather not have to worry about.

------
dasil003
Something I've learned in startups is that you've got to have immediate short-
term goals and keep pushing towards them relentlessly. In bigger companies
with stable revenue the natural sense of urgency is lost, and you can often
spend endless time in analysis paralysis or perfecting inconsequential
details.

Having milestones and deadlines in whatever process you choose to implement is
very important to keeping everyone's eye on the ball. The problem comes in
when there is not flexibility for the necessary tradeoffs, and it becomes a
death march. This is management failure plain and simple. Taking away
deadlines may superficially be better for people's health, but it doesn't help
the company be more effective which in the long term could potentially lead to
everyone losing their job which is ultimately way more stressful.

~~~
wwarner
Exactly.

------
pwm
Regarding creativity what I found over my time writing code is that you need
time to do deep thinking. That’s the only way I know of to harness complexity
successfully. Here is the twist: you don’t know how much time you need doing
it because you don’t know when realisations emerge. The problem with deadlines
is that they create stress and stress is the enemy of deep thinking. The funny
thing is that while a deadline can be entirely accurate in estimating the
amount of deep thinking required for a task, the mere presence of it prohibits
achieving the relaxed state of mind that is required for deep thinking.

~~~
adrianmsmith
Further, having a meeting e.g. at 10am every day (daily standup) means that
it’s unlikely you’ll get any deep thinking done during the morning, so that
just leaves the afternoon. Adopting daily standups at a fixed time as dictated
by Scrum reduces your team’s deep thinking time by 50%.

------
pier25
This reminds me of an anecdote in the book "Thinking Fast and Slow".

A set of experts (including the author of the book) sat down to complete an
education project (like a program or something). They estimated it would take
them 1 year, at the most. It took them 7 years.

It is extremely difficult to estimate the needed resources to solve a problem.
Especially a problem you have never solved before.

------
jakub_g
Another point I've noticed about sprints: It usually creates a problem of "uh
we have too much content in the sprint compared to available resources, but it
can't be reasonably split into smaller pieces" before the sprint and "uh we
didn't deliver what we've overpromised" after the sprint, and people being
stressed of tasks always moving from one sprint to another.

Sometimes you have things to do with high estimates (many days) that can't be
reasonably split into smaller pieces (the "you don't know what you don't know,
and what exactly has to be done" situation). But still, it doesn't look good
to put a too highly estimated task in the sprint, so you instead split it into
fake "Do X, part 1" and "Do X, part 2", which is basically creative accounting
to satisfy the tooling.

In that situation, the Scrum theory says to create a "spike" to figure out
what to do, and then create the proper stories, but if often doesn't work this
way in real life (in particular, if you need to discover and then deliver
ASAP, this doesn't help at all; also often you're in "continuous discovery"
mode, i.e. you do stuff, discover what else is needed, and so on, until you're
done).

Edit:

A solution to overpromising is to create "bonus" tasks that are kept in the
backlog and not put in the sprint, but this lowers the incentive to take them
since they're not formally in the sprint (and also who's taking big out-of-
sprint items while there's unfinished small stuff in the sprint?)

Adding all the unpredictable things happening during the sprint, basically the
sprints are creating more problems than they're solving.

The only good things about them are:

\- SLAs for other teams for higher level planning

\- a way of saying "no" to incoming requests ("sprint content full, sorry")

------
snidane
Arbitrary deadlines are unnecessary when there are better ways to manage
progress.

You can adopt the product delivery point of view and track progress on
something like Kanban board. You track actual deliveries of actual items when
they get done and on each time box (eg. 14 days) you open the board and try to
understand blockers by looking at kanban columns where items are piling up. If
a column grows beyond certain size (work in progress) you should start
investigating the reasons evsn sooner. This way you either keep delivering or
not and in that case you use periodic sprint meetings to understand why not.

Unfortunately what happens in organizations is that over time the organization
based on tracking progress of delivering items or products shifts to tracking
work or time workers spent working.

So on periodic 14 day meetings instead of asking questions 'why hasn't this
item been delivered yet?', 'what is blocking the progress in delivery?' or
'why are these items piling up in that column?' you get question like 'what is
everybody doing and what they plan to do?', ie. typical status report and
micromanagement.

The focus shifts from items delivered to work done by people. As the team then
loses focus, managers start to impose deadlines.

It is another case of treating symptoms instead of looking at the causes.

------
codingdave
> The tools the development team has for combatting the deadline are
> unsustainable

This misses the key power of the dev team in Scrum - to say "no":

"Can you do that quicker?" No.

"Can you cut corners?" No.

The dev team may not be able to change features or scope, but they absolutely
can tell the product owners to either change things, or accept what the dev
team says they can do in the allotted time.

------
gaucheph
It's like someone that's never painted in their life giving estimates on how
long it'll take to paint the interior of a new house based on the total width
of all brushes that'll be used and the total area to be brushed. Even if it's
small and you'll have a lot of brushes, there could be lots of detail work
because of windows/doors/etc.

Who would have a better idea? Probably someone who knows how to paint.

------
Insanity
I actually like deadlines. They challenge me to get my work done and somehow
that appeals to the competitive side of me I suppose.

It has been like that since I studied at uni and it continued like that
throughout my career.

So to say they are bad for me seems silly. Different people work in different
ways. :)

------
je42
ok, it looks like this guy has never worked in a working SCRUM environment.

> Suggesting that meeting a sprint by cutting corners is a thing. Yes, in bad
> scrum implementations.

SCRUM and KANBAN have both pro's and con's.

If you can't implement SCRUM in a good way, you will also have a problem with
KANBAN.

There some good discussions about on online like
[https://fenix.tecnico.ulisboa.pt/downloadFile/3779576751814/...](https://fenix.tecnico.ulisboa.pt/downloadFile/3779576751814/Kanban-
vs-Scrum.pdf)

> How much effort goes into each task?

"how large is the story compare to other stories we had before?" is a better
question.

Refinements are a crucial meeting to keep the team aligned and make sure they
can collaborate on user stories and help each other.

> How many sick days are there going to be in the sprint?

you don't plan for that.... you only plan for things you know in advance
(vacations etc. ) Capacity planning takes less than 5 mins in our sprint
planning. not sure where the problem is.

> Is someone leaving or joining the team?

Yep, very important to discuss. in any context (regardless if you do SCRUM or
something else).

> people end up confusing sprints to deadlines

End of sprint is a deadline according to definition:

> the latest time or date by which something should be completed.

Because the team thinks it can complete the sprint's stories by the end of the
sprint.

It is important to deliver value to customers in a timely manner. This is to
lower the risk and prevent multi month/year projects that never go to
production, etc.

Sprints help you with structuring your process to achieve this goal. Please
keep in mind, this doesn't free the team from thinking how to get the value to
the customer as soon as possible. (You can have sprints and never go to
prod...)

> trigger the fight or flight response

If you have people in the team that have that kind of reaction ? Talk about it
in a retro, and improve.

SCRUM requires a "save" environment, if you don't have one, almost no sane
process will work.

if you don't meet your sprint goals. talk about it in the retro and improve as
a team.

Consider, pulling in experience good SCRUM master's the good one's can help
how to improve your procceses.

One thing to keep in mind, if the SCRUM is only a thing of one particular
department and/or is not fully accepted by the CEO and board, you have some
side effects where situations can be quite disappointing and stressful.

however, the scrum master and PO can help sometimes in these situations. If
they can't the SCRUM process will be bypassed by people outside (like the CEO)
and hence it undermines the process and makes it less effective.

~~~
massivecali
There's nothing about the scrum process that helps me, as an engineer, to work
more efficiently. I work at the same pace regardless of what fictional story
points are assigned to a task. The entire charade is only for middle managers
to communicate up the chain what is happening. Velocity can be massaged so
easily that it is a useless metric.

~~~
welly
If story points are fictional then that's not the fault of the process, it's
the fault of the person who made the estimation.

If you've been working as a developer for any length of time, you should know
roughly how long a particular task is going to take you.

~~~
massivecali
I know how long it takes me to accomplish a task given spherical cows. Since
nothing is stable (test environment, content, other fires), the story points
are irrelevant.

------
bitwize
But are they good for the COMPANY?

That's what matters.

