
The daily stand-up is an anti-pattern - ignoramous
http://kristopherwilson.com/2015/03/09/the-daily-stand-up-is-an-antipattern/
======
donw
One of the most important things that I've learned over the years is that the
Daily Stand-Up is a tool that solves a particular problem.

Specifically, if you have a team that _doesn 't_ communicate effectively on a
daily basis, then the standup gives you -- the manager -- a place where you
can get and keep your developers on the same page.

When everybody already knows what's going on, then the standup loses a lot of
its meaning, and should get cut down to "Anybody blocked, or need anything
they don't have? Everybody good to go today? Okay, let's make this happen."

But at a lot of companies, it goes the other way, turning into a Kafkaesque
version of Show and Tell.

Most people that end up in technical management don't get any serious coaching
on leadership or management. This leads to a lot of management-by-bestseller,
cargo-cult agile, and the sort of dystopian teams that grind the minds of
otherwise talented developers into useless pulp.

It's not that these managers are incompetent or bad-intentioned, just that
they never got any solid guidance on how to lead, manage, and grow a team.

What's truly insidious is that the problems don't really start becoming
catastrophic for months or years, by which time it's very, very difficult to
turn the ship around.

One of the more powerful tools for fighting this sort of problem is the
retrospective -- a weekly block of time where the team goes over what works
and what doesn't -- but, more often than not, the retro is the _first_ thing
that gets cut from the process because "nobody has time."

~~~
nickbauman
The part about the stand up that's "what did you do yesterday? what will you
do today?" is the part that is the anti-pattern. In a well functioning team,
the only thing that needs to be communicated is "Heads up: you need to know
this now..." That's the part of the stand up that _really_ matters.

Many of my best stand ups go like

Mary: "Nothing to report."

Jon: "Nothing to report."

Dyneshwari: "Nothing to report."

Shruthi: "Nothing to report."

Su: "Nothing to report."

Grant: "Oh, we moved all the test databases. You need to get the latest base
data in your environment or you won't be able to work."

Joe: "Nothing to report."

It's over in 1 minute.

~~~
a3n
What happens to Fred, who had an appointment and wasn't at the standup? I
suppose in this example he'd notice that he isn't able to work, and ask
around, but ...

~~~
lmm
It's imperfect, but IME a standup is more reliable and usable than any
alternative I've seen tried. Emails get lost in the noise (that people get too
much email at companies is its own problem). A Slack highlight can be more of
an interruption, and non-technical people find it hard to use / won't always
be responsive there.

~~~
a3n
why not an internal blog or wiki? Or a compromise, someone transcribes
essentials from the standup to the blog or wiki.

~~~
lmm
Internal wiki hits the same problem as email (although partly because
companies always seem to choose terrible wiki implementations (confluence)).
Too much information goes on there, terribly organized, and no-one ends up
being able to find anything. Mostly these kind of things are immediate
announcements that need to be acted on once and never again, so a semi-
permanent store isn't appropriate; also the whole point was that everyone
needs to be notified, but people can't watch every wiki change.

Blog I haven't seen tried, but I imagine it would hit the same problems;
either you notify everyone and have the same problems as slack, or you don't
and have a big risk of someone missing an update.

------
evilolive
I tend to have a problem with managers who think doing Agile™ yields a better
quality product.

I've done agile agile (the process being agile) before which worked great. 3
week planning with one to three tasks per week and weekly sync, no detailed
estimates. This was pleasant, I felt trusted, empowered and as a result more
committed.

Right now I'm doing the full cargo cult Agile, with daily standup, sprint
planning, backlog grooming, sprint retrospectives, end of sprint demos. I get
regularly dinged for not following the process, never mind if the work is
actually done. Also there is 5 manager/pm at our standup, for 6 engineers. I
don't know for you but this kind of stuff makes me completely indolent, before
I start searching for something new.

~~~
gohrt
> Right now I'm doing the full cargo cult Agile,

> Also there is 5 manager/pm at our standup

These statements cannot both be true. Those 5 managers are violating the
"process".

~~~
kibibu
> Those 5 managers are violating the "process".

Only if they speak

~~~
evilolive
They don't.

Also one of the "managers" (that's his title), manages no one.

He's a scrum master of sorts, who goes around interrupting people programming
to remind them to move their tasks to "in progress" or to "closed". I assume
so our burndown chart moves down. I've been tempted to replace this guy with a
script.

~~~
rikkus
I'm tempted to replace developers who can't be bothered to help the rest of
the team out by putting in the tiny amount of effort required to keep everyone
up to date with what's happening with the current tasks. Really, it's five
minutes out of your day which makes everyone happy because they know that
tasks aren't stuck or forgotten about and doesn't require you to interrupt
your flow.

~~~
evilolive
I literally work in a team of 2, that also has a PM. We've been parachuted in
another team's standup.

We all know what the other member of the team works on, so the standup is
clearly not for us but for a minute update to all the managers who are sitting
in on several "standups" in a row.

If you read my comments, it's not really the standup itself that I complain
about. It's disguised micro management with an Agile shell.

Since teams are supposed to be self organized and the process itself should be
agile, you could ask the member of the team to comment on the process and if
they think the standup help them.

------
calineczka
Standups can be very useful for entire team. But what bothered us was the sync
aspect of it. People knew standup is coming at given hour and they need to
schedule their work around it because they know they will be interrupted.

So we decided to went with textual async standups on dedicated slack channel.

Example: "Yesterday I finished the “fix the price calculator” feature, which
was mostly about removing the Coffee code and rely on the value retrieved from
the backend, via ajax. The nice thing was that the backend code was already
covered with tests, while the Coffee one wasn’t. After that I helped Jack with
the “allow logging in with email” feature (we need it now because we have a
batch import of users from system X soon). After that I did a small ticket,
where I block buying licences for special periods of time. This was nicely
TDD'ed, thanks to the concept of aggregate, introduced by Robert recently -
all the tests pass < 1s. Here is a commit worth looking at. Today I’m going to
start with foreman'ing the recent commits and after that I want to work the
XYZ system to allow a better editing of entries. I’m not sure how to start it,
so all help is welcome"

Blogpost where we describe this technique:
[http://blog.arkency.com/2014/06/async-
standups/](http://blog.arkency.com/2014/06/async-standups/) and list of them
where we explain the async&remote approach:
[https://blog.arkency.com/story/async-and-
remote/](https://blog.arkency.com/story/async-and-remote/)

~~~
MCRed
That's excellent! I find the cost of a "15 minute" standup is more like 1.5
hours. First, it's hard to get any work done in the 30 minutes leading up to
the meeting because I'm trying to come up with what to talk about. The meeting
never lasts 15 minutes, it's always 30 minutes, and it always involved being
immediately ordered by the manager to talk about some BS nonsense that came up
in the meeting. Then it taks an hour to get back in the zone to be productive
after the meeting.

~~~
dllthomas
My current team does a standup immediately before lunch, scheduled for 15
minutes and often coming in shorter. Those "oh, we should talk about that"
realizations that come up then often wind up, when they do (and it's not every
day), then often happen casually over food. It winds up pretty comfortable,
although I certainly see ways it could go bad if we were focused on keeping
the form of it rather than whether things were working well.

~~~
calineczka
So you have the comfort (or lack of it) of everyone going for lunch at the
same time?

~~~
dllthomas
Everyone on our particular team, yeah. We're not rigid about it, but as a
tendency it reduces the number of interruptions.

------
MCRed
Since Agile became a buzzword (and before that "Extreme Programming!!1!")
about 14 years ago, I've never seen it work right. I've never seen either of
these have a net addition to the performance of the team. 2 developers pair
programming don't get new features done twice as fast. (though it's great for
fixing a bug or transferring knowledge for a particular piece of code.)

Daily standups have never been beneficial. I see people here talking about
managers not talking during standup. I've never seen that once in the past 10
years that "SCRUM" has been the buzzword. NOT ONCE. I've never seen standups
that were only 15 miutes. After being forced to stand for 20-40 minutes each
day listening to an air headed project manager drone on during the Standups at
Amazon, I vowed I'd had enough. I got tired of having my time wasted and made
a rule that if I can't sit down during a meeting, I'm not attending. If you
think I'm rambling in the meeting, then you can make me stand up, but I'm
never the problem (always the "product manager" or "biz guy" is the problem.
Talking seems to be what they think is the purpose of their job.)

It's gotten to the point where I associate the word "scrum" in job postings as
a red flag.

Teams should work asynchronously, all the time. Git lets us code async. Slack
and Hipchat let us chat async. Whenever we need to coordinate, we just talk.
(which is why you need offices so your talking doesn't bother other people.)
Otherwise, everything should be async.

A standup is a big old pointless nose-counting exercise. It feels like it
comes from the 1950s.

And if you're having a daily standup at 10am, then that means I can't start
work at noon, can I? So, where is this "flex hours" that everyone thought was
such a good perk 10 years ago?

~~~
shubb
The worst standup I've seen was lead by a fitness fanatic tech lead / manager.
He used his superior endurance to 'win' technical arguments by just talking
until people gave up because they wanted to sit down. These were typically
hour meetings, but could extend to three. I'd give them 15 minutes then start
sitting on the table.

In my industry, the big problem is people trying to use agile to deliver fixed
cost, fixed feature, fixed time projects. They'll often be doing this as part
of a large organisation also working to those targets. If you want to deliver
a project like that, you need to control change to requirements, and push the
costs from change either into a cost bucket you can track, or back onto the
customer. Because Agile encourages flexibility, other teams teams working on
waterfall push changes towards the Agile team. If the interface between them
needs unforeseen changes, or some extra business logic turns out to need to go
somewhere guess who's implementing it. The axe falls on the project manager at
the end.

I don't think scrum is right if - you don't have direct contact with users
(i.e. a feedback loop), you don't have the capacity to change your product and
drop features as you go.

It's worth agreeing, in that kind of organisation, the scrum will be happening
at 10am, like you say.

------
madeofpalk
Stand-ups vary so much between teams that it's naive to say flat out that
they're an anti-pattern. What the author really meant (or should have) was
stand-ups in his team are an anti-pattern.

It's like saying 'burgers taste bad'. If your burger tastes bad, then maybe
you're making it wrong.

~~~
Pyxl101
It's not especially constructive to to reply to a detailed article on "X is
bad" with simply "you're doing X wrong", without offering additional advice on
what the author has missed or how to do it right.

It's almost a tautology: "My time machine doesn't work." "Well, maybe you
didn't build your time machine right!"

What do the effective teams you've worked with do differently and better than
the author's? How do they avoid the pitfalls, or why are the problems not
problems that the author outlines in "three general arguments" against it?
What kind of variation in teams should the author account for?

~~~
pkaye
Here are a couple things we tried for our scrum teams.

We let them choose the time of the day for the daily stand-up. One team agreed
on 11am. Another on 5pm. Some people see this 15 minute stand-up serves as a
major interruption. I see it as a way to consolidate some of the tiny
interruptions throughout the day into one.

Also teams have individuals of varying experience so we consider the stories
to be a team goal. This makes the more experienced individual more willing to
help those still learning since they are no longer making a trade-off for
their own stories vs somebody else.

Lastly, I've worked on projects from 1-20 people and beyond a certain size,
daily meetings are just mandatory or things fall apart. In a previous project,
I ran these big daily status meetings and they tended to run long. Everyone
hated it so I dropped it for a few days but then the code started breaking due
to lack of communications. We decided to split the meeting into smaller groups
and they ran quicker and there were less complaints. However we were still
able to keep the code quality.

But I think the most important things is "one size doesn't fit all." If
something is not working, have an open discussion within the team and suggest
some alternatives. If there is no avenue to give feedback, that is the
fundamental problem.

~~~
firepoet
> We let them choose the time of the day

Interesting language. "We let them" sets of an alarm for me. Why do they need
to be allowed to the choose time of day? Are they not self-organizing? Or is
this organization still in the midst of transformation?

~~~
pkaye
Yes we are in the midst of a transformation and most people are new to this.
And those with previous experience with scrum teams had lots of bad
experiences elsewhere (hour long stand-up meetings and inconvenient times,
etc.)

------
kogus
When the author states "The first question of the daily stand-up is pretty
pointless: What did you do yesterday?", he misses the real value in the
question, which is to motivate me to do something today which I will be able
to talk about tomorrow.

~~~
Finster
As a lead developer, if my developers are only motivated to do something each
day because of being held accountable the next day, then I hired the wrong
people. I want people to be self-starters. I shouldn't have to babysit and
micromanage what they're doing each day.

We use stand-ups as opportunities to discuss obstacles that people are
encountering and discuss opportunities for pair programming. I use them as an
option in my training toolkit. If we're working on fairly routine things (like
setting up unit tests, database layers, etc.) then I don't bother with stand-
ups at all unless I sense a need (like someone hitting a wall).

~~~
claar
"Self-starter" is one of many good qualities for a developer. Here are some
others off the top of my head:

    
    
      * Creative
      * Detail-oriented
      * Outside-the-box-thinker
      * Insightful
      * Meticulous
    

.. and so on. I've found that with any such list, people will already excel in
some, and still be growing in the others. Oftentimes these attributes are
contrary to each other -- your most creative developer is probably not your
most detail-oriented developer, for instance.

If you restrict your hires to all excel in a single attribute, such as "self-
starter", you may be missing out on some fantastic developers who excel in
other things.

In short, some of your developers may very well find daily accountability to
be helpful, and this doesn't necessarily mean they aren't fantastic developers
in other ways.

------
nbevans
Stand-ups don't work because the attendees are too focused trying to keep
their mind full of their current stack of work, to not forget anything, whilst
the 15 minutes of managerial meaninglessness plays out. It can be mind-
numbingly boring listening to other developers speak about some bug they are
working to fix when all you want to do is go back to your desk and continue
with your own work that is far more interesting.

Asynchronous communications are best for development teams. Taking out an
exclusive lock on every developer's full attention for 15 minutes is extremely
dumb. Stop interrupting, you dumb-ass managers, and let your team do their
work. They're smarter than you.

~~~
douche
This has been my biggest peeve with the standup idea. Quite often I'm in at 8
or 8:30, so if I actually get started working, rather than dinking around
doing email before a 9:15 standup meeting, I'll just be getting into the flow
of what I'm doing when it's time to come up and switch gears to do the
meeting.

~~~
flurdy
I not totally against morning stand ups but with people starting at different
times it may be easier to have a lunch time stand up.

People may start (culture/nation dependent) e.g. 8am , 9am or 10am. I am
usually a late starter so I hate stand ups at 9.30am as that as soon as I get
in and I have no recollection yet of what I actually did the day before. And
had I started a lot earlier also a sudden forced break may be breaking the
flow.

People are more flexible on when they can go for lunch, (and to encourage
people eating together in general for better team spirit), why not have the
stand up 15, 10 or even just 5 minutes before lunch. E.g. 12:45 each day or
11:15 (depending when lunch hour is appropriate for where you work).

When people realise unnecessary prolonging the meeting is eating into their
lunch hour some may keep their stand ups shorter :) And there is not much lost
productivity by just stopping for a few minutes before lunch.

(I did rant about this once [http://blog.flurdy.com/2013/04/do-not-stand-up-
in-morning-do...](http://blog.flurdy.com/2013/04/do-not-stand-up-in-morning-
do-it-at.html))

~~~
itsybitsycoder
And some people may not... leading to the whole team missing their lunch break
on a regular basis because of that One Guy who won't shut up. Guarantee that
would have happened in the last team I did "Agile" with.

------
aorloff
Coding and associated work efforts are largely individual. You sit (or stand)
at your computer and work alone. But in reality you are working in a group.
The standup reinforces the team nature of the overall effort. Humans are
naturally social, but the computer engineering work effort is done largely
individually. Something is necessary to maintain the social element and that's
where standups come in. Other meeting patterns could work, but one at the
beginning of the work day where everyone "checks in" seems to work well from
the standpoint of managers whose job it is to corral independent workers of
different strengths. If your team doesn't need a standup that's great, but if
the team starts to need one you will wish you had been doing it all along
before the balance got out of whack.

------
Osiris
In my team, we do stand-ups in chat. It's basically just to get a sense of
what the UX guy is doing, how the UI is coming along and what APIs that I need
to build or fix for them are, etc.

Since we do stand-ups in chat, it takes a whole 30 seconds of my time, and I
just read what the other guys are doing when it's convenient.

The only in-person planning we do now is our sprint planning.

~~~
blazespin
+1 Chat is awesome for standups and generally does all the required things.
Wish everyone did it this way. The one thing I'd like to see is more
scheduling of breakouts (conf calls) though. An ideal standup for me schedules
at least 2 conf calls per day to work through issues. This is very rough
estimate, fewer is fine only if everyone is chugging along great and knocking
off tasks quickly and cleanly.

I'd also like to say standup works great for remote teams.

------
mc32
My take on this, from my experience, is that some managers manage by cargo
cult. They skim HN, HBR, etc. and introduce things --whether they are
appropriate or not. Many times these are new (but not always young) managers
who are just learning and don't have a lot of experience to go by beside
reading some management books on the side.

A daily standup for a team which communicates well and has good interpersonal
communication between collaborators and clients is kind of overkill. So when
this happens, you jump through these hoops because that's what they put there.
My experience is that it's not worth bringing up the lack of value added to
the manager, as they see that as impugning their better judgement.

I can envision situations where a daily would be helpful, yes. It is however,
currently overused/abused as a management tool, in my opinion.

------
gedrap
Stand up is not easy to do well because people tend to abuse it a bit.

It's ok if everyone briefly answers these 3 questions and moves on. 1
minute/each, no big deal. I find it a bit useful when I am work on something
totally unrelated to the rest of the team.

The problem arises when someone abuses it and starts going into great
irrelevant details about what they are going to do or did and carries on for 5
minutes. Everyone loses focus, gets annoyed or interrupted, time wasted. Same
for managers who use it as a chance to discuss details with each member of the
team.

So all in all, little to be gained and 15-30min of time to be lost by
everyone. Not worth it :)

~~~
DanielBMarkham
One of the ways I train stand-ups is having teams do fake standups. Everybody
gets a card. Some cards just describe a couple of new things to report. Some
cards provide instructions to destroy the stand-up. Things like "Ask a lot of
questions when somebody else is talking" or "Ramble on for a long while about
the story behind a problem you had"

Then the team gets a chance to practice figuring out what's going wrong and
fixing it themselves. No SM or outsider needed.

Really 5 minutes should do it. 30-60 seconds for everybody there, no more than
7 people on the team. If you're going 10-15 minutes? Somebody is talking too
much.

Having said that, what I look for is a 3-minute standup that's over quickly --
and then folks mill about for another 10 minutes freely grouping and talking
about the stuff they've just learned and how to fix it. This should be an
emergent thing, and only happens when the team is working through a tough
problem. If somebody is managing that process the standup ain't working right.

Stand-ups are a purposeful interruption, but they should also be energetic,
to-the-point, and a way to prevent folks setting up a bunch of stupid meetings
to waste peoples' time even more.

------
jimbobimbo
My current team does the daily standup and we discuss only "what's changed"
(no changes - move along). It takes 15-20 minutes usually and I find them very
useful: they bring everybody on the same page, help spotting issues earlier,
prompt for deeper discussions after the standup.

------
melloclello
I mainly resent standups because most employers I've ever had scheduled them
at 9am, and I'm not really ready to talk to other humans yet at that hour.

~~~
tomjen3
Counterpoint: I am often in earlier than 8 but our semi-daily meetings are at
10.

The real problem is that we do the meetings in person, rather than by writing
a slack post/email, but there you go.

~~~
melloclello
I'd just like to say that 10am is still too early for me. After lunch is more
like where I'm at.

------
badthingfactory
I've been on three different teams in my career and each had different needs
in terms of daily stand ups.

team 1) At my first job I had a manager who spent his entire day putting out
fires. I would sometimes go weeks without speaking to him. During that time, I
would run out of work, be waiting on meetings he was supposed to arrange, work
on the exact same piece of work as another programmer, fall asleep in my
chair, etc. That team desperately needed a 5 minute meeting in the morning
just so I could touch base with him and let him know what I needed and stay on
task.

team 2) My second job was at a large company. Stand ups were regularly
derailed by one or two people droning on about trivial details. The room had
white noise generators which made it impossible to hear soft-spoken introverts
(almost all of us). Management used it as a platform to inform us how to
properly fill in time sheets and that was probably the most useful information
anyone ever gained out of those meetings.

team 3) My current team is small with several remote employees. We communicate
regularly through various channels on Slack. We recently decided to sync up
once a week, and that seems to work well. Daily stand ups have been
considered, but it really feels like a solution seeking a problem.

I'm personally not a fan of the daily stand up. Team 1 needed them, but only
because the manager wouldn't take 5 minutes away from his insane excel macros
to check up on the team. While the meetings did nothing for me on team 2, I do
think they were helpful for management. Team 3 has no need for a lot of the
same reasons outlined in this blog post.

------
tikhonj
To me it's also annoying as an unnecessary point of synchronization—for
everyone on the team. Everyone has to be there at the same time, which means
that either everyone has to arrive at the same time (annoying, inconvenient
and unnecessary) or everyone has to interrupt their work at the same time.
Aren't interruptions grand?

I would love something less synchronous and centralized.

The cost goes up quadratically with the number of people you add (every single
person has to spend 1 unit of time and attention for every other person) while
the benefit is limited to either the people working together most directly—who
should be communicating constantly anyhow—or for the manager.

Having everyone stand around to update the manager is not great for anyone
_but_ the manager, but of course they're the ones mandating and organizing
standups in the first place. I've seen a few cases where that's what standup
devolved into.

It's easy to do standup wrong, and the benefits of doing it _right_ are not
immediately obvious. I don't think they outweigh the costs, and I am not a fan
of the practice.

~~~
gohrt
> The cost goes up quadratically with the number of people you add

This is a feature: it incentivizes keeping the functional teams small.

> or for the manager.

This is your problem. The "manager" is not supposed to be present in a daily
standup, according to the design documents that introduced the term "standup".
The daily standup is for the dev team to sync up.

------
Yhippa
I see where he's coming from. In practice I've used the daily stand-up at a
large company and we pretty much did the opposite of things he mentioned in
the article that the stand-up is supposed to do. We ended up doing the stand-
up for not just one project but multiple concurrent projects. People would try
to solve problems and went way off track during the meetings. They lasted a
lot longer than 15 minutes for sure.

Worst of all I felt that this meeting was a built-in context switch so I had
to stop what I was doing, participate in the meeting, then get back to what I
was doing which took a little bit of time.

Where I've seen it work we had competent and motivated people who wouldn't
wait for a problem to fester on the side or delay the whole project. Also we
ended up using tools (I know, anti-Agile) like Jira which really helped us
keep track of where we were and where others were in their work.

I'm not a big fan of the daily stand-up but I'm sure there's a place and time
for it. You just have to be honest if it's working for your situation or not.

------
vetler
I've worked in places where people just say "nothing to report", and the
meeting was over in one minute, and that's great - the team is using good
tools and communicating well.

I've also worked in places where you need to have a daily session where we
communicate, because there are so many different (often unforeseen) things
happening.

Communicating is a necessary part of working together, and a daily standup
gives everyone an arena to talk with each other - not everyone are good at
communicating as much as they should be, unfortunately, and this makes
everyone reflect and vocalize what they're doing ... which is a good thing.

Personally - I don't need daily standups, but development is a team effort.

------
phn
Agile, in my understanding means "adaptive", and people often forget that
part. If meetings or whatever else aren't working FOR YOUR TEAM, then don't do
them. I think the retrospective is the only real cornerstone. It should
happen, even if everyone just says "I think everything is working fine".

That being said, I think stand-ups create a "common time" where everyone can
get be aware of what everyone else is doing, which removes that
worry/distraction from everyone's mind at every other time. (I think being
aware of what other people are doing is important, especially on a small
company).

~~~
wan23
This is the best advice possible to people who have dysfunctional agile
implementations. If what you're doing isn't working, stop doing it and try
something else. The only thing that you should consider mandatory is a
regularly scheduled retrospective. (And if people complain that the process
keeps changing too quickly, you can always decide in the retrospective as a
team to have less frequent retrospectives).

------
dpweb
Some thoughts about dailys as we've started to embrace some scrum elements
over the last few years.

I've found they are more valuable on some projects than others because of the
number of people on the project, how sharp they are, timeline and amt of work
to be done, etc.. We've found them more necessary in projects with larger
groups and shorter timeframe.

One counter-intuitive thing about them. "Oh great another meeting".. You may
get back some time spent on email correspondence or impromptu meetings when
every issue has to be emails back and forth. Just hold it until the next
standup.

The author said you don't want to wait 8 hrs until the next mtg to alert the
PM of a blocker, but often you can make progress on other tasks - save the
emails - or even worse - the impromptu meeting. Often, it can wait until
tomorrow.

Most important, don't let the standups get off track. Either a PM who tries to
turn it into a regular meeting. It's not a 30 or 60 min. status update they
may be used to. Or - who lets people run wild. It's 15 minutes and that's it -
and take things offline.

~~~
optimusclimb
Where did the term "offline" come from? It's bewildered me for the past
decade. It's always used in a meeting, which is inherently "offline".

It's also always code for "this is going to get ugly", or "this actually
involves thought". So again, don't really get why "offline".

Additionally, I find it amusing (and agree with the author about standups btw)
that anything which actually requires discussion among team members, and is
interesting, and usually...worthy of us MEETING with each other...gets ordered
out of the "meeting". Mundane status updates generally get ignored while
everyone else looks at their phone or fidgets.

------
jvoorhis
At the risk of a downvote, I find it difficult to read a criticism of
communication methods and techniques in the presence of poor grammar.

------
itamarwe
I don't think that's an anti-pattern. You'll be surprised how difficult it is
to keep everyone focused on the goals of the sprint, or even to make sure they
are working on the tasks of the sprint. I've seen teams that fail to stay
focused even with daily standup meetings AND a huge scrum board.

------
bytasv
You might agree with the author if you are working with self-managing team
where everyone is capable to deliver something daily.

But more often that's not the case:

1\. "Members of the team already know what I did yesterday, because they can
see the completed items in the "DONE" column on the Scrum Board." \- this is
not true, because in case someone is a slacker in a team and does nothing you
won't be able to track that, you can't see progress of "doing nothing" unless
two days in a row you hear the same person still "working on the same
problem". Everyone who participates in a stand-ups knows that bad feeling when
you are on a standup and you don't have to say anything about what you have
done, you force yourself to fix that because that embarrasses you.

2\. "This question is a little maddening, isn't it? I can tell you what I'm
planning on doing today, like maybe finishing the task that I just told you I
was halfway through, and then grabbing the next..." \- this is to prevent
multiple persons on jumping the same task, that's your daily planning.

3\. "Waiting for the daily stand-up is a terrible way to deal with
impediments." \- again, nobody forces you to wait for a standup to deal with
problems that arise, this is used to explain why were you spending so much
time on fixing some small bug. For example - you spent whole day trying to fix
a bug, but the fix itself was a "one-liner". After looking to your commit I
could make a false assumption that you were slacking the whole day and only
made a single "change" where on a standup you have time to explain what
problems forced you to spent whole day on tracking down that bug... Another
example - someone spends whole day on a feature but still doesn't finish that
even though it's trivial to implement, he might either explain that he faced a
problems that prevented him from implementing that feature faster or he won't
have anything to say because he was slacking

------
bitwize
> Each member is not a silo, but a cog in a highly functioning machine (you're
> much more than that; I'm terrible with analogies) that needs to work
> cohesively with the rest of the machine to function successfully.

"A company--"

"Is like an enormous clock."

"\--is like an enormous cl--yes, precisely!"

I'm a bit tired of this idea that because we work with other people we should
be in a near-constant state of "collaboration" with others. (See also: the
most common excuse for cubicles wuth waist-height walls instead of actual
fucking offices.) Sometimes cranking out a piece of code requires nothing more
than focus and sitzfleisch. One function of the stand up is to provide a
Schelling point for team members to synchronize their models of what's getting
done, after which they can go back to their distraction-free deep hack mode to
actually do it.

~~~
collyw
Its a pain in the arose when people can interrupt you constantly. And a
complete productivity killer in many circumstances.

~~~
bitwize
Monkeyfighting snakes on a Monday-to-Friday plane ain't got nothing on
autocorrect censorship: "pain in the arose", "what the duck?", "you're gonna
see some serious shot".

------
megablast
> If they don't happen to see me move my task around, they probably noticed my
> Pull Request being put into GitHub, and various comments and discussions
> going back and forth on the code and feature. Additionally, we use HipChat,
> which receives notifications of GitHub activity as well.

Yup, because only developers should be at standups. Designers, UX, BAs, data
guys, etc... should not be allowed to come to standups.

And your project is so small, you can track when everyone moves their cards.

> I can tell you what I'm planning on doing today

Yup that is fine. If you are being constantly prevented from finishing that,
then that is a problem.

> Waiting for the daily stand-up is a terrible way to deal with impediments.

You are doing it wrong. Deal with the impediment straight away, and then start
tracking it on the board. Keep everyone informed about the impediment, so that
if it touches other people, they know about it.

------
westoque
The daily stand-up for me is summed up in one word:

"visibility"

This is the reason why I like standups. This gives everyone a good view on
where everyone is, how they're doing, or if they're having a problem. This
gives more focus on the product and business value and keeping everything on
point.

------
ExpiredLink
> _Daily Stand-up is a keystone of the Scrum framework_

It's the Daily Scrum.

> _1\. What did you do yesterday?_

> _2\. What are you going to do today?_

> _3\. What impediments have you encountered?_

Seemingly the main purpose of Scrum is to exert more pressure on the
individual team member to avoid loitering.

------
jkulmala
I've used Scrum/Agile for several years and daily stand-ups seemed to the
thing a lot of people hated. As a started my own business (Financial Analytics
for SaaS) I finally understood why. An effective process shouldn't need
polling to keep it going - which the meetings really are.

I'm happy to see new processes appear, where that kind of extra hassle is
removed, like: [http://timeblock.com](http://timeblock.com)

In timeblock, communication happens when a developer can't get his task done.
Otherwise everyone can assume that the week will proceed as planned.

In practice this seems to keep people happier than Agile/Scrum.

------
UK-AL
The problem with a lot of developers is that they just want to be sit in a
corner, and figure stuff out on there own.

When in 3 words you can ask for help from someone who's done it before, and
save a lot of time for the company.

There a lot of personality types that just won't ask for help, unless you make
it a part of the routine.

Stand ups go bad when employers try to use it to "control" employees(You must
be in at this time, put social pressure on you to complete things etc) as
opposed to just a casual routine thing.

Tends to be good when implemented by devs themselves, bad when its enforced as
strict policy, and business people trying to squeeze the last bit energy from
the dev team.

------
tosh
The more people you have the more complicated it is to align everyone. Stand-
ups are a way to help with that.

The interrogation-style way of iterating over people imho does not work as
well as iterating over work items (kanban board).

That said, in the end it is just a tool to align people. If you have a
distributed team over many time zones doing daily stand-ups might not even
work well.

In the end it is about achieving the alignment, not about doing the ceremony.

All in all processes can be super helpful, but they are just a tool. Similar
to frameworks and libraries in programming you need to know when and how to
apply them to the situation, they don't magically make your own code better.

------
re_todd
I worked at a place that did a stand-up once a week, and that worked pretty
well. The communication between everyone was pretty good, so maybe other
places that don't communicate well could not get away with that.

------
ollysb
Verbal communication is far richer than written. You gain insight into how a
developer feels about aspects of their work. Is there something they're not
happy with but aren't comfortable talking about, are they enthusiastic about
something which motivates other team members? Team dynamics can't be distilled
into written communication. The standup can surface things like tensions
between team members or a drop in morale. It's not just there as a status
update, it's there to solve softer problems to help turn a group of developers
into a great team.

------
DanielBMarkham
I teach this stuff. I am also not a process wonk. In fact, I'm just a coder. I
help teams because as a coder I've seen hundreds of teams in dozens of
industries. All I care about is what works.

And standups fascinate me. I have seen teams that were communicating horribly
-- one guy would go off and work by himself, one person struggled with some
new tech but couldn't admit it, one person was too shy to talk about his
problems. You get them doing standups well and suddenly these things start to
work themselves out.

But the really crazy thing is that those same teams, when things start working
out? Many times the same members will leave the standup going "Geesh. What a
waste of time."

It's like when you're inside a standup you can't see it working. Very weird.

I agree with most every point the author makes here. I do not, however, agree
with the conclusion.

Communication in a team is a completely different type of thing than
programming or math. It's not just the movement of data around. It's a social
thing. There are no red lights that go off or alarms that flash if you're
doing communication poorly. Everybody just keeps working as if communication
was going along fine. So it's not something you can do, inspect to see how
it's working, then adapt. The feedback loop is too subtle.

So standups end up being something akin to brushing your teeth. You do it
daily -- sometimes multiple times daily -- because over the long run folks
have observed that you'll be much happier. You do not brush your teeth and
then go "Wow! I feel so great because I brushed my teeth!" Doesn't work like
that.

If I had to toss out every piece of process BS I could, I'd probably keep
standups, co-location, and mob/pair programming. Some kind of kanban/story
board and TDD/ATDD would come a close second, but only under certain
circumstances (commercial software work, more than 2 folks, etc) In general
you add in stuff as your project grows more complex, but standups are pretty
useful even if it's just you and another coder talking over the phone every
day at 9.

One nit with the article. In it he says that the third part is "What
impediments have you encountered?" I prefer to phrase this as "Is there
anything we can help you with?" People have problems when they work. What I'm
really want to know is "Have you taken some time to think about whether other
folks on the team can help you with anything? Because that's what we're here
for". Yes, you should be doing this constantly. No, people do not do this
constantly because they get their head stuck in their work and need a moment
to look at the other guys and reflect.

------
codeulike
Author quotes this

 _Individuals and interactions over processes and tools_

but is explaining that his tools (github etc) should let his team know what he
did yesterday, and that he finds it pointless to tell them face to face.

------
erikb
If you have a team that works fine, then yes, okay, don't do that stand-up.
But usually people don't know what the other guys are doing in the other
office or even just the next guy, because projects are complicated in real
life. And if you really follow that pattern, then each member takes less than
a minute and you are done in 5-10 minutes with a whole team. There is nothing
to optimize, even if it's unnecessary.

------
hawleyal
The daily standup is good for teams that are not functioning well. You
describe how a well-functioning team does not need a daily standup.

------
fsloth
I think a scrum/kanban board is a very strong instrument in implementing a
healthy development process. There should be an explicit method to updating
the board - even if the method is just "you can move only your own tickets".
If there is an intact development process that lacks a board&ticket system I
don't see it is necessary to implement one. However, broken development
processes often have a problem of priorization and communication and
discplined ticket and board tracking system can help there a lot.

Now, the daily standup is one method of updating the board with the added
benefit that it provides maximum bandwidth of information of team status in a
brief time to all team members.

The author stipulated that in their team everyone else already knows what
others are doing. If so, great. However, I think it is really naive to think
this would hold for all teams. For teams that lack this amount of coordination
and transparency I would see a healthy standup that is brief and to the point
improves teamwork as it helps synchronize work.

Not all teams are composed of equal members. There can be coherent products
whose team members work on completely different areas of the code and the
product to implement the feature and in those instances I would imagine it
would slow down total velocity if everyone would need to keep tabs on what
everyone else is doing. For instance, a dedicated tester might be a part of
the team, who is not so interested in explicit submits but rather what is the
current end-user interface status.

Not all people are comfortable in asking support due to shyness and so on.
Having an explicit process of synchronizing work and announcing impediments
can help there a lot. Since impediment removal is part of the process, the
person asking for help does not need to feel like a bother (and they notice
others need help too), the work progresses and everyone is more relaxed. The
counter argument is that people should already be good at teamwork - sadly
this is not true, great teamwork is not inbread to humans, but, everyone can
learn it and having a teamwork supporting process in place helps to maintain a
healthy culture.

So, I suppose, in the end, it's not necessarily about standup vs. no standup,
it's about having processes that helps supporting a healthy team culture,
whatever it is. For small teams with long term stability this is less of an
issue but the more ephemeral the team constitution is and the larger it is the
more value a healthy standup process can bring (healthy as in by-the-book-
scrum healthy - to follow the manifesto style - I prefer a by-the-book-scrum
standup that is about bringing value to the team to a standup that is
converted to a managerial status update).

------
bjwbell
I've never worked on a team that did /daily/ standups & I plan on never doing
so. Heck I missed half the meetings we had on my previous job and we only had
maybe three a week. Was I a jerk? Yes. But I also got 3x more done than by
sweating the superficial stuff.

~~~
woof
3x more of what?

* Stuff you deemed important?

* Stuff the team deemed important?

* Stuff the customer deemed important?

------
fsloth
I cannot agree with any of the specific points (1., 2. and 3.) being
generalizable enough as arguments against standups. They may be valid notions
where the author works. Perhaps this writing was intended rather as tool in
office politics than general rumination on the topic?

------
iopq
The worst part about it is it becomes a way to force people to come in at a
certain time. Look, if I only have GOD FORBID 6 hours of time overlapping with
someone and want to come in 2 hours later, I think I can SOMEHOW catch them.
Especially since they sit to my left.

------
adamconroy
I don't agree with the term anti-pattern in this case, but I find standups
boring and a chore. I also think standups drive a culture of velocity instead
of progress, which can be a little maddening.

------
DigitalSea
I have worked in quite a few Scrum/Agile workplaces over the years. I have
seen it work really well and I have seen it work horribly as well. The weakest
part of Scrum is definitely the daily stand-up. I have often questioned
whether or not I am wrong over the years because it seems the bulk majority of
those who have worked within a Scrum ecosystem seem to like the daily stand-
ups. I have voiced my concern about them over the years, but it usually riles
people up and ends up being a one-sided debate with those in favour making you
feel like a bad employee.

The biggest gripe I have with daily stand-ups and I am sure there are others
(including the author) who agree with me on this: they often run over and turn
into meetings/debates. While some workplaces I am sure have it down to a
science, I routinely encountered stand-ups turning into group bitching
sessions about a bad deploy, a changed requirement or issue someone is
happening as a result of something that someone else did in a previous release
or a management decision. Instead of staying on task, they would often derail.
Even when someone would try to steer the stand-up back, it was too late. It
would be short-lived and it would derail again. Time after time.

There is nothing worse than the feeling of being in a stand-up knowing that
you have a few tasks with looming deadlines that you want to get done. This
sinking feeling in your stomach that time is escaping you and there is nothing
you can do about it. That the 15 or 20 minutes the stand-up is going for, you
might have been able to knock one of the tickets off your list and reduce your
stress levels a little bit. It's a horrible feeling and one I have felt many
times over the years. It's a kind of anxiety that stand-ups seem to make even
worse.

More often than most, the question of what did you do yesterday usually
results in: I don't remember. And you know what, if you have a lot on your
plate, that is a fair statement to make. What is the point of saying what you
did yesterday other than to appease to micro-managers (as the article points
out)? Does Steve the system administrator truly deep down inside care about
that bugfix I finished yesterday? No. The stand-up seems to operate on this
purist view that people have a set plan of what they will work on for the day.
As a developer what I plan on doing for the day about 90% of the time never
works out how I would have imagined.

I come into work with the greatest intentions of finishing off an outstanding
task or finishing off some low-hanging fruit tasks in Jira, but then something
will break, someone will ask me to do something and say that it is urgent and
BOOM! there goes my "planned" day of doing what I planned to do invalidating
what I just said in the stand-up.

I feel like I am in a minority that views stand-ups as distracting, starting
out as status updates that usually diverge into meetings that cut into my
precious morning. Don't get me started on what happens when someone is working
from home, has to dial in and all you can hear is children screaming or dogs
barking (I've beared witness to that a lot).

These days we have tools like Slack or Hipchat, we have collaboration
platforms like Github, Bitbucket and peer review applications like Crucible. I
feel like the stand-up is an outdated relic in todays development ecosystem.
Instead of making it a single discussion everyday, how about we work on making
teams talk together on a daily basis when they have a problem instead of
waiting until the following day to bring it up?

A place I contracted at recently used Slack and they had a #standup channel in
which people would post what they would be working on today, there was no
requirement to dwell on yesterday only the today. And if there were any
blockers or issues, you were encourage to create an issue in Jira and tag your
manager instead of voicing them in the chat. In my opinion this was a good
approach because it meant people could give an update without distracting
others and on their own terms.

Stand-ups encourage anti-communication in that they seem to be used in place
of actual communication, they can also feel like pitchforky at times: meaning
people often get publicly implicated and blamed for issues/hold-ups which
usually results in a defensive response. "I can't do anything until Michael
addresses my blocker" to which Michael would reply, "I can't get to Daves
blocker task because I keep getting asked to do other things"

~~~
vpeters25
> The biggest gripe I have with daily stand-ups and I am sure there are others
> (including the author) who agree with me on this: they often run over and
> turn into meetings/debates.

In my last job we rotated scrummasters every iteration. Daily meetings were
not starting on time and running long.

My first turn I closed the door and said: "Ok, I want to keep this under 5
minutes so lets go around quickly". A couple of the guys who usually showed up
late came in when we were almost done. I completed the meeting with a friendly
reminder the meeting starts at the agreed time, sharp. After that, everybody
showed up on time and meetings ran less than 5 minutes average.

> More often than most, the question of what did you do yesterday usually
> results in: I don't remember. And you know what, if you have a lot on your
> plate, that is a fair statement to make.

Someone having "a lot on their plate" is a symptom of poor iteration planning:
no team member should be working in more than one thing at a time. Also, tasks
should be sized between half a day to 2 days of work (around 3 to 12 ideal
hours)

If your scrum board shows a bunch of small tasks less than half-day work, then
your team went too far micromanaging and should combine them into single tasks
that take no less than half a day to complete.

~~~
DigitalSea
In my experience rarely is Scrum/Agile implemented into an organisation in its
pure and intended form. I think companies start out with the best intentions,
but the nature of modern software/web development is things are sometimes
difficult to plan for. In the beginning it can be great, but once again,
things start to derail. Sometimes companies want to implement process, but
they realise the amount of organisational work that goes into adhering to
Scrum & Agile, they get half of the way there and half-implement it.

If a debilitating bug is preventing your users from using your app, you're
going to make the team go out of their way to fix it (even if it was not
planned). If "higher ups" want to implement a last minute feature because an
investor meeting is coming up and a competitor just launched said feature, no
manager is going to firmly say "no, you can't have it unless we plan for it"
to the very person(s) that pay their salary. Sprint planning meetings and
poker are great for estimating new features most definitely, but they fail to
really and realistically take into account that sometimes SHTF and no amount
of planning can accommodate for that.

In the real world developers don't get to go into sprint planning meetings,
get a set amount of work and no that's all they'll be working on. I mean,
that's how Scrum is supposed to work, right? But how many developers can
honestly say it stays that way? Scrum/Agile does not stop people going outside
of the framework (and in my experience there are always people that do) and
assigning you work or asking you to do what they think are "small tweaks" and
"quick changes" which usually blow out into one or two day tasks that take you
out of the sprint workflow, then the burndown graphs start looking bad and
your manager starts wondering why the graph is not looking so good.

The issue with Scrum/Agile is not the fault of the methodology itself, it is
the implementation. On paper it looks great, but in the real world and this I
need it now society we have created, it becomes increasingly hard to stick to
set fixed processes when things need to be done right now. I don't doubt that
some places are doing Scrum/Agile right, but from what I have discovered and
again this might just be on account of bad luck, most places are not doing
Scrum/Agile correctly and it only takes a little imbalance from the
methodology to throw everything into disarray.

In my experience sprint planning does not equate to less work or more balance,
it doesn't reduce the stress. Yeah, you know how much time you have in your
sprint period, but usually there are tasks that only specific members of the
team can work on. Meaning someone is usually doing more than someone else.
Once again though, maybe I have just been unfortunate in the places I have
worked which haven't implemented the pure and originally intended form of
Scrum/Agile.

~~~
dragonwriter
> In my experience rarely is Scrum/Agile implemented into an organisation in
> its pure and intended form.

Well, Scrum/Agile isn't a thing, its two _very_ different things, and if you
implement either of them in its "pure and intended form", you are absolutely
_not_ implementing the other in its "pure and intended form", since Agile is
an approach that disfavors rigid externally defined methodologies in
preference to adaptation to the needs of the team, and Scrum is a rigid,
externally defined methodology with a rulebook of specific practices which, if
you aren't following, you aren't doing Scrum.

An organization taking an Agile approach may adopt Scrum as a starting point
for its internal processes as it evaluates what works for the teams it has on
the problems it is working on, and adjust the details from that baseline. But
if you are working within the defined bounds of Scrum you aren't Agile, and if
you are Agile you are not committed the rules of Scrum.

Confusing Scrum for Agile or vice versa is a sign that someone doesn't
understand either Agile, Scrum, or both.

------
lectrick
Something like [https://www.workingon.co](https://www.workingon.co) might be
more efficient.

------
am185
have done retrospective after reading this article; my "what needs to go" is:
\- not opening rants.

------
mattxxx
Sharing knowledge and communicating ideas are the hardest parts of working in
a team.

------
warkid
Standups can't replace pair programming

------
vacri
So, our commit notifications in hipchat all come from the same user(s) who
pushes changes to master. You can't always tell who made the commit, and not
all commit messages are informative. And even then, not everyone religiously
watches chat or issue boards, so monitoring what your teammates are doing
using that mechanism doesn't work for everyone.

And in a multidisciplinary team, standups help with cross-pollination. I'm an
ops guy, but in standup I find out what the design guy is doing. He doesn't
commit to a repo that posts notifications, but I get an idea of where future
ops work is going to land.

If standups don't work for your team, don't do them. But they're not an anti-
pattern.

~~~
blister
Shouldn't you also see the pushes everyone is making to their upstream
branches and the Pull Requests?

That's the useful information I like to see. HipChat + Bitbucket is the most
powerful combo I have for keeping up with what everyone on the team is doing.

------
michaelochurch
The daily standup, _if people actually stand and if it 's timeboxed to 15
minutes_, is the least broken thing in all of Scrum/Agile. Honestly, I think
it can be a good thing.

No one (except for terminal middle managers) likes status meetings but the
alternative (in many settings) to a fixed daily status meeting is random,
unpredictable status pings from management which are far more disruptive to
the daily work flow. I'd rather give status at the same time every day than
deal with the irritation of a "What's happening?" interruption.

As long as people actually stand and the meeting ends at 15 minutes and there
is absolutely zero risk of follow-on meetings, stand-up is probably more good
than bad. Done properly, it eliminates the resentment and politics that come
from the "Does Tom actually _do_ anything?" type of speculation.

That said, Scrum is just horrible. The whole package is a bundle of fail.
Senior developers will resent it and leave, and while junior developers may
benefit from the structure, what they really need is mentoring and they're not
going to get it when all the seniors are either (a) trying to make an
acceptable "user story point" count for the week or (b) looking for other
jobs. Scrum sucks. It never adds, it's either meaningless or it detracts.

If you're really not convinced, read my take-down of Agile/Scrum on Quora:
[http://www.quora.com/Why-do-some-developers-at-strong-
compan...](http://www.quora.com/Why-do-some-developers-at-strong-companies-
like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church)

I don't know why it is that all this Taylorist pseudoscience that failed in
the rest of industry has made a home in the software industry. Fuck Scrum and
fuck Agile, and this is _not_ "excessive negativity" because I have seen that
shit burn down (pun intended) billion dollar companies-- not meaning "the
culture became something I didn't like" but "Scrum directly caused it to lose
80% of its market capitalization". That shit is fucking _toxic_.

~~~
logfromblammo
I worked for a few years in a company that did salutary scrum, which is to say
that we shoehorned our developer-led process into the correct buzzwords and
cargo cult practices to make the management think it was Scrum. That was the
best job I ever had. I was very sad that the company was purchased by a larger
company with a history of annihilating their acquired development teams
without thinking. (That practice actually called into existence one of their
current major competitors, as an example of the Batman Effect in action.)

As a result, I didn't think Scrum was all that bad, until the worst job I ever
had instituted the daily stand-up meeting.

Anecdotally, Scrum will do nothing to help an already good development
process, and will make an already bad development process much, much worse.

As such, it means nothing to me if a company "uses Scrum". I have to look at
the individual development teams, and see for myself how they _really_ do
their work. A decent development team can create a facade over their own
working process that looks enough like Scrum that management won't interfere
with it. A horrible team can create a Scrum facade over their own process that
multiplies aggravation for everyone with no benefit to productivity.

I'd even go beyond "fuck Scrum" to spurn any development process that has a
brand name and a dedicated consultant ecosystem.

------
dotdi
I think this blog post does not comply with the 'new' no-gratuitous-negativity
rule on hn.

Anyway, behind your rant I just sense the notion that YOU think scrum doesn't
fit YOUR working style. Doesn't make it an antipattern by a long shot.

------
benjaminwootton
The author sounds like someone who doesn't want to communicate and would
prefer to stare at a screen all day.

It's just 15 minutes to give people a status update, sync up on what you are
working on, and surface any problems. After that you can get back to your
keyboard, headphones on and be anti-social for the rest of the day.

Too much process is bad, but complaining about a 15 minute sync up is just
petulant.

~~~
suppressingfire
While I broadly disagree with the OP, I don't think this critique resonates.

The OP argues for more communication and collaboration throughout the day:
Don't wait for the standup if you're blocking. Share status information
immediately. Keep up to date with teammembers constantly.

Also, dammit, it's not a sync! And if your team has so many members that it
last 15 minutes, there are too many people on the team (or the team is being
too lenient with the format).

~~~
benjaminwootton
There is some stuff on the edge of my perception and interest that I don't
want to hear about immediately.

Instead, 15 minutes at the start of the next day are ideal to get a batch
update on how the development of component X or the provision of server Y is
progressing is perfect.

