> they were never doing stand ups to begin with

that's true, but it just turns the question into the one of "is it possible to do real standups?". My experience is that I've never managed to do real standups. It's just not possible to relay complex information about what you're doing in 1 minute. You either do it so superficially it's worthless or you it in depth and it takes longer than a standup should.

So that’s the thing: a standup isn’t for discussing what you’re doing, it’s to ensure that things are on track (which the default assumption is they are) and a forum for surfacing blockers/impediments to sort out offline.

Assuming you have a Kanban board for your work, and assuming the work is actually accurate on the board in terms of status (which most teams are terrible at without practice) AND assuming you properly have “waiting for testing” “testing” “waiting for review” “reviewing” columns (those waiting for columns are critical to seeing the true state of work), then you simply just “walk the wall” from right to left. As you scan through each column, team members call out if shit is a mess, otherwise you just get a thumbs up and move to the next thing.

Then, just use some analytics to highlight tickets stuck in a status too long, and bubble those up in the standup. “You keep saying this is on track, but it’s been here for a week, what’s the deal?”.

STANDUPS ARE NOT STATUS UPDATES. They’re for resolving blockers in person without letting shit linger too long.

As long as your board is accurate and respected as the source of truth, it is the status update mechanism. It’s no longer a human job.

(And yes, this is actually possibly, my agility team does this with 15+ scrumban teams right now)

> STANDUPS ARE NOT STATUS UPDATES. They’re for resolving blockers in person without letting shit linger too long.

Which means "real" standups are completely useless. Let's say we have it every day at 9:30 and I get stuck at 11:00. Does anyone really expect me to wait almost a whole day to get help, or should I just go talk to someone about it right away like a normal adult would?

So... what type of question or blocker is so unimportant that it can wait for a day to get resolved, but at the same time is so important that we need the whole team to stop working and discuss it?

1. Standups are a place to make people aware of problems, not the only place.

2. You don’t discuss problems at a standup, you make your team aware (if you haven’t already) and organise a separate session with only the interested people.

> You don’t discuss problems at a standup, you make your team aware (if you haven’t already)

Exactly my point. We make the team aware of problems of blockers via Slack (team channel), so there is no point in making the team aware again of such blockers in the standup.

Based on my experience sharing things in-person is much more productive. I think you're looking from a developer perspective and thinking "how can I produce as much functionality without being impeded", which is your point of view. The scrum master is likely thinking "how can we ensure the whole team has an optimal flow" and ensuring such blockers are dealt with as effectively as possible, which is more important.

Granted, most scrum masters have no idea what they're doing which likely leads to individual team members not seeing fulle value in Agile rituals, but it is there.

it absolutely makes no difference to me to have standups, yet still we participate in them...

- To see who's working on what, I just look at the board. - To seek help when I get blocked, I send a message on Slack (or whatever) at the point that I need that help, not only at 9:30 AM - To know who's blocked on what, just tune to Slack

Given the above and if you have the team discipline to make sure that tickets reflect the state of work. Why do we need standups then?

That time can be more targeted towards a meaningful discussion, but the industry seem to be blindly just doing that without giving it much deeper thought. It baffles me.

You might not.

“Individuals and interactions over processes and tools”

Doing standups for the sake of it is adherence to a process over the needs of you’re people.

Equally, a core principal of agile was always:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

And I think it’s always worth considering if your truth is the same for everyone on the team. This is actually something I’d bring up in a review (assuming you have those too right?). If you all agree that notifying and handling problems in Slack is enough, that checking the board is sufficient the just do that? What is stopping you?

I would also look for actually data too back it up. How often are people blocked. How do they get unblocked. How long does that take. Etc. Gives you some insight into the reality of the situation and some ammunition to get things changed if you’re team isn’t really being agile and is just doing the corporate software eng dance.

Thats sounds really quite personal to the individual / team culture and you’re likely right given you’re a part of the team and so one of the best people to know.

If standup’s aren’t solving a clear problem for you, stop doing them.

Have you spoken to your lead / manager about why you do them? How do the rest of your team feel?

I also at least have the impression (correct me if I'm wrong) that standup, and the Agile philosophy that describes them, arose before Slack and similar work-based IM systems were common.

Well, email and IRC existed at the time so I am not certain of that.

Think of the standup-time as the upper-bounds on how long a problem will block someone before everyone knows about it instead of the lower-bound on time-to-cure.

If you always know who can solve every problem for you, then you’re either not doing very interesting things or you’re burning that person out, and Management (including the engineering team leads) needs to know this.

The whole point of a standup is to create a cadence to work. But if you don’t enjoy that invented ritual on at least a certain level, you’re probably not going to benefit from it.

> Let's say we have it every day at 9:30 and I get stuck at 11:00. Does anyone really expect me to wait almost a whole day to get help, or should I just go talk to someone about it right away like a normal adult would?

The standup would be the safety net when people don't see that they're stuck, know what to do and are afraid to ask / hands down in smth they just don't see the obvious.

Uncovering this in a standup should prevent them from "wasting time" even longer.

I have rarely seen this in my experience so far; either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.

> either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.

Exactly. If you're starting to get stuck and you're afraid to ask for help, the last thing you're going to do is making that obvious in front of the whole team and/or your boss. If you didn't believe you can manage it on your own, you'd have asked for help already.

Projects often have many parts. One of them gets blocked and you work on something else for a while. Maybe you shoot off some emails and wait for replies that never come. If you get distracted, you can be in this state for a while.

Often these issues just linger until you finally talk to your manager or team about them. Having a regular opportunity to do that can speed up the process.

> So... what type of question or blocker is so unimportant that it can wait for a day to get resolved, but at the same time is so important that we need the whole team to stop working and discuss it?

A blocker or unforseen problem that you have already overcome but a) have been delayed by and b) might be of interest to the rest of the team to learn from, even if it is just for curiosity.

An example might be "this has been delayed because I discovered the underlying service is a mess and needed a good deal of changing to support the function we thought it already supported. That's now done - grab me after for details if interested - and I am now back to implementing the stuff in the story but it's been a full day of unexpected extra work."

Firstly, it's about scheduling and prioritising. If anything comes up that might be a blocker, or has been blocking you, or will in the future, you mention that as it relates to scheduling, and go solve the block whenever you want. There is zero expectation for you to wait for standup to raise any issue.

As someone new to working on a team with others devs, I’ve always wondered this too.

I hated standups until we eventually got a great PM who moved to something like this, and now I try hard and make standup run like this on any project I'm on. Jira has this nice feature where it puts a little dot on something for each day it's in a column. Standups largely turned into scanning for things that had > 2 dots on a ticket from right to left, and discussing what we needed to do to keep things moving through the system. Love it!

interesting to see this becoming part of the tools.

In 2012, I was on project were we used a physical board, and we would make a black circle for everyday on the board and once we started exceeding the initial estimate (it was done in days as opposed to complexity for some reason) we make that in red, then we started discussing the reds

Except stand ups rarely come across as a way to ensure things are on track, and more as a way to CYA about things being on track, so that someone can place the blame on you about why you didn’t inform the team earlier on the day you realize things are not on track.

> STANDUPS ARE NOT STATUS UPDATES. They’re for resolving blockers in person without letting shit linger too long.

Which make standups useless. If I have blockers I communicate them right away. I don't wait until the next standup to do so.

Unfortunately, many engineers will consider themselves “blocked” after doing only 5 minutes of research and deciding they needed to interrupt someone else’s work for help. They are concerned only with their own productivity, not with the productivity of other team members who have to context switch to solve a different problem.

A standup encourages people to solve their own problems as best as they can, and to aggregate their interruptions to limit the number of individual interruptions throughout the day. Without a system like this, a team’s senior engineers may get nothing done besides assisting others.

I think most people do. But then what? Just let it be for a week and never follow up? Having a daily reminder and time to discuss it is nice.

Isn't a reliable person supposed to tell when an obstacle is met but carry on otherwise? Raise an event when something happened and only when it happened, not polling him/her constantly about it? ; ) Seems like a waste activity when raising issues is limited to a particular time period during the day and supposed to be happening on its own anyway. It is not good for meaningful discussions, it is not enough and not the place for socializing, constraining or repeating something to/at a specific time that should occur otherwise.

> turns the question into the one of "is it possible to do real standups?"

The answer to that is yes. But only if you have someone with the authority to interrupt when it goes off-track. I frequently do that, but it usually takes a very long time to convince the people I work with that someone needs to have this authority(interrupting people is usually considered rude, whereas unrelated rambling is really the rude part by being disrespectful of all the people that are not interested in it).

On paper I thought that that's the role of the scrum master. But in practice I've never seen a scrum master do that. I usually offer this to the project owner, but usually the project owner is the one rambling the most in standups.

Practically speaking what happens is that when people start rambling I interrupt and tell them to take the discussion to the 2-3 other people that need to discuss this with him/her after the meeting.

Yes it is possible if you realize that you aren't supposed to inform everyone present of the whole technical detail of what you did or are facing, and that issues are not resolved in the standup.

The idea is to make the connections needed with the people present, to help with the issue after standup (Bob is having issues with authentication on API x, and Sally says she might know how to help. They will take this up after the meeting).

Status updates should also not go into detail. You might be proud of your very cool efficient implementation for a sorting problem, but get your ego stroked someplace else please (PR's are a good place for that).

Most important of all; empower every team member to shut down this kind of time wasting for the rest of the team, by simply saying that this kind of talk should be taken up after the meeting.

Me and my team and a financial institution do this, and it does not matter who is in the meeting (PO's, executive directors etc).

We do them in 5 to 15 mins. If you're conveying complex information, you fucked up. If you have something you want to talk to someone about, you make a note with them in the standup that you want to discuss it further later, and move on. Standups are to create notes for action, not solve problems.

Even if the standup is short and concise, I still think the meeting negatively impacts a team’s ability to do deep work.

Why? Because no matter when you schedule a daily meeting, it will be in the middle of someones deep work hours, and they will have to context switch for 15 minutes just to tell “No impediments”.

Strongly agree. I arrive first one in the office because I also want to leave early, it takes me a while to get warmed up and productive.

When I'm peaking it's stand up time because it's the earliest time when everybody is available.

The best standups I had were at a previous job, after lunch:

1. A major interruption already happened.

2. Your "mind cache" is fresh and you know what blocks you, compared to remembering what you were doing the day before. People systematically forget stuff during early morning stand up then come interrupt you for questions hours later.

I can't agree with this strongly enough also with the parent comment.

I think it's the constant conflict between the 'maker schedule' and the 'manager schedule'

I firmly believe that I can be way more productive when having no standups and when I control my time rather than satisfy an ill thought about ritual, but more often than not you can't change much about it. When I can, I always do.

daily standups were my favourite thing. i always tried to make them as long as possible by acking innocent questions, since i got literally paid for not working. best idea some moron ever came up with.

Agile, standup, iteration have became buzzwords with very little meaning now. Agile with had deadline for big project delivery (teams working in sprints, PO getting cold water for having major features late by a few days), standups that include breakfast and chit-chat, iteration on major features that take 3 months to deliver.

My ex-LM is now working for major finance processing company. They went trough major agile transformation everyone in the city was talking about how big success it was. He's a tech-lead. He has to estimate feature development in man-hours to the board and investors. Everyone below him (SM, PO, devs, QAs) estimate in story points. He gets shit for features being late by days (eg. sprint finishes on Thursday next week, board meeting is on Tuesday this week).

They cancelled something they were doing completely wrong, because they never reached for quality material how to do it right. Good for them, it was a waste of time to begin with.

I think during a standup you have to - literally stand up. That's the point. It is mindfully uncomfortable/physical work for both speaker and listener, so important communication gets sort of selected in a darwinian way.

Compare that to hourly <n>-people's time is profligately spent and it has advantages for everyone.

If something needs more discussion, then the interested parties - only - can have their own meeting.

Don't worry, a manager's advantage is big enough to make a hour long standing up meeting...

Sincerely, someone who at some point decided to start stand ups early with unofficial goal of "finish before manager gets in"

I can stand for two hours no problem. If the deal is to make it uncomfortable, don't be surprised people dislike it.

This sounds like someone bad at moderation punishing not healthy team members. Our hoping people are not fit enough to stand for long.

This seems wholly non-Darwinian to me, what do you mean would be the evolutionary process here?

I mean subjects. Everybody - speaker and listener alike - gets tired and cranky from standing so long that only the actually important subjects are discussed.

or do it from a plank position

This. Just because your standups are inefficient (and not actually standups) does not mean the process/practice is inherently bad.

In theory yes, but if the majority of the teams are doing standups the wrong way, then perhaps there is something inherently wrong with standups.

I think it's more likely that no amount of good practices and process will work if people don't understand them. The process still improves things compared to doing things ad hoc.

I think the point of this article was not to bash standups but to give an example of empowering your team to make decisions.

Be bold. Make change. Improve the way you work.

Was cancelling standups going to far? Maybe. But that's not the point.

It's pretty hilarious to me that not having standups is even in the same sentence as "going too far".

I don't mean to pick on you with this comment - you are accurately describing the state of the industry.

My first job was at a very large company where every team was required to have a Product Owner, Scrum Master, Business Analyst, QA and then however many devs were on that project.

Our product owner broke her foot one weekend and wanted to sit during Monday's standup meeting. Our scrum master demanded she either stand or leave the meeting. Arguing ensued, loudly.

I bring this up only to say, our industry, while being very progressing in some areas, also happens to be extremely dogmatic about some ridiculous concepts without really understanding them.

Your scrum master is a tool and a liability and if they worked for me this would result in a documented disciplinary action.

Don’t tolerate power-trippers.

Ultimately his contract wasn't renewed because everyone had generally had enough of his schtick.

Wrt that meeting though, several of the devs (including me) got pretty loud and ultimately our PO sat and our Scrum Master pouted.

ooh yeah, the industry is dogmatic about ill thought about so called agile principles. Nobody dare to question them it baffles me.

I've been consulting for over 10 years, how come I've never encountered a useful scrum master if they do exist

Well for one, consultants are rarely brought in to working, well-functioning companies.

Also, scrum (as in the dot-org) doesn’t do a great job of teaching management how to measure the performance of their team so it’s very easy to be bad at anything for a long time and never know it if you’re also bad at management.

I find anything (including scrum) works pretty well if you send your management team out for training too, and don’t let them piss around with soft metrics.

Hm, is this illegal in the US? From a brief search, I think that since the 2008 amendments to the ADA, temporary but severe injuries give you protection under the ADA, and being able to sit during standup seems like an entirely reasonable accomodation.

Sometimes someone can also just be reasonable without it being legally mandated, methinks

Yes, that's obviously the preferred option, but in this particular case it seems like it didn't happen.

The devs were a part of the loud arguing, and eventually the SM just kinda pouted while the PO sat and we all just had a normal standup meeting.

Scrum master could be in a lot of trouble to demand this from a temporary disabled (broken foot) person

that's exactly my reluctance to question Agile processes, because people will think I am pushing it too far.

I remember in 1999 when i had my first programming job while i was in the Uni. It was simple, i had a part of the software to built, i estimated how much time it was going to take and i built it. No stupid time consuming ceremonies.

I guess that the new "gamerization" has been partly caused by millennials and other contemporary generations need for constant recognition.

Everyone is great at pointing out problems. But people are rarely good at coming up with (good) solutions without a level of overall understanding and context.

I think good management takes employee input and uses it to influence decisions while also considering the needs of the entire group of employees and the company.

But either way, I’m not bashing you, just disagreeing :) No harm in trying things and experimenting to find what works for you.

I don't understand why it needs to be formalised like this, what if people are working on something for a bit longer than one day and got no news to tell or talk about? I think each company and product got its own rhythm and meetings should be adjusted to match that, we are human beings, not robots.

Then they say "I worked on X, still working on X, no blockers" and move on.

A well run standup is a minute per person, max. It ensures everyone pulls their head up out of their work long enough to highlight obstacles that might effect delivery, or that someone else on the team might be able to help with, while also ensuring there aren't constant interruptions throughout the day.

That's what we do as well.

I have been in good standups and bad standups, sometimes at the same company.

A bad week-after-week standup was one that dragged on and on, and started at 8AM because that was evening time for our off-shore team which the US team knew was going to be canned in a few weeks. Each person would go on and on, on a bad connection in a thick accent about what they were working on. Between the connection, and accent, and knowledge they were all junior and working on minor tickets and flubbing them and all soon to be getting axed, I did not pay attention when that off-shore team was talking. It was all a waste of time for me.

On the other hand, I have had standups where the scrum master (or product manager in the scrum master's absence) would keep the standups to 15 minutes, and if anyone went on too long or some conversation went on too long he said they should continue what they were saying after the standup, and anyone who needed to hear it could stay. Standups were brief, and sometimes productive if I heard something I needed to know, or was blocked on something and was offered help. And if I or someone else was still just plugging away on something, we would say "I worked on X, still working on X, no blockers" and the meeting moved on.

Insofar as chat, some people get to the standup a minute or two early, and after the hour for the first minute people would still be joining the standup, and people would sometimes chat then.

> A bad week-after-week standup was one that dragged on and on ... our off-shore team which the US team knew was going to be canned in a few weeks...Between the connection, and accent, and knowledge they were all junior and working on minor tickets and flubbing them...

I hope I never have to work the managers who allowed this to go on. Treating this way the people who potentially didn't feel empowered to push back, is an indication of how they would treat others in a similar situation.

This ^^^ we do a 30 minute standup every morning (remotely) and it's mostly the same except we get about three mins per team member. It's also a good time to bring up issues if user stories/acceptance criteria aren't well enough refined after coming out of draft and that gets taken to another, usually short meeting with the PM's individually.

In that 30 mins we also handle bug reports and assign blah blah blah.

Those 30 mins are 100% focused to stuff people are working on, except for an initial 5 mins or so of chit chat. It's massively efficient and massively productive. So whatever the writer of this article was doing, it certainly wasn't a standup. I'm not big on prescriptive process, but a well organised standup is unbeatable.

> we do a 30 minute standup every morning

If you wouldn't feel comfortable standing with a coffee for the duration of the standup then it's too long.

30 minutes is far too long and is well into conventional status-meeting territory. Aim for 10.

Flip the premise of the meeting from "who's working on what" to "who's blocked by what". If there's no problem, say nothing. Not only does that save time, it is also more empowering for those with problems because they're not "swimming against the current" of those who are reporting their successes.

Why attend a meeting just to say that?

Because someone else in the meeting might say "I'm working on X, I'm stuck and I need help" whereby you might say "Hey, I've worked on X before, chat me up after this meeting and I'll try and help out".

^ This.

If everything is going well, it's five minutes spent.

If anything -isn't-, it's five minutes spent highlighting where additional interaction needs to take place.

Even if everything is going well, a status update can be "I'm working on X, no blockers", and someone else can still say "Oh! I've done X! Let me know if you need help", setting the team up for avoiding future obstacles.

Without it, you'll have people hammering at the same problem for days without raising it up because they don't realize anyone else can help them. Or reinventing the wheel because they don't realize someone else has already done it.

Etc. Done right, it's an excellent way to spend 5 minutes. Done wrong, it's a waste of an hour.

E.g. I might be blocked by some bug I am working on, and have no idea that Jim encountered this 2 months ago and has it all worked out. Normally I wouldn't have thought to ask Jim because he's currently working on something else. So this quick meeting is a way to discover that somebody else has already solved the problem I'm working on.

If someone is working on something for a long time, they can explain what part of it they worked on, whether they need help, whether they're blocked, whether they need to adjust expectations, and so on. Long running tasks are a necessary evil, not the default state of the world, as they make planning work difficult.

Giving people time to express that they are being blocked or that they need help with something increases the chances that they will feel empowered to ask for help or to be unblocked. It also aids in accountability and ensuring that people are getting their work done on time and as agreed with stakeholders, as well as giving other team members an opportunity to mitigate any such issue.

On the other end, formalizing that it is short prevents it from turning into an unexpected retro or venting session or long-winded technical discussion better left for some other forum. Everyone should be able to give a quick update before any member of the team loses interest.

There are reasons behind all of these things, and as aware as I am that not everyone agrees with every tenet of every leadership strategy, the "standup" as commonly formalized is actually really solid and I would expect a good reason not to employ it in the way that it typically is.

> If someone is working on something for a long time, they can explain what part of it they worked on, whether they need help, whether they're blocked, whether they need to adjust expectations, and so on.

Additionally, it may highlight that the team underestimated the size of a story or perhaps that the story should have been broken down further.

When I last worked in an org with standups, whenever I intended to go head-down on something substantial I'd simply tell the vp of eng to not expect to hear from me or even see me for at least a few days until I have something substantial worth sharing on the subject.

There was never any resistance there, and I've never encountered friction in that vein anywhere. No cto or vpe above me has ever wanted to get in the way of someone productive getting into a multi-day flow state anywhere I've bothered to work that hard. Peers or underlings however, the competition that is, it's a different story I mostly ignored.

Having said that, I found standups to be a very obnoxious, passive-aggressive tool management used for dealing with folks unable to maintain a relevant and correctly prioritized todo list, and stay on task day-to-day. It's a group I've dabbled in being part of at some employers, and found quite unfulfilling and frustrating because management is way more meddlesome in that mode and individual leverage is practically nonexistent without playing the politics game well. YMMV

> It's a group I've dabbled in being part of at some employers, and found quite unfulfilling and frustrating because management is way more meddlesome in that mode and individual leverage is practically nonexistent without playing the politics game well. YMMV

No kidding. Seeing this failure mode is unfortunate because it's not an immediate killer but it's a lethal one once it sinks its teeth in un-opposed.

The standup is daily opportunity for the team together to coordinate itself and the its work. It is not a status update where the workers have to report to the boss. That is not what you should be doing.

> what if people are working on something for a bit longer than one day and got no news to tell or talk about?

They can just say that they are busy on it. But now the team can coordinate.

Maybe that feature is taking too long, and you should instead spend time on something more important.

Maybe Jerry says "hey, I'm finishing up on issue XYZ. Now I can go help you with that long task."

Maybe you are working on that long task, but hear that another team member has a problem which you know a lot about.

Maybe someone in the team is thinking of starting a new issue which is related to your long task, in which case some coordination may be needed.

Maybe someone thinks your long task is shouldn't be taking that long and they can afterwards help you out. It is easy to get stuff in a bog and not know it.

Scrum is meant to be a team sport where members are helping and supporting each other.

It's good to have a regular reminder to take stock and see whether you're going down the wrong path. Since that often means asking the rest of your team a couple of questions, it's less disruptive if everyone does it at the same time.