
You don’t need standups - jxub
https://medium.com/@jsonpify/you-dont-need-standup-9a74782517c1
======
ravenstine
One thing I don't like about standups is that they can create a false sense of
either blockage or someone being ineffective at their job. For instance, there
have been many times where I've worked on a task or a set or related tasks for
weeks or months, simply because the tasks required a lot of forethought and
careful planning. There were times I somewhat dreaded standups because I knew
that I'd say that I'm doing the same thing I'd been doing for the last several
days, like a broken record. I don't want to have to say "Yup, still workin' on
those bugs" every morning. When shit's fixed or I've completed a feature, _I
'll let you know_.

In fact, all I like about standups is seeing my team mates once a day. Besides
that, there's almost no upside. Literally everyone can read the project board
to see what we're up to. If you're really so curious as to what everyone is
doing, why not just look at that?

~~~
chomp
"working on bugs" is not a great update, it's opaque and doesn't help your
team or your leader get a picture of what you're struggling with.

"I tried this and this and measured this latency from the application and
suspect it's a race condition, I checked this code and feel like I'm on the
right track, and if someone wants to take a second set of eyes on my bug I
would appreciate it" is a much much better update. Stand ups are about
communication with your peers. Having to hunt down tasks you're working on and
reading through each task can create an unnecessary mental load that can be
solved with a single 1 minute "ESPN sportscenter edition" summary of your
current issues.

However, blockers do create a sense of ineffectiveness. Especially on small
workload teams where task swarming doesn't net too much benefit. "Hey I am
still waiting on $vendor to configure their service" or "Still waiting on
netops to tag $port for vlan blah" or "Procurement put in a PO for $hardware,
still waiting on it", there are times when we are waiting for something, and
there's nothing able to be done currently. Especially when the immediate tasks
are already doled out and your leader doesn't want to pull more work into the
current sprint. Subsequent tasks could be too large or complex to be pulled
in. Current tasks could be unable to be broken up any further, to which I have
to say, pair program until your blockers dissipate. We do this at my current
job, and it really creates tangible benefit.

As for TFA's bulletpoints on why sprints can be bad, most of their arguments
are bunk except for this one:

> 4\. Extroverts thrive at stand-ups, planning, and retros.

Not everyone is great at self-selling, and people who move up in the company
are the ones who hype their personal brand, not necessarily those who are the
best at their roles. I don't know how to solve this as it's a personality
issue, but I do think it can be a problem for a lot of businesses and teams.

~~~
some_account
What if I don't want a team mate to look at something I'm working on? What if
I just want to focus on building, not explaining and sharing?

The current trend of "agile" is just another form of micro management. It's
not good for the programmers at all, it's only good for product owners and
team leads who are coordinating resources. Because it's micro management. We
just call it something else now.

It forces developers to share every mistake they make, it makes them share if
they are thinking incorrectly about something, it makes them easily
replaceable.

Let's just stop pretending it's good for the programmers, alright?

~~~
kerbalspacepro
1\. Agile is not personally great for programmers.

2\. Agile is good for managers.

3\. Managers run the business and make sure it exists.

4\. Programmers need the business in order to have a job.

5\. Agile is therefore good for the business,

6\. And therefore Agile is good for Programmers, though not personally.

~~~
crazypyro
I would disagree with almost every claim on this list.

~~~
kerbalspacepro
I don't really have that strong of an attachment to any specific one of these
claims. I was just pointing out the logic of the parent comment is very
narcissistic (without saying as much).

The logic falls apart when you look at different individuals and different
companies. For example, if your company is very political then what is good
for managers very likely is not good for programmers. If your company focuses
on teamwork and has a strong one-for-all;all-for-one culture, then whats good
for managers probably is good for programmers.

------
DanielBMarkham
I always upvote these things, not because they're right. Because they show
common misunderstandings about Agile. Agile is so simple and easy that the
development community continues to screw it up. It's important to understand
how.

According to the author, standups are something companies require developers
to do to report about what they're doing. Many times they can take more than a
half hour.

That may be true, but the purpose of standups is that the team requires one
another to get together and talk about how to move the project forward. It's
not about what you did. That's a status report. It's about how you can help
one another.

If you can self-organize, effectively communicate, and help one another as-
needed without standups? Don't do them. Easy. There's no magic requirement
that you have to. What we've found over the years is that if you give it a
name and a time, at least you have a way to talk about whether it's working or
not. Other people can drop by to help out. But if that's too formal for you
and you don't need it? Stop!

Standups remind me of brushing your teeth. When they're working well, it looks
like nothing of value is happening. Five minutes and people tell jokes and
leave. It's when they're misunderstood as something else that they become
useless and painful. Had to throw a SM out of his own team room once because
he kept using standups as an opportunity to play "What's your status?". Nobody
cares about your status. We care about how the entire team is working. Have
some down time? Tell us you're free and then go play tennis the rest of the
day or something. It's not a management, outside-in meeting. Just the
opposite, in fact.

I love these articles because they remind us that the goal is what's
important, not the ritual. Unfortunately, people get the two conflated,
usually due to a lack of multiple-team/org experiences.

~~~
tejaswiy
That is just bullshit though. I don't find value in anything that agile
offers, can I just throw it out entirely by your argument?

Standups - You can simply claim that, hey you don't want to do standups, don't
do standups but if you take a concrete implementation of Agile, say scrum for
instance, it specifically asks each person in the team to answer:

"What did I do yesterday that helped the development team meet the sprint
goal? What will I do today to help the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting
the sprint goal?"

These questions are effectively a way lay out a very clear path for management
to basically micro-manage developers and they add pressure on developers to
come up with some contrived explanation to make it sound like their day was
productive. Hardly builds any trust when your work is being supervised and
judged by a team every single day even if the goal of the meeting is not to do
so specifically.

I can go deeper into each individual process that agile variants impose and
take each of them apart. I have nothing but spite for this godforsaken
process, the only thing it's good for is to give management an illusion of
control on software development process.

~~~
mattmanser
If you read the agile manifesto and then you look at scrum, it feels as if
scrum has nothing to do with agile. It seems to breaks every rule.

Scrum is processes and tools over individuals and interactions, by its very
nature.

Scrum is comprehensive documentation over working software, because you have
to map everything out.

Scrum is contract negotiation over customer collaboration, by allowing
management to effectively rule scrum, scrum masters are _always_ management or
reporting to management, so devolve into contract negotiation by proxy.

Scrum is following a plan over responding to change, again, by its very
nature.

It's the most odd thing I've ever seen, that somehow scrum came out of agile
and literally got it all backwards. There's even certifications on _how_ to do
scrum, which is utterly stupid when you read the 12 principles, some choice
scrum oxymorons:

 _trust them to get the job done_ \- nope, we don't trust you, follow these
scrum rules you oiks

 _simplicity is essential_ \- but we've got all these formal rules for you to
follow

 _working software is the primary measure of progress_ \- no, actually, how
many sprints have been successfully completed?

 _the best architectures, requirements, and designs emerge from self-
organizing teams_ \- but we're not going to let you self organize, you must
follow these scrum rules

~~~
KZeillmann
Scrum is all about implementing a system and then adapting it over time to fit
your needs. It's all about having the team figure out for itself how to
organize. It's not a rigid set of requirements. It's a set of suggestions
about how to begin implementing the system, and then trusting the team to
figure out what to adapt and what to cut.

~~~
mattmanser
That's not how it's presented in real life.

Read something like this:

[https://www.mountaingoatsoftware.com/agile/scrum](https://www.mountaingoatsoftware.com/agile/scrum)

All about what has to be done, with a formal role of scrum master.

Phrases like these brook no adaptability:

 _On each day of the sprint, all team members should attend a daily Scrum
meeting, including the ScrumMaster and the product owner_

 _on the first day of a sprint and during the planning meeting_

 _Another activity in Scrum project management is the sprint retrospective at
the end of each sprint. The whole team participates in this meeting_

Management take Scrum as a set of rules to follow and then use it to micro-
manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn
in to daily justify your worth.

------
vfc1
Standups always felt to me that they had a core negative message to
developers.

It's not about communication at all. Its about control, its about saying:

We don't trust you.

We are going to check on you to see what you are doing, every single day,
because you are not a responsible adult and need constant surveillance.

Its also about putting constant psychological pressure on developers, to make
sure they complete the tasks as soon as possible, and move on to the next task
in the list.

Even if developers know that some refactoring is absolutely needed or this
production issue needs a closer look because something strange is going on,
developers don't have the autonomy to just do what they know needs to be done.

Everything needs to be pre-approved by a non technical manager and assigned a
JIRA or equivalent.

Looking back, to me its clear that I resented standups, they made me feel like
I was being treated as an assembly line worker.

~~~
zmmmmm
Not really a fan of standups either, but I want to express a counter point:
developers consistently over-estimate their understanding of the problem
domain they are working in and the wider context it sits in. That is yes,
managers don't "trust" developers - but not in quite as negative a sense as
you think. There is a positive aspect of supporting the person, ensuring they
are connected to the right resources to succeed and stopping them getting
stuck on things that don't matter.

I have a small team of devs and I consistently find that given task X they
will get stuck and end up spending a lot of time on small subpart Y. And they
really want to solve Y, because they are engineers and doing the "hard" stuff
is what often drives them. So without some kind of input, what they will do is
spend a week on Y and then report back that X was much harder than expected.
When told at that point "Oh, we really actually don't need the Y part, we
could just to Z instead" they will be quite disappointed, and wonder why they
weren't informed that Y wasn't that important to begin with. So more regular
communication of some kind is really important to avoid this. As I mentioned,
I don't really like daily standups as the optimal way to achieve it ... but I
don't quite accept the "leave your developers alone for weeks at a time"
strategy either.

~~~
cellularmitosis
I understand that avoiding spending a week on Y is important for business
value, but constantly prioritizing shipping features in the cheapest manner
possible also means not investing in the long-term growth of your developers.
You don't learn much of value by gluing together a handful of framework
functions. You become a better engineer by really struggling with and digging
into Y for an entire week. If engineers are never given the freedom to do
that, they stagnate as framework glue monkeys. "Deep work" is a rare thing in
scrum shops.

~~~
zmmmmm
That's a really good point. I know my career has nearly entirely been steered
from "non-core" activities that I undertook which never would have been
justified on a week to week schedule. Businesses also are actually very poor
at understanding technical opportunities which developers at the coalface can
see (that is, things that are technically easy or at least feasible, possibly
due to the specific skill of the engineer(s) in question, but have very high
value).

------
Sohcahtoa82
The entire concept of a sprint to me always felt wrong. Development work can't
be split up into time slices. And trying to divvy up tasks based on an
estimate of how long it'll take to complete each one is just a waste of time.

I remember being in a standup, being told to bump a high-priority task into
the next sprint and complete a couple low-priority tasks instead because I
already had too many points assigned to me for that sprint and just
thinking...really? If I don't complete the second high-priority task before
the end of the sprint, so what? I still made progress on it.

It just felt like so much time was being wasted. We estimated the amount of
time each task would take, assigned it points based on that, and we'd fill our
task list in such a way to try to make the estimation close 40 hours of work.
If you had 30 hours worth of tasks assigned to you already, and there was a
20-hour high-priority task in the queue, it'd get bumped to the next sprint
with 10 points of low-priority tasks assigned instead. It was more important
to them to get precisely an estimated 40 hours of tasks completed, rather than
getting supposedly high-priority tasks done.

Obviously, this frequently resulted in priority inversion, not to mention the
problems from poor estimations of task time.

Management was often clueless. You only earned the points when you completed
the task. So if you took on two 20-hour tasks, and just barely didn't finish
the second one before the end of the week, but then completed that plus 40
hours the next week, they'd question why your productivity swings so much
because you only got 20 hours done one week, but 60 hours the next!

And of course, as mentioned, these "hours" were all estimated hours, not the
actual hours done. People started overestimating the hours needed for tasks,
but management was apparently smart enough to catch on to that when they
noticed everyone was getting 50-60 hours worth of work done, despite everyone
only working about 40 hours per week.

I've rambled a bit, but you get the idea. I think the author is spot on. Just
use your task tracker.

~~~
aphextron
>The entire concept of a sprint to me always felt wrong. Development work
can't be split up into time slices. And trying to divvy up tasks based on an
estimate of how long it'll take to complete each one is just a waste of time.

That's because sprints weren't designed for us. They're designed for
management. Product managers and VPs need to be able to think of their
"resources" in manageable, discrete chunks. Vagaries are an absolute
antithesis to their world view. Small boutique firms can avoid this, but mass
production means the need for mass conformity.

~~~
bunderbunder
They _should_ be designed for us. The idea is supposed to be that there are
limited times that developers are negotiating with the outside world about
what exactly they are working on. The rest of the time, nobody gets to
interrupt and demand that they drop everything and jump on to their latest
crazy idea.

But yeah. I currently have to wear both the PO and dev hats, and, when I'm
wearing the PO hat, I also see advantages: It means that I get to have a
rhythmic schedule that I can set my calendar to. That makes all the
orchestration crap _so_ much easier.

Which, incidentally, I also like from a developer perspective. The less time I
have to spend on that stuff, or get randomly interrupted by that stuff, or
randomly interrupt people with that stuff, the more time I get to spend on
actually building stuff.

------
mr_tristan
I'm the scrum master on a team where most members are very geographically
spread out, and the standup is great. It's time for everyone to have that
direct social connection.

But I don't ask about ticket status. We just ask about what they did
yesterday, and what they're up to today. And I mostly ask that if they aren't
doing something already captured in a ticket, make another one, so we have a
record of issues taking up our time. You want to do some tech debt reduction?
OK, but keep it unambiguous - "tech debt" is too generic.

The standup typically exposes important issues, like how team members are
siloing off from each other. And then we can easily sit down and notice "hey
we need to sync up". A lot of ad hoc conversations appear right after
standups, that wouldn't have just happened, because people don't often spend
their time reading through the comment section on open tickets.

It's really a gut check that yes, the team is indeed working together. If your
team's standup is just some regular robotic process of repeating status
already captured in tickets... WTF; I'd say you've got serious leadership
problems.

~~~
QualityReboot
Why doesn't everyone just write what they're up to today in a chat channel and
people can reply if they want?

It seems kind of silly to me to have everyone dial in or stand around in a
circle, to each have one person speak. I'd much rather see a list of what's
going on with everyone today and if anything catches my eye, I can talk to
them about it.

~~~
chadlavi
On a mostly-remote team, it may be the only opportunity in a day for everyone
to hear everyone else's voices. Social interaction is important.

------
caymanjim
This sounds to me like a team that went through the agile rituals until
everyone was familiar with the benefits and methodologies and got rid of the
formal structure once that happened. That's fine. But having structure in
place around these things is helpful to newcomers, especially when the entire
larger organization is trying to transition from a waterfall process or no
process at all.

The list of rituals the author got rid of shows that the team has already
learned the more abstract values and benefits and is doing them real-time
instead of scheduling them as standalone meetings and sessions. It doesn't
mean these things have no value; it means the team is a well-oiled machine.

Except standups. Standups are, have always been, and always will be a waste of
time.

------
k2xl
I've been managing engineering teams for a few jobs now, but I think this
article suffers from some logical fallacies.

"You don't need stand-ups"

I've actually tried this multiple times with multiple teams in my career. The
truth is, is that sure no stand-ups can work... _sometimes_. Some teams some
teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we
ended up doing a slack standup, and some teams we skipped them altogether.

I too, when I had my first engineering team skip stand-ups and retros felt
like I had unlocked some secret in management, as work was indeed getting
done.

But the very next team I tried it on it failed miserably. Tons of conflicts,
duplicated work, etc. We also tried to "fix them as they went" but what ended
up happening is that bringing up and trying to resolve every issue when it
happened got difficult. Naturally we kept "tabling" issues to discuss later
and we never did until we create monthly meetings to discuss all the issues
together. Funny how a "retro" ended up organically forming.

The truth is, every team is different. What works with one team won't work
with another. I've found that as a general rule, a regular check in with
engineers help align goals and what they are working on. And a somewhat
regular cadence of evaluating _how_ you do work makes sense.

I also think the authors marriage analogy is weak. At work, your team isn't a
family. It's a team. You can't fire family members. A team you need to stay
consistently plugged in because you are trying to complete specific
objectives. Marriage is rarely like that.

------
LargeWu
Here's a thought experiment, and a challenge: When was the last time you
learned something really important at a standup meeting that you wouldn't have
learned otherwise, either by talking to someone directly or in some form of
asynchronous communication?

I bet it was a while ago, if you can even think of anything specific.

Standups, in my experience, are a net negative, in that there is a cost, but
rarely a benefit. I almost never get anything useful from them. I don't need
to know that the product owner is in meetings all day. That's almost every
day. I don't need to know what every single other developer is doing every
single day. If I have a general idea of what the team is doing that's usually
good enough. If I am blocked on something, how is that useful for you to know?
If there's anything you can do about it, or need to communicate to somebody
else, I've probably already talked to you. And if I haven't talked to you,
it's almost certainly irrelevant to you.

Challenge: For the next week, make a note (actually write it down on paper) of
something useful and actionable you learned at a standup meeting, and see how
many times that happens. Then compare the cost of the time spent in standups
to the number of times it was useful.

~~~
tomjakubowski
> Here's a thought experiment, and a challenge: When was the last time you
> learned something really important at a standup meeting that you wouldn't
> have learned otherwise, either by talking to someone directly or in some
> form of asynchronous communication?

Twice this sprint, a problem I mentioned at standup was addressed at that
moment by a comment or suggestion from a teammate. The standup is really the
only venue I have to casually, non-directionally vent frustrations I'm facing.
They're great.

------
nodefourtytwo
A team where the Engineering Lead(or any kind of manager) thinks that you
don't need retros because there are no problems is exactly the kind of team
that needs retros.

~~~
lobotryas
You may have missed the part where the author says that problems should be
addressed as they come up and not just once at the end of the week.

A retro obligates people to find and/or bring up issues. In my opinion an open
door policy would push people to bring up things that actually matter.

~~~
munchbunny
This is a situation that really depends on the team. If your team isn't
surfacing issues, then either you're creating an environment where people
don't feel comfortable surfacing issues, or your team is mostly just not the
type that is proactive about it.

If it's the latter, then "priming the pump" is a useful exercise, and a
regular retrospective makes tons of sense.

That's also generally true of processes: every team has its quirks, and you
fit the processes to the team's quirks.

------
munchbunny
Posts like this usually have good points, but I feel like they should always
come with a massive caveat:

 _Every team is different, and you should tailor your processes to fit the
team._

And because of this, I think posts like this one should spend time answering:

 _What conditions were needed for your decision to be a good idea? And when
would your decision be a bad idea?_

The author seems aware of this, because he tries to generalize to just not
over-complicating things. But his post is pretty much just arguments for
removing meetings entirely without really considering when that might not be a
good idea. And there are definitely teams and circumstances where that might
not be a good idea.

~~~
antris
Isn't pretty much that caveat right under the title?

 _" Notice: Below represents my PERSONAL beliefs about agile and team
organization. Your results may vary."_

~~~
munchbunny
Not quite. I think there's an important distinction. That caveat says: "I
think you should do things this way, it might work for you." But what I'm
asking for is: "I think, under these conditions, you should do things this
way."

But you're right to point this out. I think I phrased my post badly. The
caveat isn't the important part. The second point is the really important one.
The decision framework for when to take any specific piece of advice is more
important than the advice itself. In general (and this is definitely true with
development process advice), advice is plentiful and often conflicting, and
most of it gives you ideas of what to do, but doesn't tell you when it's
applicable. The really good books, courses, and blog posts I've found do
exactly that.

------
iEchoic
Is there any reason to believe that a process that interrupts an entire team
every day to make everyone listen to non-critical updates would be necessary?

Standups are (in my experience) usually a symptom of a low-trust environment,
where there's an underlying belief that engineers will do less work or let
things slip without the fear of being behind at the next standup. In some
companies, this is actually true - so in some cases, standups are certainly
effective - but I can't think of any argument for why they'd be necessary at
all companies.

Our team is distributed and has been going ~eight months without standups or
work hours, and I'm extremely happy with the quality and pace of our
engineering. This requires a high-trust environment where every person is
given large feature areas that they are able (and incentivized) to drive
autonomously, but I think this ends up being better both for productivity and
for quality-of-life.

~~~
TooBrokeToBeg
> Standups are (in my experience) usually a symptom of a low-trust environment

and or a high volatility process and or poor information flow. All of these
things occur at different times throughout any company. Standups mitigate
these issues and are not supposed to be these hour marathons that I see
everywhere.

~~~
iEchoic
Agreed that those are other common causes.

I think that keeping standups short does very little to mitigate the damage
they cause, though. The biggest cost isn't the time they take, it's the act of
forcing your entire engineering team out of a flow state (or worse, forcing
them to wait until after standup to even start) on a daily basis. That happens
regardless of if they're 10 minutes or 30 minutes.

------
peterwwillis
I love the fact that none of this exists in open source projects. All
communication is done immediately using IRC, mailing lists, and bugs/tickets.
Nobody has to follow a development methodology. You volunteer to contribute to
the things planned in the roadmap. You get shit done when you get around to
it. When it's ready, it's ready.

I hate the fact that if you're _not_ following a bullshit development
methodology (and usually poorly) you're treated like there's something wrong
with you.

------
cbanek
It's hard for me to dislike this, because I also find standups and sprint
planning meetings to be painful and somewhat less than useful for myself.

On the other hand, when you are with a new team, or a team with a few people
that need mentoring, or going in a new direction, I find that it's important
to force people to coordinate, because many times people will just run off in
random directions you don't want them to. You really have to have the best
people, and trust their instincts if you follow what the article suggests. Any
weak players on your team will just be lost and potentially set you back (or
at best, just waste their time).

~~~
zebraflask
Exactly. This could work well in teams where the engineers are all competent
and really just need the PM to stay out of their way.

In weak teams, this could easily see an end-of-quarter with unmet deliverables
and other management messes. A lot of people would take advantage of the
hands-off approach as much as they could.

Either way, Agile is ridiculous so I agree with the author about that.

~~~
jiveturkey
> _In weak teams,_

Agile is largely about managing weaker teams.

~~~
cjalmeida
Also, everyone is weak at some point of their careers. Until they aren’t.

------
luka-birsa
We actually massively profited from implementing standups and agile-ish
process and we really do not feel the downsides mentioned in the article.

Standups:

1\. The standups are held in very small groups that work on the same thing and
where it is important that they are coordinated.

2\. Standups are not a place to discuss priorities. Those were set way before.
It's for you to tell everybody what you're working.

3\. Standups take 5-6 minutes per day. It's less than one foosball game. Some
teams actually do their standups while doing a plank, so that they're very
short.

4\. Standups help us achieve team cohesion. Everybody knows what everybody is
doing, so people can help each other when needed + leads can detect issues
sooner (especially valid for introverts, since they sometimes lock up and
grind away without telling anybody).

5\. If you're bored during standup and not getting any value then you should
not be part of the standup. Standups are considered optional, but everybody
attends.

Agile process:

1\. 14-day scrums are to sync priorities and discuss the development process.
Generally speaking, we set up quarterly goals (and we have a rolling forecast
for the next two quarters) so its clear what people need to do. We do not
change the quarterly goal, except if external forces force us (example: things
failing).

2\. The schedule also gives the leads a clear tool to block any "non-urgent"
but important tasks that would meddle in the development process. Instead of
caving under the pressure of product teams or high-level management they can
clearly state when they will start working on the task. I think the schedule
needs to be set so that management can handle the lag between request and
start of work on the request. I've heard of 3-day sprints since that was the
most effective way of blocking daily priorities changing until management got
on board.

------
joepour
We do stand ups once a week on Monday morning to get everyone on the same page
and focussed for new week.

Each time a different dev runs it, chosen by the person who ran it last.

Our stand ups are one of the most mentioned things in my 1:1s as everyone
likes to hear what other people are working on.

We then do a retro on Friday afternoon, sit outside and have a beer and chat
about what worked and what didn’t.

Not strictly agile, but this works for us and everyone is happy and
productive.

~~~
wool_gather
> Not strictly agile

Sure it is, because agile is precisely supposed to be "whatever works for your
team". Awesome that you've been able to find such a good, low-key process!

------
brightball
Not going to lie...I like stand-ups, but I am an extrovert. I also like them
as a full time remote because it's the only way I regularly see my team.

As long as it doesn't interrupt people. 10am is to late if the work day starts
at 8:30am. About 45 minutes after the "beginning" of the day is about as long
as can be tolerated. Give people time to arrive, account for traffic, get
coffee, check some email, quick stand-up with the team and then get to it.

At the same time, there's not a point where I think stand-ups encourage
prioritizing features over tech debt. Usually, that comes from sprints
themselves and the planning around sprints. Stand-up shouldn't be anything
more than a quick "how's it going" for the team.

I would have no argument as a developer working under this unless the
quarterly goals were out of control.

What you're describing is basically Kanban.

I agree with almost every word.

------
inv
I've worked at 5 different companies that did standups. They always sucked.
Agree with what others said here: If you need to talk to someone, just do it,
don't wait for the next day.

The team that didn't do standups was by far my best team. We still talked
frequently as needed and moved quickly. Actually quicker because we didn't get
interrupted by standups, hour long retros and planning meetings.

------
seancoleman
I've been beating this drum as it's one of the more frequently cargoculted
items about agile.

A standup has 3 questions to report on:

1\. What did you make progress on yesterday?

2\. What are you planning on making progress on today?

3\. Do you have any blockers?

Taking this pulse once every 24 hours is artificially constraining. Relevant
stakeholders (product people, other engineers, project managers, etc.) should
have perfect, frictionless visibility in to what people recently worked on,
and what they are planning to work on at any given time, as self-reported by
the team. Additionally, if you have a blocker, you should not wait until the
next standup. Unless the blocker was discovered immediately preceding the
standup, it should be well known to all who need to know with the same
perfect, frictionless visibility. At the time of the standup, blockers should
be well-known. I've specifically seen standups backfire as individuals use
reserve their blockers until the next morning. It's a great reason to call it
an early day when you hit a blocker and get the opportunity to report
something of substance at the next day's standup.

Perhaps I just described an unattainable utopia, but I think it's important to
start with process idealism and make considered compromises rather than
acculturating the status quo.

I lead an entirely remote-first development team, and am adamant that standups
often are a crutch at best, and inhibit progress at worst.

~~~
Florin_Andrei
> _I 've been beating this drum as it's one of the more frequently cargoculted
> items about agile._

When most aspects of something have strong cargo cult features, then maybe the
whole thing is a fantasy.

------
ibdf
I really dislike these type of articles. The title is there just to shock you,
and so is the content... so much that there's a disclaimer at the end of it. I
think I would read it with an open mind if the title was phrased
differently... "Maybe you don't need standup" or "how standup slows down our
company" something of that sort.

"The natural side effects of not doing standup are:"

"\- Developers communicate more \- Your team becomes more remote-friendly \-
Tech debt gets addressed \- Developers feel more in control and less stressed
\- Developers know you trust them and that you have their back"

These bullet points are non-sense. Perhaps developers were not communicating
properly, and that's why you started having stand-ups in the first place.
Perhaps your developers need more guidance and someone overseeing them. Maybe
your business is growing too fast and you need to have more meetings to get
things back under control. Some people are goal driven and can take care of
things on their schedule other people don't even know how to make a proper
schedule.

Here's what you should do:

1\. See what works for you 2\. Make adjustments 3\. Evaluate adjustments 4\.
Repeat

Meanwhile, read some books on management and learn from more experienced
people. There's no reason to drop everything you are doing because a blog post
said so.

~~~
k1ns
Our team of developers is 100% remote and we do a daily standup each morning
that lasts anywhere from 15-30 minutes. Each person runs through anything of
note from yesterday, our priorities for the coming day, any roadblocks, and
anything we feel like discussing with the team.

Coming from a team that did nothing remotely close to a standup, I highly
value our current system. It's not perfect, and I have no idea if it fits the
Valley's definition of "standup", but it serves its purpose very well and
keeps everyone on the same page. I can't tell you how many times a person from
my team has reached out in the afternoon about a roadblock I mentioned during
standup. Or how many times a team member wanted to help me out on a tough user
story simply because I was open about discussing its difficulty.

This is just my opinion.

------
aphextron
As someone who hates standups I tend to disagree. I've found that without some
kind of forced daily interaction, lines of communication in a team break down
very quickly if they aren't already extremely tight knit. Once that happens,
your project is toast.

~~~
randomdata
That's funny because we recently started doing standups and our communication
has fallen off a cliff. I feel like we had that tight knit group you describe,
knowing when to get in touch and when to leave things alone.

Now we don't speak to each other except during standups, and even then it
feels more like speaking at each other as it is expected that each member put
in their voice, even when they have nothing to useful to add, leading to the
team quickly tuning out and then not paying attention when something important
is mentioned. Not to mention that now there is up to a 24 hour window before
anything is addressed, when the previously used ad-hoc meetings would have got
everyone on the right track in a much shorter timeframe. And as a result of
all that I feel like there is a lot more animosity between members.

It may be possible to do standups well, but we've failed at it horrifically.

------
rosege
This approach works really well when you have a great team - like I'd imagine
palmerj3 has at Spotify. I've worked in a few of these places and know how
well this approach can work. However, I am currently working at a place with
people who are very inexperienced and frankly pretty lazy and just generally
not very motivated. The manager has to constantly monitor them and make sure
everything is being done. In this type of environment you just wouldnt see the
end result at the end of the month. But personally I find this approach works
super well for me.

------
ghostbrainalpha
People should try to think more long term about standups.

Yes, maybe you could remove them and maintain the same productivity for a
year, so they appear wasteful.

But removing accountability, can lead you occasional bad decisions, which lead
to more frequent bad decisions and then 5 years later you have some REALLY bad
habits in place. Standups feel like babysitting, and they are not necessary if
everyone is just ready to work, but I think the accountability from publicly
stating goals for the day has a subconscious effect that can lead to people
getting into a great routine.

I myself, never needed standups to prevent goofing off. But they really helped
me get a handle on how bad I was at predicting the results of my work for a
day. My optimize makes me perpetually underestimate the time it will take to
do a task by a factor of 3-4. With practice in standups I've got that down to
more like 2x.

------
tapvt
I'd really like to hear thoughts on how this applies to remote teams. I find
that async standups via slack are pretty damn helpful for keeping everyone
appraised of what is going on across 5 timezones.

Process and communication are kind of key, aren't they?

~~~
KallDrexx
Async standups do well only if the engineers have the discipline to actually
go through them. My past experiences have shown a couple devs paid attention
to the standups to look for issues and everyone else just typed their own up
without looking at what other people wrote.

~~~
bcassedy
This is what everyone does in person too. The people that go last tune out
because they're preoccupied about what they'll say and the people that go
first stop listening because the value of the information tends to be very
low.

------
cimi_
I've pushed for this model and I've done this with my team over the past year.
It's worked out relatively well, but not as well as I expected. Context: I am
the lead developer on the team, I am not a people manager.

Our work involves some research which we've managed to do quite well following
this model. We've also evolved our product and managed to deliver complex
features more efficiently than we would have done if we did sprints, IMO.

A few team members have complained about lack of frequent deadlines (?!?),
lack of status meetings/standups etc. The arguments are weak IMO - 'that's how
we did it before', 'we hear what other people are doing' (we are pretty good
on transparency), 'it's nice to have a forum to discuss how things are going'
(we use chat extensively and we should be able to discuss things there). Our
manager is great and he helps people choose which things to work on - he's
been handling feature prioritization and he's making sure that people are
comfortable with their work during 1:1s.

Also, I think it's really important to have a clear vision and steer the
product - we've been missing that and it's caused a lot of friction when
deciding how to evolve the product. Sprints wouldn't have fixed that, but
maybe a more rigid decision making process would have made us fix the problem
(or at least complain more) earlier.

------
irrational
I work on a team where 3/4 of the team are business people. Yet we have a
stand up with the entire team everyday and everyone talks about what they are
working on. How is hearing that you are talking to account X about something
or just came back from conference Y applicable to the job I've been hired to
do? Likewise when it comes to my turn to talk it often turns into "blah blah
blah [giggle] I don't know what any of that means! computers!" from the
business people. It's so useless.

------
sytse
I think you want a culture were people let others know as soon as they are
blocked. And were a manager discusses your progress 1 on 1, not in a group
setting. Standups are inefficient because most updates of others don't matter
and it is needlessly synchronous.

------
CJST_
While I do agree with the sentiment of reducing meetings and time spent
planning, I don't believe that removing all scheduled communication and
planning is a good answer. This approach is especially problematic for teams
that are working more directly on rapidly changing business concerns.
Communication, planning and analysis are quite important for teams with
members who need regular guidance or teams with lots of distinct roles.

------
crispinb
I understand many writers are desperate for views, but I'm looking forward to
this nasty spreading imperative title infection to die out (which it will, but
not soon enough). "What you need to know about ..." ( _you have no idea what
my knowledge requirements are_ ) "You don't need ..." ( _you won 't know what
I need until you find out something about me, dolt_). "Why you should ..." (
_until you 've at a minimum skimmed 'Ethics for Dummies', which your 1st-year-
uni-essay-think-piece betrays no evidence of, you're not qualified to inform
me what I 'should' do_).

This rash is particularly prevalent in the prissy modern etiquette columns
that dominate so many alleged newspapers (I'm looking at you, Graun), but the
tech sector is also succumbing apace.

Now Kant: _there_ was a guy who knew how to construct titles. He did not write
"What you need to know about the categorical imperative", nor "Why you must
critique pure reason".

~~~
Florin_Andrei
Yes, but Kant was not incentivized to write in a certain way by some
performance graph in Google Analytics.

~~~
crispinb
Indeed. Our intellectual history definitely dodged a bullet there.

------
telltruth
One of my manager used to say that number of status meetings you must to do is
inversely proportional to quality of people you have.

The whole concept of standups and scrum was started to bring highly
dysfunctional team back on track. Since then now we have been applying
methodology that is required to make highly dysfunctional teams work to _all_
teams.

~~~
username90
Agile is the management equivalent to electron apps, not very efficient but
makes your job easier.

------
hfourm
I think a lot of the themes in this article I can agree with, but I come away
with the overall impression that the author hasn't necessarily worked in a
healthy agile environment before. Basically, I agree with many of the
conclusions (or solutions) but disagree with a lot of how the author came to
them.

Standups aren't inherently bad. Also it sounds like he moved his team to more
of a kanban style workflow -- which many people use already. That isn't ground
breaking. There is still iterative planning, even if they aren't "sprint
planning" sessions.

~~~
VectorLock
I got the impression that the author of the post had worked in effective agile
environments and he came to the conclusion that the cargo-culted trapping of
agile were unnecessary.

~~~
chris11
I was a little bit surprised to see this article with him at Spotify. Their
Squads framework is shown as an example for larger-scale agile, I heard about
it at a place that had just started doing SAFe. The approach mentioned in the
article doesn't really match up with my idea of larger-scale more corporate
agile.

------
rightisleft
FTA: Say you’re in a relationship and it’s going amazing. You should totally
start going to couples therapy once a week, right? </sarcasm>

Me: Actually yes - that way it stays amazing...

~~~
bunderbunder
I thought the same thing. Not couples therapy, per se - that bit is a blatant
straw effigy - but we do have a regularly scheduled chat that is, in effect, a
standup meeting.

We've found that it ultimately reduces the amount of time we spend on talking
about that stuff. Sit down, take care of business, see what's on Netflix.
Without it, we could easily spend the same amount of time per week just
figuring out _when_ to talk about XXX thing, let alone actually talking about
it.

------
dood
Probably too late to this thread, but anyway - the key to understanding agile
tomfoolery is that _processes are most effective if they evolve to meet the
needs of the people in the team_.

A process will always feel like a burden (and be less effective for it) unless
it is co-created by the people right in the middle of it. Most people like
doing a good job if they're permitted to, and like supporting their colleagues
if it doesn't prevent them doing a good job. Few people want to make their
colleagues' job harder or get in fights - much of this is friction caused by
bad processes.

Given a chance to talk over problems faced by each team-member and to discover
fair solutions, a team that dislikes agile may themselves choose to adopt
parts of agile if it is obvious that _it solves real problems and makes the
team more effective_.

The difference between a pointless, painful, morale-destroying standup and a
fun, useful, team-building standup is that one is imposed from outside and the
other naturally arises from a team allowed to figure out for themselves how
best to work together.

------
nineteen999
I think a lot of this depends on the size of the organization and teams
involved. Too often I find these kinds of articles (from both sides of the
argument) ignore that aspect.

Some aspects of Agile/XP/Scrum etc. obviously have some benefits particularly
for larger organizations/teams. On the other hand I've seen smaller companies
that are trying to emulate this success really struggle to get real work done,
because there are so many standups, retros, kanban and "user stories" etc. In
between morning tea and lunchtime, not much breakfix or clearing out tech debt
actually gets done, before they are required to pour another bucket of
features on top.

I've worked at a company like this that held retros on Friday afternoons and
by Monday morning standups, they couldn't remember the things that had been
discussed in Friday's retro. It all felt so mindlessly pointless, and playing
into the hands of those who make good money selling books about Agile, or
talking at conferences about Agile.

IMHO I think the sweet spot is probably somewhere in between.

------
wolco
I find myself slowing down or doing tasks that I can easily explain because of
standups. Instead of pushing ahead and killing it I find I need to translate
what I am doing into english conversation speak so I manage my work around
this. Normally I would work on multiple items but standups force me to work on
something easily explainable/simple so I do less but explain it well.

------
httpz
This should really be taken as an example of a team that got rid of standups
and did well. Every team is different and without prior knowledge of the team
featured in this article, it's hard to judge if this advice is any useful to
me. I would've preferred if the tone was more like "Why we didn't need
standups" not "You don't need standups".

------
rajacombinator
Good article. If you have a good team, you don't need agile or other
methodologies. These frameworks have always been the crutch of bad managers,
or MBA types who want to corral "those developer people." Now, can
agile/scrum/ninjitsu/rockstarism transform a bad team into a competent one? I
don't know - I don't work with bad teams.

------
vinceguidry
I really like this advice. One thing I've been taking notice of at my job is
just how meaningful the tracker is to our workflow. If things are settled down
and well-managed, then no meetings are needed, the tracker is a really good
representation of the current state of the project, and Shit Gets Done. For
awhile when I first joined the team we pounded through sprints and often had a
week or more of downtime that we could use to clean up tech debt or play ping
pong.

It was Amazing. So amazing I ended up having to speak up at meetings telling
our nervous team leadership that nothing was going wrong. We were kicking ass
and playing more ping pong than everybody else in the company.

Now we're still kicking ass, but the management has gone into the shitter. We
had a product owner, a team lead, and project manager, then the product owner
got pushed out and it's been veritable chaos ever since. If anybody is looking
for a Rails ninja, drop me a line.

------
ianbicking
I think standups can be good, but get rid of the mandatory status updates.

Want to talk about something? Knowing you can put it on the agenda for the
next standup is great. If the standup isn't the right forum for the topic,
then it's still probably the right forum to decide what the right forum is,
and let's you include people who are unexpectedly interested.

Talking about incoming tasks and bugs is also helpful, and is an important
part of developing a collective understanding of priority and approach.

And of course when there's some specific pressure or deadline, then you'll
need to talk status and cover details. The standup is going to change based on
needs. It's good to have a well-socialized team that regularly talks and both
makes collective decisions and learns how to interpret those decisions when
doing their personal work. Daily practice is worth it, and pays off double
when something goes wrong.

------
adrianmonk
> _I wanted the team to know I trusted them._

This can be very powerful. People will often rise (or sink) to the level
corresponding to how much you show you believe in them.

Imagine you hand someone the reigns and say, "Here, take over this for me. I
know you're going to do a good job." And you sincerely mean it because you've
bothered to understand them well enough to know that they can. In a lot of
cases, you'll be amazed at what they will accomplish. They may even be amazed
too.

Often, forming good, healthy relationships and building people up is what's
really effective at getting people to get stuff done. So many of the other
things people do (endless status reports, procedures and methodologies du
jour, applying pressure or creating fear, etc.) are really just bandaids to
attempt to force productivity to happen when it's really not happening because
the basics haven't been covered.

------
tanu057
One thing that the standup helped me was getting blocked by a senior
developer.He would never answer my questions normally. But once we started
with scrum and daily standups, there was that I am blocked because of
something that can be answered by another developer within 15 minutes.
Standups make a team working.

------
Falkon1313
To me, standups are most useful for 3 things:

1) When working on a new system, making sure that your work aligns with what
others are doing, and you have group consensus that your approach is
acceptable (or if not, then getting someone to talk through it with after
standing).

2) When working on a legacy system, getting group consensus on the hacky stuff
you're doing to solve a problem (and in the process letting others know about
that hacky stuff).

3) The group's lighthearted banter while we wait for others to join the
meeting, and sometimes at the end, or on a particularly fun day, in the
middle.

All of that is about group teamwork, consensus, and a little bit of bonding.
All the details should already be on the board, and in slack discussions or
calls with the relevant people. The meeting should focus on stuff that needs
the group interactions.

------
ceedan
my 2 cents,

I don't think this post will age well.

The team I am on is currently swinging back towards more traditional agile
after going too lax on planning, retro, estimation, etc for a while. These
"rituals" are effective ways to ensure a good base level of inefficiency. If
you're feeling like the agile rituals are becoming a waste of time, I would
try out doing longer sprints before dropping them entirely.

Cutting process relies on good habits from the developers/whoever on the team,
and habits can degrade over time. Devs can cut corners without formal process,
because creating meetings and facilitating process that doesn't formally exist
can feel like just another burden/task switch they have to take on.

------
partycoder
Let's say you have 2 developers:

\- developer A wants to get promoted as quickly as possible. developer A will
try to "ship" as many features as possible.

\- developer B wants features to actually work, not just be "shipped".
developer B volunteers to fix the problems developer A created by rushing to
close as many tickets as possible.

Now, guess which developer contributes more to the team "velocity"? developer
A. But in reality, developer A is just gaming the system and making everyone
else _slower_. This is how agile distorts development.

Using velocity as KPI is the same as evaluating leaflet distributors by amount
of leaflets distributed. Some will just throw them away in the garbage and
claim their money.

~~~
alexchamberlain
Or do developer A and developer B make a good team? Looks like you've got a
starter and a closer there to me.

~~~
partycoder
Sometimes that is indeed the case.

In other cases you need a full rewrite, and that is not good.

------
tw1010
Why the need for all this formalization of process. We're all adults. As long
as we hire people who can communicate well, shouldn't just having
conversations here and there when the need feels natural be enough?

------
acconrad
I'm so in alignment with this. I've always hated standups. As a night owl,
it's a morning meeting I have to make every single day and I hate it. I also
don't understand how I can't just communicate in Slack to say "hey this is
what I'm working on, this is what I worked on. Here are the questions I have."
And move on. And if the PM prioritizes the backlog, always pick from the top
just _makes sense_. And yes, retros feel like a place for extroverts to own
the conversation (and I know, I'm an extrovert).

~~~
smileysteve
We have some teams that do "slack-ins" but I find few people read the updates
and even fewer questions are answered or asked.

At best, this gives micromanagers satisfaction while not doing much, and at
worst it's a log of "well I told you so"

~~~
LargeWu
The fact that everybody tunes out these updates suggests that the things being
communicated are of low value.

------
mnm1
> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great
> way to ruin developer flow.

Do they ever. Every day I have no idea what I'll actually be working on. It's
almost never what I say I'll be working on because shit comes up in a stand-
up. I'm not a manager so it doesn't bother me much, but it does slow progress
on larger tasks considerably at times. Sometimes I just avoid saying what I
think I'll be working on to save time as it's irrelevant and the meeting is
already twenty to thirty minutes anyway.

------
throwaway11232
I have done a lot of standups. From my perspective, no one really cares for
them. Most of the time, your coworkers are working on something that either
doesn't matter to your task or you have no clue what they are doing even when
they explain it. So standups are ultimately for the manager to get a sense of
where everything is. But good managers should already have a grasp of the
situation so standups become redundant.

------
artsyxxx
All of this is even worse with a distributed team. Don't get me started on
what happens when contractors enter the picture.

Edit: and so-called development managers!

~~~
RandallBrown
I've had some truly great development managers, and some really mediocre ones.
It's helpful to have a technical manager that can shield you from certain
issues while still understanding your needs enough to actually meet them.

~~~
artsyxxx
You said it man. But when development managers enter the picture, and when
they're also your people managers, and they come into the scrum and start
enforcing top-down patterns it's about as toxic as you can get.

------
aryehof
It seems that much of the discussion here can be distilled into not trusting
people. Lack of trust that people will work, can do the work, will tell
someone when they have a problem or surprise, and mistrust of the
effectiveness of the particular Task Management System in use.

Daily standups as largely practiced today, are a means to overcome this lack
of trust through micromanagement.

------
stevebmark
This makes me suspicious of Spotify. This is bad advice that could maybe apply
temporarily to teams where you're not working on mission critical business
work (what is left to engineer at Spotify?)

I also don't like that he prefixed bad advice with "PERSONAL beliefs" as a
cop-out for responsibility. This is a tactic used by people skirting ownership
of ideas.

------
rc_bhg
This article flies in the face of everything. I love articles that fly in the
face of everything.

------
Bizarro
Standups is just another example of something that someone had to makeup for
the Agile methodology in order to be able to say that "people are
communicating"...kumbaya.

It was probably invented by the same guy that invented the demented concept of
open office.

------
known
Scrum vs Kanban [https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-
they-...](https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-the-
same-thing/)

------
kansface
I'd guess this is probably only possible at a cash flush company where the
devs personally use the product and fully understand the cost/benefit trade
offs. Also, those sorts of meetings aren't for the sole benefit of the
engineers.

------
lmilcin
This is easy to explain. Main premise of agile is spending a lot of effort on
improving the process. These are the standups, demos, retrospectives, etc.

It is no wonder you get more done if you cut the effort. You are coasting on
past improvements. This is only going to work for a while until your
performance starts to slip because the team stopped correcting and improving.

Spending time on improvements is important for other reasons. If your team
spends 100% of the time on project work it is inefficient by definition
(though not very intuitively, but see constraint theory). Spending time on
improvements creates necessary flexible buffer. This is an alternative task
when there is shortage of project work or it can be temporarily cut if there
is too much project work.

------
piccolbo
I am collecting links to SCRUM-related criticism at
[https://againstscrum.tumblr.com/](https://againstscrum.tumblr.com/) Please
contribute!

------
nherment
I'm having a hard time agreeing with a lot of the points being made (I mostly
skimmed but also read some parts).

The conclusion is relatively sound though: the default agile approach
(sprints, standups, planning, grooming, retro) is only a base to start working
on a software development project. The team members should optimize it or even
throw it out if it works for them.

\- Daily standups are a __tool __for coordinating teams.

\- Weekly planning is a __tool __for iteratively communicating about the
progress being done, steering the team and discussing priorities

\- Retrospectives are a __tool __as well; a quorum regarding what goes well
and what should be improved.

In a well functioning team, you will always need coordination/communication,
progress visibility, continuous improvements, etc.

I picked 2 red flags in how this junior product manager approaches their work:

\- the team did not discuss estimations

\- he told his boss the team will deliver after 3 months

Basically he just "winged it" for his first project, picked a waterfall
approach, and made it. Congrats! That tells me he either has a kick ass team
(thank them) or the deliverable was easily achievable (thank the boss), or
more likely a bit of both.

Let's take a few of the points being made throughout the post:

> _Trello (or whatever you use) has to be kept in sync with what’s discussed
> in these meetings. It often isn’t. As the team grows this becomes even more
> complicated._

This is spot on. Using a tool to keep in sync is only useful if the members
keep it up to date. If the tool is not up to date, the team either has a tool
problem or a people problem.

> _Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great
> way to ruin developer flow._

I strongly disagree there. Nothing, in each team member speaking daily, for
less than 2 minutes, about what they are working on, encourages change of
plans.

When the author mentions standups routinely lasting 30+ minutes... well yeah
either fix it the soft way (time limit + a judge making sure everybody stays
on point) or the hard way (just stop doing standups & send updates through a
different channel).

What I've seen is that there are usually 2 team members that come with the
'authority' to make for a great standup: the product owner (in this case our
author) or the tech lead (well, seems it's the author again, as a technical.
prod. owner?).

> _Standup forces every team member to be productive at a set place and a set
> time_

Yes it can be a problem. That could possibly be reason #1 to get rid of
standups. We're lucky in our remote team that everybody is happy starting the
day at 9am as standups mid or end of day make not much sense.

> _Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that
> tech debt is such a common problem. Developers shouldn’t have to PUSH for
> tech debt to be addressed. Teams should operate at a sustainable pace._

Again, it sounds like standups are being used for the wrong thing. The standup
is at 90% a 'passive' communication tool. Listen to the others carefully. Wait
for the standup to be finished and FREE PEOPLE FROM THE MEETING to catch up
with whomever you want on whichever subject you want.

> _Why do we encourage problems to be discussed once a week? We should address
> them immediately, not just at retros._

Absolutely, problems that can and should be addressed on the spot MUST be
addressed on the spot or taken ownership of by a lead and then addressed
timely.

However that approach does not catch everything. Retrospectives are an
excellent way to make sure people can flag issues. It is natural that, in the
week, someone will be too busy to immediately flag an issue, but make a note
of what could be improved. A regular open quorum dedicated to these things
helps share these details.

There are 2 critical elements to successful retrospectives:

\- trust that everybody can speak up about the most minute detail. Be open
about anything that is being said. Leave the ego out.

\- trust that what is said is genuinely acted upon. Track improvement and
suggestions and ADDRESS THEM. In software development, if you see a bug, you
create a regression test and then fix the bug. Well, tske the same approach!

> _Sprints encourage iterative development. This sounds really good to people
> like me who strongly advocate small, concise, pull requests over long-living
> feature branches. But it’s not the same thing. Sprints encourage features
> over tech debt. How often have you had to advocate spending an entire sprint
> tackling tech debt?_

I'm eluded by the fact that sprints encourage features over tech debt. It
seems that the source of the friction with sprints is not the sprint itself
but how it is being used.

Addressing tech debt is part of any new feature. There should be no 'tech
debt' in a sprint. DO NOT address tech debt that does not fix a bug(s) or help
new a new feature though. It can be useful to write a list of hot spots, for
communication and reminder purposes..

For each new feature, the team has many choices for the implementation: from
complete hack to full refactor. A constant balance goes a long way, with the
occasional 'that is needed in a week' and 'we need to refactor A to K before
we do feature XYZ'. These are healthy events in a team that care a lot about
delivering the most business value through solid software.

> _That said, I’m not against planning, I’m against planning on an interval._

Fair point. Planning on an interval brings a few things on the table:

\- it sets a cadence. Some people love stability. Regular planning can be an
anchor to someone's organization of their work.

\- it allows measuring velocity and therefore longer term planning through
past velocity.

\- it allows reprioritization sprint after sprint. Usually the product owner
role is to gather clients' needs. These needs evolve both with new features
and time. Rather than re-prioritizing on the spot (like it seems it was being
done at the author's previous projects), it is a compromise between constantly
shuffling around what developers do and being flexible about what is being
built.

In my modest experience, all of these are very useful tools :)

------
blubb-fish
now we don't need stand-ups. couple of months ago they were the best since
sliced bread. in job interviews i still get asked every time how often we do
stand-ups - right after whether my team is lean, agile or design thinking.
good lord have mercy ...

------
amai
I read "You don't need startups" and nodded my head in agreement.

------
jillesvangurp
Post agile is a thing. Everybody is pretending to be agile these days. So, the
word has become utterly meaningless. Every bank, insurerer, etc. is doing
agile. And they are just as boring, stupid, and ineffective as 20 years ago.
Government IT projects still go spectacularly wrong but they all pray to the
church of Agile now.

When the agile manifesto was signed (yes old enough to remember), this was not
the case. Agile was a new thing then. People were doing all sorts of stuff at
the time and confusing processes and modeling techniques and requirements
engineering methodology. Universities taught waterfall then (mostly because
academics have no clue how development actually works). Rational Unified
Process was something pimped by a company specializing in UML tooling! They
ended up in the hands of IBM; probably the least agile company in existence at
the time. Blue suits/white shirts were very much still a thing then. RUP was
considered modern in the late nineties.

UML itself perpetuated the dogmas of waterfall, which was to first do detailed
designs (using UML) after doing requirements specifications and before doing
implementation work and before testing would commence. Automated testing was
not a thing at the time. With rational unified they added a thin layer of
iterative; meaning you got to do waterfall multiple times in a project.
Rational's premise was that this required tools, lots of tools. Very complex
tools that required lots of consulting. This is why IBM bought them.

Iterative development is of course almost as old as waterfall. The original
paper by Royce on waterfall is actually a pretty good read but was soon
complemented by papers on spiral and iterative development. Feedback loops are
a good thing; every engineer knows this.

What the agile manifesto accomplished was that the UML bubble was burst.
Having a lot of design documentation slows you down when iterating and makes
it hard to do that. When people figured out that the added value of this
typically incomplete and out of date documentation was questionable and that
iterating was a good thing the result was that UML became a thing for
whiteboards and from there an entirely optional thing. Same with requirements
documentation, which was a bit of a black art to begin with. With agile people
figured out that it's much easier to specify small deltas of what you want
changed then the whole thing up front. Issue trackers empowered this. Bugzilla
was the first popular one that got a lot of traction. They turned requirements
into a way of working.

In a post agile world, everybody uses similarly capable tools. Typically git,
some issue tracker, async commnunication tools like irc or slack, etc. I
exclude email here; relative to 20 years ago, I spend a lot less time looking
at email. It's rapidly disappearing from my life at least. Async communication
is at odds with meetings and empower having distributed teams. The open source
world was always distributed and never relied on meetings. They were an early
adopted of asynchronous tools.

With post agile people are discovering that the added value of meetings is
questionable. Agile initially replaced tools with structured ways to organize
teams. An unintended side effect was lots of meetings. Meetings are inherently
synchronous in both time and (usually) space. They require heads in a room at
a specific moment. Video conferencing sucks and remote attendees are typically
at a huge disadvantage in such meetings. So meetings are an obstacle for
having remote teams.

With post agile, people are keeping some of the tools but are abandoning
meetings. This is similarly liberating as saying goodbye to convoluted out of
date UML diagrams, crappy requirements specifications, and the glacial pace of
waterfall style development. Other post agile trends are continuous
deployment: if it's ready, ship it now, not after the next retrospective in
two weeks. And it's key enabler: continuous integration: aka. automatically
assess whether you are fit to ship right now and do that after every small
change. The former eliminates release management as a role and the latter
relieves product managers from having to manually test and approve releases.
That cuts down on meetings and eliminates Sprints as a necessity and allows
you to iterate in hours instead of weeks. With sprints out of the way, you can
delete the associated meetings. Standups are not practical in a distributed
team, so those go as well. Post agile is about asynchronous communication and
work distribution and getting rid of synchronization bottlenecks in processes
(aka meetings).

------
com2kid
Line by line:

> Trello (or whatever you use) has to be kept in sync with what’s discussed in
> these meetings. It often isn’t.

My team offloaded this to the PM.

> Stand-ups ENCOURAGE plans to change daily.

The sprint plan is the plan, stand-ups make sure the execution is coordinated.

> Standup forces every team member to be productive at a set place and a set
> time

Timing around standups is interesting. 11am and everyone will be there, but it
interrupts a lot of people's flow. Earlier and people no show, later and the
point of a morning stand up is lost.

> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that
> tech debt is such a common problem.

How are extroverts and tech debt related?

> Developers shouldn’t have to PUSH for tech debt to be addressed.

Have a sustainable plan for addressing tech debt. My team had 3 week sprints,
2 weeks code, 1 week on debt. Developers who had just finished a major feature
would be cycled on to tech debt for the entirety of the next sprint.

> Why do we encourage problems to be discussed once a week?

You can talk about problems whenever, but having a set place to have larger
planning discussions means that you waste less time smaller meetings about
them.

> Sprints encourage features over tech debt.

Plan tech debt into your sprints. Put bug fixing onto your task board. Put
writing tests onto your task board. If your task board is full of tech debt,
then you can't add any more features, because that is how a task board works,
it gets filled up eventually and you have to go through it completing stuff.

> It usually serves to interrupt developers, make them feel pressured to
> prioritize features over tech debt

Tech debt sounds like a cultural problem on team's he has been on. Not
surprising, it is a cultural problem on a lot of teams, independent of dev
methodology.

> Developers communicate more

Why? Developers are always free to communicate outside of stand-ups.

> Tech debt gets addressed

If promotions are based upon feature completion, as they often are, tech debt
being completed isn't a natural outcome of freeing up 10 minutes a day.

One goal of stand-ups is for people to say outloud what they are working on,
so if someone else has knowledge in that area, that person can overhear and
chip in.

Without a public forum, how is Developer A supposed to know Developer B is
knee deep in code that Developer A wrote a year ago? Keep up to date on
everyone's assigned tasks?

> It’s my role to “steer the ship” (e.g. decide what we work on).

I find that giving developers input on this is important. In fact, that is how
the tech debt gets addressed...

> If I’m changing my mind about this on a daily basis that’s problematic.

Yeah, don't do that. Daily standups are not for PMs to give feedback, or talk
much for that matter. They are for devs to coordinate the day's tasks.

> Stop planning every sprint

Sprints are super useful to chunk up work and allocate resources. For
companies that have infinite investor money and ship a fancy JS app that can
be updated at any time without impacting customers, sure, go sprint less.

Have a hard deadline that you need work done by? Does shipping your product
have an actual impact on end users? You need to be able to estimate how long
work will take, and figure out what people will be doing.

Historical task completion rate, bug fix rates, and burn down charts let teams
accurately estimate how much work they can get done before that real life
deadline hits.

IMHO weekly planning is too much. My team experimented with a bunch of
different sprint schedules, we settled on 3 weeks as a good balance between
time spent planning and time spent getting stuff done.

Sprints had a rhythm, developers assigned to multi-sprint features ignored the
rhythm for the most part.

For everyone else, 2 weeks feature work, 1 week tech debt, and coordinating
with test for sign off.

> Tasks are added to the backlog as needed,

Stand-ups have no impact on this being possible. The add task button is always
available, 24/7.

> Developers are trusted to be working on the correct things

Stand-ups have no impact on this. You can still trust people to pull of the
tasks they feel are important.

> Stop doing retros

Retros are how the devs tell everyone else that tech debt needs to be
addressed. It is where they can make a solid numerical argument that more time
needs to be taken to fix bugs. On multiple occasions I used retros to get the
larger org to buy off on my team spending an entire sprint on just bug fixes
and tech debt. We were able to show previous burn down charts, show how our
productivity had decreased as tech debt went up, and use hard numbers to
estimate our improved velocity after taking time off to address out debt.

tl;dr: Stand-ups are a nice way for developers to catch up on what is being
worked on by their team mates, and to know if they can help each other out.

If you use them for anything more than that, well, sure, simplify it.

~~~
nrbernard
> Plan tech debt into your sprints.

Exactly! Nothing about Scrum or Agile discourages tackling tech debt. Managers
and Product Owners encourage features—not sprints.

------
tzakrajs
"Extroverts thrive at stand-ups, planning, and retros."

As if to insinuate that extroverts like to increase technical debt and
introverts are the quiet ones that toil away. Nah.

------
ryanx435
Sometimes the goal is to slow down work. For example, if your budget is for a
year but the project only takes 6 months, sometimes people add extra hurdles
that look good to outsiders but slow down work enough so they get paid for the
full time.

If a project ends 6 months early it's entirely possible to not get paid as
much.

------
andrewmcwatters
Bull-fucking-shit; you know why Spotify's engineering team does well?
Stripe's? Netflix's? Because they have _money_ , they have _money_ so they can
buy the best engineers. You ever see a small business development team compete
on their level that isn't a bespoke design firm?

In my world, my team isn't an olympic-performing high-end software engineering
pack. They don't lead in particular subfields in FOSS in their spare time. So
you know what? They need fucking plans.

This article is a glorified, "Well if you're good you don't need process,"
piece.

~~~
dang
Would you please not rant like this to HN? You may have a substantive point in
there but you need to make it more thoughtfully.

~~~
andrewmcwatters
Could you please elaborate? I don't feel like "like this" and "thoughtfully"
are constructive pieces of feedback for comments.

~~~
wgjordan
> Could you please elaborate?

'Bull-fucking-shit' was literally the first word in your comment.

~~~
andrewmcwatters
And? [https://hn.algolia.com/?q=&query=bull-fucking-
shit&sort=byPo...](https://hn.algolia.com/?q=&query=bull-fucking-
shit&sort=byPopularity&prefix&page=0&dateRange=all&type=comment)

~~~
dang
It's basically the online equivalent of spittle flying out of your mouth while
berating someone.

------
apolymath
Funny how there's a Show HN link for a standup app right above this post...

------
jiveturkey
ah, gratuitous obscenity. the sign of someone that really knows what they're
doing, from whom we should take advice.

it's still worth reading, not for what it says but what is between the lines.
"how not to do sprints". admittedly this isn't (must not be, i guess) common,
but at my current $JOB we do dedicate entire sprints to tech debt. remote
people phone into our sprints and are well included. it actually HELPS remote
contact as there is at minimum a daily interaction with the entire team.
(@tapvt had a similar comment.) his comments about changing the course on a
daily basis is another example of likely abuse of sprints.

~~~
nherment
I am a bit saddened by the fact you are getting downvoted.

Swearing adds nothing to the author's arguments and I believe you are spot-on
on the analysis of the blog post.

Edit:

I missed the following from HN's guidelines

 _Please don 't comment about the voting on comments. It never does any good,
and it makes boring reading._

Sounds very fair. The more you know... :)

~~~
s73v3r_
Complaining about swearing adds even less to the discussion.

------
agrippanux
The only time anyone cares about a standup is when they are talking.

