
The good, the bad and the ugly standup - kristoff_it
https://kristoff.it/blog/good-bad-ugly-standup/
======
overgard
I never understood why the standup cant just be an asynchronous chat room. The
information is easier to review and follow up on, and people can check in when
its not a disruption. My gut feeling is, at most places, 90% of the purpose is
for the pm to feel like the captain of the ship, and 10% is an attendance
check.

~~~
ssss11
I’m a PM and (perhaps not like the others, but) in my mind the standup is not
just the status update, the important bit is to convey any roadblocks or
problems you’re facing and the team or the PM can assist to resolve them. I
think though, that many teams out there probably do not feel comfortable
enough to talk about such things and the standup merely becomes the status
update bore.

~~~
Redsquare
This installs a ridiculous mindset, what if a dev hits a block at 11am and
your ceremony is at 10am?

------
santoshalper
I have been an engineer or in engineering leadership most of my life. Now CTO
of a large company. Nobody wants to say it out loud, but what we really need
to do is treat engineers with respect. Give them a quiet place to work and
leave them the fuck alone. Agile is just a watered-down compromise. We still
get to have project managers, we just call them scrummasters and they get to
bother the engineers slightly less.

~~~
alicorn
How cute. I tried your suggestion once. What I got was an overengineered,
poorly documented delivery that matched the spec about 50%. Oh, it was also a
year late. Sorry, but processes are there for a reason, and the reason is,
broadly, that getting an average team of engineers to deliver on time,
according to spec and without diving all the way down every overoptimization /
navelgazing / random interest / flamewar / framework flavor of the day
rabbithole there is is otherwise impossible. With process it becomes at least
a tiny bit more akin to herding cats instead of just watching them run amok
every which way.

~~~
musicale
> on time, according to spec

time, features, reliability: pick two

~~~
NikolaNovak
Typically, the triangle involves money on one of the axis.

In principle you could have those three if you throw enough resources at them.

------
tvanantwerp
Once had a daily standup with 30-35 employees, all different teams and
projects, and no one enforcing brevity (going down the rabbit whole was
common). The whole exercise felt like taking attendance. After the one senior
person who insisted on them left, we dropped them immediately with no negative
consequences.

~~~
mrbrowning
> The whole exercise felt like taking attendance.

In my experience, almost anyone who insists on synchronous, in-person standups
is doing so because they want them to function this way, whether consciously
or unconsciously.

I also suspect that standups with no active brevity constraint frequently come
about not because of a lack of leadership but because they're actually a means
for disordered thinkers to feel productive, which I think goes part of the way
towards explaining why you see such irrational attachment to standups even
among ICs.

~~~
pieterhg
What is an IC?

~~~
jiofih
Individual Contributor. Manager euphemism for a cog in the machine.

~~~
MockObject
What is the alternative to being an Individual Contributor? An...individual
non-contributor? Or a non-individual contributor?

~~~
jiofih
Management and leadership roles.

~~~
MockObject
And they aren't said to contribute? Odd terminology.

------
kube-system
I think that the people who don't like standups, are the people who have never
been a part of one that works well. This isn't surprising, because most don't
work well.

There are two critical things that a leader must do to run an effective
standup:

1\. You must have a leader who is willing to enforce the rules in order to
effectively extract the right information to support managerial tasks (and not
arbitrarily, but through team buy-in), and

2\. They must be willing and able to understand most of the technical
intricacies of the tasks taking place.

In my experience, most organizations' standups are run by people who fail at
one or both of these.

Maybe they'll put in a PM who enforces the rules, but doesn't understand (or
doesn't care to understand) the tasks the developers are doing with enough
detail to be an effective facilitator. They act as a note-taker, letting the
developers manage themselves ad-hoc, and don't ask questions unless someone
specifically brings up a blocker. This can work with a team 100% full of self-
starters who are comfortable with asking hard questions of each other, but
that's your only hope.

Or on the opposite side of the spectrum, you have organizations that put more
senior developers in that role. Then, you often end up going down design
rabbit holes until you've run out of time, and you never end up doing the
tasks that you actually needed to do: planning everyone's time effectively,
and recording/communicating progress so that stakeholders expectations are
correctly managed.

In both of those failure cases, you end up failing to deliver a quality
product on time and/or fail to communicate expectations to stakeholders. In
the first case, you made a plan, but it wasn't a full picture. In the second
failure case, you had all of the right tasks figured out, but you failed to
plan and communicate it.

~~~
WJW
If most people are unable to do it right, the act is too difficult. Saying "it
works fine if everyone does as they should" just ignores that people don't
usually do as they "should" and is not very useful.

~~~
kube-system
I disagree. Most new ideas implemented in the workplace come with generational
learning curves, even when history has shown them to be good ideas. This is
just a cyclical skills gap.

Few people running software projects have formal study that spans both
management and software. Many have _neither_ , in my experience. Sure, formal
study is not a requirement for good performance, it sure helps to get everyone
in an organization on the same page.

------
fourmyle
Yesterday I did a thing, Today I am doing a thing and currently I am or not
able to do that thing.

For me the main problem with stand-ups, especially when they are more than 2
times a week, is that they make it impossible to do lengthy unstructured work.
It's embarrassing to say that you worked on something and didn't get anywhere.
My theory is that max task size becomes the length of time between standups in
most orgs.

~~~
soinus
Same here. After working in academia with no agile process (worked well), in a
startup or around 20 engineers using OKRs (worked great) and a big company
following SCRUM (nightmarish) I could not agree more with you.

I believe weekly OKRs are the best of two worlds: they are restrictive enough
to feel the peer pressure for ones committed goal and descriptive enough for
any manager to get a grip on the current situation, while at the same time
relaxed enough for engineers to not feel like they are trapped in a cage. One
week is plenty of time to either finish some work that just needs to be done
or write a small prototype. In fact I liked it so much, that I brought the
idea of OKRs back to my research lab and everybody loves it!

Scrum is the worst of this for me. We've rotated through a couple of daily
formats and it always feels micromanaged and pointless. In addition to that it
takes away the personal feeling of achievement. My best work in this framework
has been done when I ignored the framework as the whole...

------
lunias
As with anything "agile", it pays to stop and take stock of how your processes
actually address the 4 key agile principals:

\- Individuals and interactions over processes and tools

\- Working software over comprehensive documentation

\- Customer collaboration over contract negotiation

\- Responding to change over following a plan

I personally interpret "individuals and interactions over processes and tools"
as a warning against the snake oil and magic bullets that agile consultants
sold / are selling to corporations.

Standups are not at all a bad idea, but I feel like most implementations are
simply a response to a prescription rather than a symptom. Nor do I feel like
the prescription is particularly effective: rather than using the structure of
a standup you could just, of your own volition - when useful; take an interest
in your teammates' work, talk to them, and collaboratively come up with a
solution.

~~~
29athrowaway
This website has an interesting response to the agile values:

[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

Excuse the profanity, btw.

~~~
lunias
Haha. Love it! The satire; not the fact that it's largely in alignment with my
experience in enterprise...

------
geoelectric
Excluding QA wasn't a plus. Quality works better when there's an advocate from
the beginning.

Problem is a lot of companies only engage QA for post-build integration
testing. They try to phase it as a mini-waterfall within the agile cycles,
which doesn't play well with agile and drags the process. At that point,
leaving them to their own horizontal meetings seems like a plus, but there's a
ton of opportunity cost for not having them in the primary conversation.

Other companies try to leverage QA for unit tests, but those really should be
written by whoever wrote the interface as part of ensuring their intended
contracts are fulfilled. That makes unit test writing not really a good QA
role, other than making sure they're there.

The exception would be if you're going to pull QA in and pair-program/test TDD
style--which is its own potential boondoggle. But you need real SDETs at that
point, as opposed to scripters. Real SDETs aren't terribly common, and are not
terribly cheap as they're niche specialists.

The best solution I've seen is to split the advocacy/short-term roles and the
test/architecture/long-term development roles (even if it's two hats on one
person), have them in the meeting for the former and have the horizontal run
their own projects with milestone syncs for the latter.

At that point you can treat the short-term role as a team member, and the
long-term roles as an internal vendor or external dependency (i.e. no
expectation of control). Any sort of one-size-fits-all approach won't work.

~~~
qa_guy
Just curious - when you say "(real) SDET" can you expand on what that means
for you? I ask because I started out as SDET, but my title is now QA
Automation Engineer. I sort of see myself as a developer working in a QA role
- I work on testing frameworks and the architecture of that framework and then
write integration tests against whatever a company's product is - whether it
be an internal API, an external-facing API, a single page website, or a
complicated multi-page website. I was just curious if there were additional
responsibilities or techstacks I could be learning that other companies'
"real" SDETs do as well. In my near 6 years of work in this niche, I've only
been at two companies and they let me do my thing, so I'm not really sure if
I'm "missing out" on knowledge or something.

I am also curious as to what you mean by "Quality works better when there's an
advocate from the beginning." In my experience, even when (or if) I am invited
to an agile Sprint Grooming or Planning sessions, I am more there to report on
how a bug works and how severe I think the issue is - no matter how well I
document some bug I found or whether product is there (as they should be
deciding severity). I'm not sure how to meaningfully leverage my QA experience
into helping developers drive their design and architecture to create more
bug-free, quality code. I do notice that once I join a company and find/report
zillions of bugs, their code slowly gets better over time, but isolating an
incident and then measuring my impact is nigh impossible.

Anyway, I know this has nothing to do with the topic, I just wanted to see
what you thought because SDET/QA talk is rare to find on this website.

~~~
poulsbohemian
Not the parent poster, but I would guess that when they say things like
"(real) SDET" they are referring to someone who creates automated tests,
creates scripts for testing, possibly uses white box / gray box approaches,
creates test cases for sub-components and layers.

Compare to someone who only does black box testing and only tests from the
standpoint of manually testing via a user interface.

~~~
geoelectric
It's actually more that an SDET has classically been the one who writes the
tools and infrastructure that QA Automation Engineers would use to write
scripts.

It implies an education/experience background equivalent to any other T&I
Software Engineer, but usually with _additional_ experience in QA.
Alternately, it could be a QA engineer who would be genuinely qualified as a
general SWE in a promotion path, but who chooses to stay in quality as a
domain. But either way it implies equivalent qualifications as a SWE at the
same level.

The "real" bit is because over the last half decade or so, SDET has been
blurred by title inflation. Scripters have been getting the title without any
real experience maintaining longer-term or larger software projects, and who
aren't qualified enough to be hireable as a SWE generalist.

That's one reason you still get "lesser than SWE" status arguments about SDET,
when IME you actually tend to demand a little more in the market because of
the need for experience in two separate disciplines.

My response to the comment above you has a lot more detail expanding on that.

------
29athrowaway
How can you verify that your standups are effective? After the standup, take 2
random members and ask them to describe each other updates.

You will be surprised with the results.

~~~
poulsbohemian
This is at the root of my stink with standups - I've been on many teams where
each individual is working on some part of the system and has essentially no
overlap on a daily or even weekly basis, yet here we are all meeting because
cargo cult development practices says we should. So it's irrelevant to me what
Jane is working on anymore than it is to her what I'm working on. The
naysayers will say that that's the whole point of us meeting, because there
might be some esoteric overlap that will only come to light due to our over-
communication, but for my money there are other ways to solve that without a
lengthy daily meeting.

~~~
29athrowaway
In the restaurant industry, they do similar meetings called pre-shift
meetings, aka lineups. The purpose of those is to check everyone is on time,
check their uniform, talk about current promotions/deals/offers, discuss
potential goals/bonuses, etc. And it makes sense.

In software, standups make it easier for stakeholders to track that people go
to the office, and do so at a reasonable time, although most people will not
admit it because it sounds bad.

Of course, making sure that team members are making progress and they're not
blocked is very important, but that might not be relevant for non-
stakeholders.

Sometimes it's all unintelligible mumbling and serves no purpose other than
cargo cult.

~~~
poulsbohemian
Right - but this gets to my bigger issues with how software development is
done these days (and why I’m exiting as fast as possible after a 20+ year
career...)... in theory we’ve got advanced degrees, are well-compensated, have
to know dozens of technologies from the front end to the database, work twelve
hour days, work weekends and nights on call, build systems that generate
millions of dollars in revenues that keep the company running... but some
project manager thinks they need to take roll call daily because I might not
be responsible for myself? Gimmea break!

------
sumanthvepa
The primary purpose of a standup seems to be a forcing function. It forces
developers to make progress. The embarrassment factor of having to admit you
did not finish your tasks for the day is what drives these meetings. I've been
through the grind on both sides: as a developer and as a manager. I thoroughly
detest stand-ups. When I started my company, I decided not to do them. I have
a one-on-one with each developer everyday to understand progress. I don't ask
for progress reports, since I can see their commit history. This seems to more
effective than wasting their time and mine in a pointless meeting. I still do
stand-ups with sales people though. They seem to like the camaraderie of the
big meeting.

------
fourmyle
I'd honestly take a pay cut for a private office and maybe 1x standups.

~~~
GreenJelloShot
For a private office and minimal meetings, I'd probably never interview for
another job again.

------
adamzapasnik
Standups ain't that bad when they are short and to the point and honest. Being
honest that something may take longer than it was estimated for should be
okay. But people make it a big deal, that if it takes even a few days more,
you are incompetent. So participants chose not to share that details and there
is miscommunication or bugs or both.

Also, an important note. Even if there was a standup, it's ok to talk more in
detail about the tasks/tickets after it, during a day. People seem to forget
it and make the stantups far too long for everyone to hold one's attention
until the end.

------
hnrodey
I'm in a software leadership role.

I'm currently involved in several, what I like to call, "dead standups".
Zombie's could give an update and no one would bat an eyelash.

Stand up can be useful if there is an effective leader. I'm actively trying to
identify these characteristics and implement on the teams for where I am
involved with the goal to cultivate/develop/train people to make these stand
up meetings useful. Because we all know a dead standup is where productivity
goes to die.

I'll have to share my results. Tomorrow, I hope someone asks me for an update
on my progress ; )

~~~
baroomba
If the _teams themselves_ don't want a standup, you're probably gonna get a
"dead standup". The actually-useful-to-the-team part of the standup is
something a team that's been exposed to such will probably self-organize
without some not-on-the-team leader or manager telling them to, _if_ they feel
they need it for their situation/project. I'd say imposed standups are only
useful for teams that aren't already familiar with them (the done-right
version of them, that is) so may need an introduction to understand that it
might be something they want to do, or as a simple micromanaging status
meeting under a trendier name.

~~~
alexbanks
In my experience, if a team doesn't _want_ a standup (or some status update
from their team members), they probably need rotated to something new. No
process, or person, or tool can make a team member care about their project or
peers.

~~~
outworlder
Or maybe as part of their normal interactions they already get all the status
updates they could possibly need? Or maybe these updates are tracked in some
other way (tickets and the like)?

That's not the same as "not caring about their project". I care about my
project, but I don't want to hear 30+ status updates for tasks which are
progressing nominally.

~~~
alexbanks
I do not agree with this sentiment but that's okay. As I said, in my
experience, what you're saying is absolutely untrue, but I'm speaking purely
from my own experience.

------
jbob2000
His Ugly and Bad aren't that bad! I'd be happy if those were my standups.

Right now for me, the project managers own the whole event. You are asked for
an update on a task that is on the project managers list, you give your
update, and then he moves on to the next guy. There is only one developer in
the meeting (me). The rest are QA, BA, Product Management, Delivery
Management, and Change Management staff.

The developers who work under me will get prodded randomly throughout the day
by various other project managers for their updates.

This is what happens when your company is "project oriented".

~~~
brutt
It's called "status meeting". Usually, manager is not present at standup
meeting at all, unless team asked him to participate.

~~~
baroomba
I've seen a lot more status meetings going by the name "standup" than I've
seen actual standups. A good clue is when there are people on _totally
different projects_ in the same "standup". If a lot of the people in the room
are very unlikely to give a shit what most of the other people say for their
part of the standup because they're not even working on the same things,
that's a good sign you're actually in a status meeting. If someone's likely to
get on your ass for being more concerned about surfacing blockers and
communicating usefully with your actual team members than strictly following
"yesterday I... today I will..." format, or folks are often getting "OK, but
where are you at on X?" or "how much longer on Y?" follow-up questions from a
PM or manager, not a direct contributor for whom X or Y is relevant, you're
likely in a status meeting.

~~~
erik_seaberg
IMHO a standup _is_ a status meeting. If I were blocked I would have said so,
not wait until the next meeting.

~~~
baroomba
Sure, in a sense, the difference being whether the form of the reporting is
aimed at helping team-members coordinate or helping a project manager move a
marker on a chart or otherwise send reports upward. Who's it _for_ is the key
concern and makes the difference in what your standups are like, and who
directly benefits from them.

Strongly agree that with certain teams you don't need a regular standup.
That's part of why I think the decision to do a standup should be left to the
team themselves, absent some clear dysfunction bad enough to require outside
intervention. Otherwise you're probably just wasting everyone's time with 15+
minutes of boring crap that could just as well be a 2-minutes-to-write daily
status update message or email to the project manager, assuming they can't get
the status info they need out of Jira or git commits and skip the side-channel
status updates altogether.

I guess another major tell aside from "multiple unrelated teams are in the
same standup" might be whether, if every single non-manager/PM quickly checks
in with the rest and they all conclude a formal standup's not needed that day
(or the entire week, or whatever), a standup either still happens or else
someone (a PM or a manager, probably) gets really bent out of shape if it
doesn't. If so, you're likely dealing with a regular ol' daily status meeting.
And again, that's what a majority of "standups" I've seen have actually been.
They're not for the team, and however they manage to occasionally serve the
team members' needs is accidental—they're just micromanagement and "agile"
box-ticking.

------
himynameisdom
The whole point of a stand up (daily scrum) is to discuss how work is
progressing towards a sprint goal. If it devolves into a card-by-card status
update meeting, it loses its value.

It is nothing more than the dev team coming together to discuss how to move
forward towards the goal. No one else should be at the meeting. If further
detailed discussion is needed, save it for afterwards.

~~~
SpicyLemonZest
How many teams are actually organized in this way, though? I've never been on
a dev team where there was a single, unified sprint goal that all developers
were working towards in an interrelated way.

------
geebee
Good post, nice roundup of some of the ways standups can go wrong and right.

I do think it skipped a common severe corruption of the daily standup, which
is a daily application of micromanagement and deadline pressures.

I’ve heard about successful daily scrum meetings but I now believe the
inherent chemical instability of this practice makes it too dangerous for all
but a few very disciplined teams and only when absolutely necessary.

To me, scrum is the nitroglycerin of management methodologies. People who
think they can handle it safely probably can’t. It’s wildly tempting for
managers or stakeholders who are concerned with deadlines to hijack the
meetings

------
ginko
I generally find that the duration of standups scales O(n^2) with the number
of participants.

------
js8
Remember, it's a called a standup because it's a comedy.

(I genuinely thought the article was gonna be about comedy. I was
disappointed.)

------
goatinaboat
The only workable way to do stand ups is not to stand at all, but make
everyone hold the plank position. The meeting ends when the scrummaster
collapses.

~~~
Kinrany
In a meritocratic organization the strongest programmers are rewarded!

~~~
paulmd
with sick gains and a rocking core!

