Hacker News new | past | comments | ask | show | jobs | submit login
We cancelled standups and let the team build (usehaystack.io)
221 points by thellimist on Sept 24, 2020 | hide | past | favorite | 258 comments



Major caveat: they were never doing stand ups to begin with. From the screenshot, the feedback from the team was “standup are becoming very long, a lot of chatting and designing features” (paraphrased)

It sounds like they had a 45-60 minute daily meeting that was not a standup. Rather than cancel the meeting, shorten the meeting with a 15 minute hard stop.

I run a 10 person remote SaaS company. We have daily morning stand ups. The standup takes no more than 10-15 minutes, but it sometimes goes 20-25 minutes since we often chat for a few minutes before jumping in to standup. (I can’t imagine us doing feature design during that meeting, as they were in the article)

The chatting / socializing is something I encourage before standup starts. As a remote team, it’s necessary to have some group interactions to maintain the group’s working relationship.


> 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.


This article, as with much tech discussion I've seen in the past 5-10 years, seems to take sprints as a given. Are most devs here working in a sprint model? It sounds a bit soul crushing to me to be "continually sprinting".

I'm so glad that our company doesn't have them—I think it's a significant factor in me grinding it out for 9+ years. We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. Otherwise, it gets delayed till the next release, and we don't make a big deal about it—several other features will still be in the release.

I feel like it gives me a lot more agency and ownership of my work. I think it's the right amount of subtle deadline pressure, relying on my intrinsic motivation to get my feature shipped and move onto the next one. Or to have the freedom to determine that it's not ready yet and spend a little more time to avoid shoving out a pile of technical debt.

I'm curious to see what I'm missing, though. Anyone love sprints? Anyone working in a non-sprint model and hate it?


My team doesn't do sprints and honestly thank god. HN is pretty "product eng" focused and sprints do work better there... but for infra projects where the units of work often tend to involve more R&D, exploration, etc. I've found that weekly check-ins work best (scheduling ad-hoc sync when needed). You still get the benefit of a heads-up on what people are working on but you're not trying to shove tasks into arbitrary 2-3 week sprints.

At the end of the day, "agile" wasn't originally the monstrosity that scrum-fetishists have turned it into. It was simply these few lines:

"Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"


"Individuals and interactions over processes and tools"

It is precisely at this beginning point where most "Agile" teams fall flat on their faces. Instead, it is all about process, rather than said individuals/interactions. Scrum rituals are done because, well, everyone else does them, so that's considered "correct". Whether or not there is any value in the process is secondary.


My company's leadership does not acknowledge or care about value delivered locally; it is all about cross-team collaboration. (If you get something done locally in 6 weeks, you wasted your time, while if you involve 4 other orgs so that it takes 30 weeks, everyone involved gets promoted).

It seems local variations in development processes as the #1 blocker to more cross-team collaboration, so it is enthusiastically steamrolling them.


It's also the motivation from management to build process. Rather than agile being a toolbox you pull from because it's helpful, it becomes a suite of metrics that managers and executives can track. Thus everyone must use the full toolbox because their benefit is overruled by management's benefit.


1000% this! The key takeaway of Agile that a lot of people lose sight of, is that you should be doing whatever works for your team, not whatever you did at a previous company or read from a trendy blog post. By all means - try out anything you think will work for your team.

If you're trying to plan out which individual stories your eng team will be working on 6 months from now, or you have a half-dozen "Sprint Retrospectives" with the same complaints every sprint from your team with no changes being made - you've probably made a wrong turn somewhere.


Unfortunately "agile" is one of those lovely sounding ideas that were never going to survive contact with the real world of company politics and management. Perhaps in some places, in some small agencies and startups with strong tech-focused leadership it might yield some successes for a short time, until they start growing and hiring from the bigger companies. Then you end up with the same-old-same-old with more meetings and Jira.


Sprints that don't ship something (i.e. "deliver user value") are just arbitrary timeboxes. They probably can just be progress checkins without all the overhead of Scrum ceremony.


Arbitrary time boxes are what poor managers use to micro manage. I recently saw a team put under leadership of a poor manager and descend into never ending micro management under the guise of "milestones" which were just arbitrary time boxes determined by a tech lead. It also serves to pressure the tech lead "you said it would be done!" which thereby incentivizes the tech leads to pressure their team. It's really dumb, net loss for the company (burnout, higher turnover), and a total waste of time.


Oh man this describes my position to a T as the lead. Manager demands a date which forces me to push my team which they hate. Sigh.


Thanks side another perspective on infra teams. We do Agile and it's such a time waster for us. We spend 5 hours a week on ceremonies that could be condensed to two half hour meetings.


I've always wondered, how did it come to this? isn't having a standup every day a 'process'?


One thing that I didn't realize I loved about sprints until I went to a place without them is the guarantee what for the next two weeks, your priorities are set, and aren't changing unless something very unexpected happens.

Having a two week period with a decided set of work allows you to peacefully do this work isolated from incoming requests - unless they are critical, they will always be delayed to the next sprint. Without sprints, our direction and priority changed daily, with no ability to say "we haven't planned for this, please wait". The result was it was incredibly hard to get anything done, and attention was always scattered.

I am happily back at a place that is doing sprints, and I am sure the problems at my previous organization were far bigger than not having them, but sprints do seem like a great tool to isolate the developer from exterior fluctuations. Granted, a great project manager can probably do the same thing.


I think it’s interesting because the feature of the sprint you appear to like is that it completely removes small a agility.

If you have constant and regular changes in priorities that appears to be an issue with whoever is doing the prioritizing/planning for your team and not a consequence of a specific process.


The agility is still there, its just buffered a bit. This is really useful for concentrating. If you are in a small startup with obvious goals, I don't think you need sprints. If you are in a large organization and are constantly being pulled into different directions between new feature work, production bugs, and tech debt initiatives, having a buffer is pretty useful.

Without sprints, when the next semi-important bug comes down from production, its pretty hard to justify that its more important than the feature you are building, or especially the tech debt cleanup you are doing. Everything tends to be "important" so if there is no culture of picking a set of work and sticking to it, attention is constantly distracted from one thing to the next.

For me at least, programming is all about some momentum - its hard to get rolling but once you are, you can keep going. Sprints give me the room to have bouts of momentum, stopping every two weeks to adjust direction, and then starting up again. Without them, it feels more like pacman - darting and reacting rather than holding a steady direction.


> I think it’s interesting because the feature of the sprint you appear to like is that it completely removes small a agility.

Ideally, at the end of a sprint you'll have a concrete deliverable. Because this deliverable is concrete and not ongoing, the team should (theoretically) be able to switch entirely to a different project (or priority) afterward when business circumstances demand it.

That's where the "agility" comes in. If, on the other hand, the work is being produced as a continuous flow--without hard cut-offs--then there's no set point where the team can switch priorities without leaving behind a half-finished state.

Obviously, YMMV on how this all shakes out in practice.


Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint."

I do think it's useful to have some cadence for important meetings, but the arbitrary timeframe should not be treated as a goal or even something worth dignifying in and of itself. It's simply a tool, nothing more and nothing less, and we should expressly state its purpose and discard it in situations where it ceases to be useful.

I actually do like the default Agile meetings, but I think they're usually implemented haphazardly. I would prefer standups at the end of the day so that they run no risk of destroying the context of a programming task or block me from starting my work day. I like IPM/sprint planning to refine stories and make sure they're ready to work. I like having a "definition of done" to create a shared agreement of what my commitments are and whether I've met them. I like retro to evaluate how we're doing as a team and to improve processes and working culture. I like technical retros to share learning and troubleshoot architectural problems and identify useful areas of research.

All of these things are great when done well and for the right reason. All of them can be sources of misery when they are done ineptly or as mere formalities, with no underlying sense of purpose.


Do standups just before lunch. People tend to work on different schedules, start/finish early, start/finish late, but most tend to have their "middle of the day meal" at around the same time. So instead of 9 or 10am, or 4 or 5pm, do it at the "natural" break time, eg 12:00-12:15.

Two advantages, people that have got "into" the work flow in the morning need to break anyway, people that use the morning for "admin" and then afternoon for work can finish their housekeeping with the standup.

Same applies at the next order of magnitude, start/finish sprints in the middle of the week, not the beginning or end. No one wants to sit in a review on a Friday afternoon.

Retrospectives make sense at the end of the working week. Planning makes sense at the beginning.


Instead of "sprints" I say "slogs". That keeps the team motivated.


> Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint."

As a both a runner and a developer, I find this quite funny and a bit wrong. The fact that we call them sprints can be a bit wrong or confusing if you put them in a different context, but what I can say is that almost every serious runner will constantly check their laps, be it miles, be it km, you will always look at your watch to see how you performed in your last km and if you are on track.

That's what I see useful in sprints, the fact that you stop for a bit and see where you are, you have the time to discuss things that might have gone wrong and try to fix them before it gets out of hand. But in the end I can understand people who dislike the system, because I've worked with a lot of managers with no technical knowledge trying to manage technical projects.


And that’s why metaphors suck.

Unlike in a run, where I know the exact moment and location I have reached my halfway point, in a real software project I don’t even know what the actual distance to be covered will be.

What sprints force you to do is basically make sure you’re running full tilt for every 400m distance, which is fine if the eventual distance ends up being 800m for example, but if it ends up being 26 miles instead, you’re just gonna burn out well before.


> We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. Otherwise, it gets delayed till the next release, and we don't make a big deal about it—several other features will still be in the release.

Um, yeah, that's a sprint. That's exactly how it's supposed to work. Like you say, it's a good way to work. What do you think a sprint is?

I've worked in non-sprint models - i.e. no regular time-based cadence - and found them harder. It's very easy for a feature to scope creep if you've not got any regular schedule, and it's harder to feel a sense of achievement if you're not releasing regularly.


Everything I've read to this point seemed to describe sprints as chunking every task so that it takes no more than 1–2 weeks to complete (depending on the company's sprint length). I inferred that a dev would be expected to pick up and complete one of those task chunks each sprint. I have seen occasional references to tasks that last 2 sprints.

I was contrasting with that model, though it sounds like I might not be accurately characterizing sprints. We've had some features that have taken over a year to complete, such as a major rearchitecture. The (generally senior) dev assigned to that task has a lot of latitude to break it up according to their judgement, submit individual parts on their own timeline, etc., all while minimizing bookkeeping and coordination with others. As long as they're continuing to make forward progress according to an initially vague, sensible, iterative plan, we tend to leave our established devs to their own devices. For newer devs and where multiple devs are collaborating on a feature together, we encourage at least weekly check-ins.


Ah, sorry, so you're saying it would be normal for a dev to take several of these 4-week periods between delivering anything? You're right, that's not scrum; not delivering anything in a given sprint shouldn't be a big deal (just re-estimate the remainder), but yeah, consistently having sprints where you don't deliver anything would be a cause for concern, and would suggest you're not breaking down your tasks enough.

I definitely wouldn't want to work in a model where you're expected to just take as long as it takes. Integrating a branch that's been going for 6 months is a nightmare; even when it goes well it's immensely stressful. Reintegrating your work back into the rest of the system can easily feel like it's taking "the other 90% of the time" - or even be impossible, if someone else has changed the system in an incompatible way in the meantime. Even if you were regularly merging code changes to master, if you try to release 6 months of work when none of it's ever been deployed to production yet then there's always the sinking feeling that maybe it's all just going to break. Or worst of all, maybe it works perfectly the way you thought it was meant to, but you misunderstood the spec and so all your work is useless.

I'm a bit confused by you talking about an "iterative" plan, because I don't see how you can meaningfully iterate if you're not delivering changes regularly - indeed "iteration" often gets used to mean the same thing as "sprint".


We generally don't have 6-month old branches. We don't shy away from assigning big projects to devs, though. They iteratively collaborate with our Product team to carve out a v1, and then get to work. We throw out reliability on delivery dates of any one feature, believing that we achieve higher throughput with less coordination (we avoid dependencies between features as much as possible).

The assigned dev absolutely breaks the big feature into reasonably atomic pull requests, ideally no more than a few hundred lines but sometimes a few thousand. The critical difference, I think, is that none of that breaking up is super planned out, and it's certainly not formalized prior to development. The changes often trickle out over several releases. Collaborators may help advise on where to break things up, but ultimately it's up to the dev to use good judgement.

I agree that 6 months of unmerged development is absolutely a horrible situation that's best to avoid.


> We generally don't have 6-month old branches. We don't shy away from assigning big projects to devs, though. They iteratively collaborate with our Product team to carve out a v1, and then get to work. We throw out reliability on delivery dates of any one feature, believing that we achieve higher throughput with less coordination (we avoid dependencies between features as much as possible).

If your product priorities are stable for 6 months at a time, you're in a rare position. And I'd worry about knowledge sharing and maintainability if whole functional areas were being implemented by one person on their own. I agree with avoiding having two people working on the same area in parallel if at all possible, and there's certainly an overhead to not having the same person do a series of related tasks, but if we're planning to share maintenance responsibility for that area of the code (which is what being on the same team means) then I think spreading out the development work is worth the overhead. And fundamentally if no-one else on the team can understand Bob's architecture then better to find that out sooner rather than later.

> The critical difference, I think, is that none of that breaking up is super planned out, and it's certainly not formalized prior to development. The changes often trickle out over several releases. Collaborators may help advise on where to break things up, but ultimately it's up to the dev to use good judgement.

Scrum doesn't favour large amounts of up-front planning - ideally you don't plan beyond the end of the sprint - but you define the user-facing change you're trying to make, at least in enough detail to a) tell whether it's actually done or not b) estimate enough to let you prioritize. Even if your priorities are stable enough that you don't need to do the latter, I think I'd always want to define what I'm aiming for in each release ahead of time - otherwise it's just too easy to scope creep and end up with those 6 months of unmerged changes. And if that goal isn't something user-facing then you're kidding yourself, IME - it's just too easy to overengineer or overarchitect and produce a bunch of churn that doesn't actually achieve anything, unless you're constantly keeping in mind what this change is actually supposed to achieve.


I think you might be assuming "sprint" to be some always-the-same-thing that it doesn't have to be.

On one recent team, we did 2 week sprints with a couple releases per week (basically, one per feature that finishes and makes it through QA).

The 2 week cycle was our planning/work prep cadence. If a feature isn't fleshed out by its owners and stakeholders prior to the start of the sprint, we're not going to ask any devs to pick it up during that sprint. If it is ready, we'll start to plan it, and estimate how long it will take, talk about debt-vs-speed tradeoffs, etc.

I think I might dislike the model you describe because it seems potentially isolated around "my feature" vs "the rest of the team's feature," and because I think making the planning cycle 4 weeks instead of two might cause more planning pain for each release.


That's interesting, thanks. So a dev can be working on a feature over an open ended number of sprints? What is the significance of the sprint, then?

We don't have "planning cycles" except for quarterly prioritization to realign on which features matter the most (exceptional features occasionally get prioritized outside the process). When you finish one project, you pick another that's interesting to you that's near the top of the priority list, with support from our Product team and Engineering Operations.


The goal of the sprint is -planning-. It has no effect on the devs doing work.

If we estimate what can get done for a given time period, we can evaluate whether we're correct. Do it a few times, we get really good in estimating. We can try and estimate the future. As soon as new things come in that we didn't plan for, we know immediately that we're going to slip, and may even be able to figure out by how much, or what we have to drop to still hit the date (or if we need to evaluate if more people would be helpful; PM triangle here). Likewise if we learn our estimates are wrong, we can start predicting we're going to miss the mark, literally as early as humanly possible.

Doing it this way is in response to longer term milestones; if you only estimate/evaluate once before delivery (if even that; oftentimes milestones are just "on time" or "behind", there isn't any acceptance that a date and set of features won't be hit, and it turns into a death march), you only get one chance to evaluate and respond. Likewise with two, three, etc milestones. Sprints just try to break the work up to do it more often, to try and recognize you're behind, sooner, and so can respond. They don't have to be two weeks; it's a tradeoff, the more measurements the faster you'll recognize you're off, but the more work it is just to measure.

If you don't have deadlines that the rest of the org has to organize around, or to communicate to a customer, just a very clear set of priorities, and you just pull from the top from, you don't benefit from Scrum. Which is perfectly okay. Just, oftentimes businesses -do- need things by a given date, or need to respond in some way. Sprints just help give you evaluations to determine that you're on track. Or not.


>So a dev can be working on a feature over an open ended number of sprints

Sure. Ideally it would be broken up into tickets that fit inside individual sprints, but sometimes particularly hard problems are just going to roll over. That's fine and nobody should feel bad about it.

I hated agile the first time I met it because the team had no autonomy and a bad culture. When you actually have the ability to treat your process like a tool, none of this is a silver bullet, but it's a fine tool.


Yes, absolutely. It's supposed to be a happy medium between everything being planned out months in advance with no flexibility on one hand, and constantly changing priorities such that developer workloads change beneath their feet before they get a chance to make significant headway. Your model sounds like it could be reasonably described as 4-week sprints.


I really don't think so. We have processes that happen on a 4-week cadence, and about 10% of the engineering team rotates through duties in shepherding those processes. For all other devs, the experience is to pick up a feature, work on it for as long as it takes with periodic technical check-ins, complete the code review, and then pick up their next feature, completely independently of our 4-week release cycle. Is that still sprints?


I would say a key difference is the "completely independently". "agile" models tend to make the independent unit a small team (say 2-5 developers, along with designers, QA people and product people). And within that team it's generally considered best practice for everyone to eat least be keeping an eye on what the others are working on and be familiar enough with it that they could pick it up if need be.


> What is the significance of the sprint, then?

Among other things, releasing something on a consistent schedule. I hope you (and the rest of HN) will forgive me for making this little meme: https://i.imgflip.com/4g6z3o.jpg


Sprints are training wheels for agile. Kanban is simpler and more productive. But only if your team has the maturity and discipline to work efficiently without deadlines.


My teams did Kanban, but we definitely had deadlines. It was wonderful to see continuous flows of work and individual developers empowered to work independently.


I've worked in these Agile teams for my entire career so far. I have begun to believe that standups, in the way that most companies conduct them, are against the interest of most developers. It feels like I need to justify my position every day, and that I am only as good as my last feature. Sprints are basically scientifically optimised crunch. It is like the last stretch of a project every 2 weeks. Just put in the extra energy "for the sake of the sprint". Pull all-nighters, just so that you can be told in your planning meeting that we are "agile", and the requirements are changing again.

Disclaimer: These are subjective opinions, and I recognise that some developers thrive in this environment. Also, this is a comment on Agile in the wild, rather than in principle.


> We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release.

That's what a sprint is.


We make basically no attempts to estimate how long a feature is going to take and then update those estimates along the way. An individual feature could take a few days to implement or several months (years even). Periodic check-ins are completely independent of the 4-week release cycle.

Every 4 weeks, we release whatever has been merged in the last 4 weeks. One dev might have 8 independent changes in a release or 0. We typically have a handful of significant changes that land each release and a bunch of minor improvements. Still, there's not much effort to estimate when any particular feature might land.

When a large feature is getting close to completion, the dev might choose to push a little bit to hit a particular release. There's not really any external pressure to do that, though.

That's still a sprint?


Yes. A key idea of Agile (maybe Scrum specifically) thinking is that you release and retrospect/rethink often, instead of long-term working on unlaunched projects from an ancient plan. I guess if you skip the rethink part than you aren't doing sprints property.

An insight of Agile is that your have to pick either a feature based release schedule or a time based release schedule, not both, which is impossible and that time-based is better.


We don't either and I do not get the fuss. It is just a very formal and robotic performance that cannot possibly address all the needs, cannot be the centerpiece of an organization, as it is pretended so many times nowadays. Including the so called sprints. The work we do differ in size and complexity and schedule and workforce requirement therefore our interactions adapt to the situation.

And not the work adapt to a mechanistic interaction style.

When we need frequent feedback we do frequent feedback. When we need deep group planing we do group planing periods. When we need intensive coding we do intensive coding with occasional follow ups. We track progress, we monitor workforce. When someone hit the wall that person cries for help and we do something about it - depends on the trouble what and how. In one position we used it but was sooo mechanistic and insufficient to address the varying needs that it died off quickly.

I believe it cold be great for certain situations. Simple repetitive ones? But otherwise looks like yet another holy grail management method people hype for a while and might join the club of all other holy grail management techniques being praised to the heavens in their time throughout the history so the world was adjusted to those not the other way around. Then found yet another holy grail out of disappointment.

Not to mention that seemingly no one knows what it is exactly and how it should be used, some do this was, some do that way. And so we are back to the adaptive management now. : )

It must be good for a certain set of situations but it is odd that this is a crucial bit in interviews if someone have experience in it or not, like if it was impossible to adapt to the management style of the task at hand and it would require special skills or capabilities requiring preexisting abilities or formal training....


The term “sprint” along with most of Agile nonsense is inane and misleading. I was skeptical of the entire process until recently when I’ve seen some benefits thinking about and practicing it as “method to efficiently parallelize and delegate tasks.” Good planning saves me and the team some cognitive load in determining “what’s next” constantly. And daily stand ups are still mostly useless but a good touch point when doing remote WFH.


I'm not doing sprints now, but we have stand-ups. I think the stand-up itself is a great way to keep people on track. Plus it gives management a much better idea of when to expect things to be delivered.

I don't have a great opinion of sprints for a couple of reasons. I used to have a job that did sprints. Development was often rushed to fit the sprints which led to a high rate of defects. And now I'm working with a vendor that does development in sprints. When we ask them for changes, it adds a large amount of lag to actually getting them because we have to wait up to 2 weeks for them to reprioritize, and then at least 2 weeks for release.


Why are standups even a thing?

Like, what is wrong with my reasoning here? Meetings are maximally efficient when the exact set of people who all need to talk to each other are present, and no more. In a team of 7, only 1 or 2 other people might be affected by what I’m working on. The other people are just wasting time pretending to care about what I’m saying.

My experience working at tech companies in SF has suggested to me that most meetings, not just standups, suffer from this problem. The time cost of a meeting grows as O(N^2), and yet we routinely have all-hands, weekly syncs, etc. Yes, some level of communication is needed but when the time cost of these things is so tremendous, it seems irresponsible not to at least ask if what we’re getting out of it is worth the cost.

Meetings are apparently the one thing that no one tries to optimize, in our industry ostensibly hyperconcerned with optimizing things.

Disclaimer: I hate most meetings.


I've come to realize that stand-ups are generally useful. You're right that out of, say 15 people, only 2 care that you are struggling to import some dependency, but the rest overhear the discussion, they register some keywords and they know what you are working on. Maybe next month Joe Junior Dev goes directly to you with a question about that dependency instead of wasting half a day googling.

Then there is also the side effect of our monkey brains to give importance to people you see often. Stand-ups cultivate the feeling of "this is a team". It's important to show members what the team is.

Stand-ups however are not a requirement for a good functioning team. I'm leading a small team of senior devs and, despite my praise above, I decided against daily stand-ups. There is sufficient intelligence and communication, and just general professionalism in everyone in the team, that daily stand-ups are not worth the hassle and corporate feeling.

As a rule of thumb, if there are junior devs on the team, I would insist on having daily stand-ups on that team.


When the company I work at decided to become "agile", it all went to hell. Every "innovation" just makes it more and more miserable to work there. Standups are a real pain, and I have yet to see any value whatsoever from this daily ritual that interrupts key work time.


Because some people are luddites and cargo-culters and don't see the reasoning behind the actions

"Agile mandates post-it notes" kinda stuff

Standups could be very well replaced by a chat channel, for example. This way it's broadcast, recorded and can be a bit async as no-one needs their turn to speak


I find having context for what others are working is helpful. Not only does it mean I can help them better when necessary, I can be aware of what other people are doing in the project and head off any potential problems.


Where I work, most people in management positions work 50-60 hours a week because most of that time is spent on meetings and they have to work overtime to finish their "real" work.

I used to enjoy meetings when I first started there because it felt good to have a break from staring at a screen all day but I quickly got tired of being invited to 90 minutes long meetings on project X where my input was only needed for one point out of the 12 on the meeting agenda.


We have a weekly status meeting. Mostly it's about giving the boss an overview over workload and discuss prioritization of upcoming stuff, and that's usually the only time he'll actually manage me as such.

However it's also nice to discover if work done by other devs interact with what I might be working on. Maybe I'm working on changing some logic in a module, and some other dev is about to make an integration for a customer which will involve that module indirectly.

He might not be aware of this indirect dependency, so I can give him a heads-up and now we know we must keep in touch over this work.

It's also good in case someone else has any good ideas for solving an issue. Maybe someone knows of a tool or a service which can do the job. Maybe someone has experience on that sort of stuff, so the dev doing the work knows who to ask for advice.

This is the only regular internal meeting I have though. There might be a case-specific one or similar once or twice a month, the rest is just ad-hoc with 1-2 others as needed via Teams or dropping by the office (pre-pandemic).


Originally, it was supposed to be to minimize meetings and make them more efficient when they do happen.


They stopped regular work and had a hack week and morale improved. Now they're back to the regular work and having standups again. What does this show other than taking a break is fun?


Yeah, the "we stopped having standups!" is good click-bait, but simply letting people work on their own projects is always going to improve morale and productivity (if you assume the fun projects are aligned with the organization).


I thought the productivity data was interesting but then it stopped right after hack week... Definitely agree, the long term implications are a lot more interesting.


"our standups are growing and spend alot of time chatting / designing new features". So your standups are inefficient and your solution is to cancel them? Talk about a false equivalency. Fix your standups, dont cancel them.


It sounds more like they asked the devs what would make them productive. You know... empowered the team. Isn't that what agile is about?


I much prefer stand-downs (I’m claiming the name now).

At the end of the day, you tell your team what you accomplished for the day in an email. Everyone already knows what they’re working on next because that’s part of the ticketing and schedule system your company uses, and decided at the beginning of the release period. If you’re blocked you go tell the person whose blocking you, or your manager.

When everyone wakes up and goes to work they can just get to work.


This. I really like this about Kanban. All of the work was already on the board. The to-do column was kept populated with tasks to be done, and there's complete visibility of what's in progress. As the lead I could look at the aging of each ticket and speak directly to the assignee about any issues. If we needed an ad-hoc meeting to deal with blockers we could do so, and invite the people needed. We'd have at least weekly meetings with the entire team and as many ad-hoc meetings as necessary, but no more.


I like that better. It’s a pain in the ass waking up and not knowing what’s really gonna happen for the day until your standup meeting.


What if one day your head is in a different space? You have to call out sick until you are ready for one specific task?


If one day your head is in a different space and you don’t feel like working, you suck it up and work anyway because you’re a professional.

If you didn’t accomplish anything for the day, you put that in your end of day email/report and explain why, and what you need to do to ensure it doesn’t happen again.

If you’re actually sick or need a day off you notify your superior. They will work with the team to pause or reassign your work while you’re gone, and when you get back you resume your work.


I've found standups to be probably the biggest waste of time of all Agile ceremonies (and I'm really not a fan of Agile as-is, but I'm too young to have experienced anything else so I can't say it's definitively bad).

I think the one caveat, though, is that standup is useless IF the team is high-performing, close with one another, and self-motivated. The team I'm currently on probably does not need any sort of formal Agile workflow at all besides setting our current sprint's worth of stories at the beginning of each sprint. But, that's because everyone on the team is very self-motivated and even remotely we're still very close with one another.

I've been on other teams where, without standup, people would go for days without working on or talking to anyone.

I think, if anything, this is proof that no company should have one method of delivering software. I work at a massive company, and forcing each team into Agile is probably easy at a top-down level, but can be very frustrating at a bottom-up level.


Standups are Scrum (possibly XP), not Agile, but Agile is dead and Scrum is wearing its skin as a macabre disguise. It puts the lotion on its skin...

Standups are the first time I ever noticed that "X is ableist" without someone else having to point it out to me. My introduction to standup meetings was a bit after I screwed up my ankle. I spent a lot of time thinking in that meeting about all the injuries and disabilities that would make the forced standing still for 15 (or let's be honest, 30) minutes an imposition. Spines, knees, hips, ankles, toes. In our industry you have to be able to manage sitting at a keyboard for 8 hours, until 'Agile' came along.

Writing this out, I'm beginning to wonder if standups (the "Stand Up" part) aren't in fact illegal under US and/or EU law.


> My introduction to standup meetings was a bit after I screwed up my ankle. I spent a lot of time thinking in that meeting about all the injuries and disabilities that would make the forced standing still for 15 (or let's be honest, 30) minutes an imposition

We have "standups" without physically standing up. I've worked places where actually standing was the norm, but they definitely wouldn't have made someone stand if they had a medical reason not to (use some common sense!)

The basic premise of a quick meeting to make sure everyone is aligned, and that any blockers are communicated seems sound to me.


I sit down if people keep me too long. If they ask me to stand up I'll just say my feet hurt.


Yeah a peeve of mine as well, I've always thought the name is insensitive at best.

However, I would have thought it's taken as given that you only stand if you are able and the real goal is to keep the meetings short and focused; with physical "discomfort" being an inspired motivator.


Standups tend to be held on purpose in places where it's socially awkward or physically difficult to bring a chair. If you can't stand for 15 minutes then carrying a chair is probably right out.

I know some feminists, I know some people with 'invisible illnesses', and I know some people who are both. There's an interesting degree of overlap in concerns and complaints for the two groups, and the intersectionality makes for some interesting commentary.

If hosting a meeting in a location where the women's restroom is on another floor veers into discrimination, if starting every meeting with, "Gentlemen... and Susan" is bad, then surely holding a daily meeting at a location without chairs creates the same type of concerns. Especially now that we include microaggression as hostile behavior.


Yes I agree - that's pretty much my concern with the concept; although I've only really experienced stand-ups in normal offices in accessible environments, your description highlights the potential for it to be even more exclusionary.


Happily my current team contains remote workers, so even before covid, 'standup' consisted of at least two rooms of people staring at a screen or conference room phone. I haven't had to stand for five or six years.

Also the flip side of the "some people can't do thirty minutes" is "some people could do six hours". Trying to use gravity as a timer does not work on endurance athletes at all. And they often have partial immunity to long, drawn-out activities. An alternative mechanism to control for time would be less problematic all around.


I've come to believe that the real motivation is avoiding the need for a meeting room.


You are not wrong.

It’s hard not to look at the inadequate meeting space in most office plans and not take it as a giant hint that they just want you to “shut up and code”. I think we often get confused between the Right thing and the expedient/practical thing. There’s certainly a lemonade from lemons aspect to stand ups.

I would conjecture that there’s an Icarus aspect to Scrum. The other agile methodologies tried to massage the limits and strengths of typical programmers, managers and customers, to save our sanity and throw management enough bones to let us be weird, but not too weird. Scrum looks a lot more like Business as Usual, and so the MBAs embraced it and made it their own.


The lack of meeting rooms is because they want to save money on real estate and rationalize it as meetings are supposed to happen in the bullpen where everyone can hear and contribute. If they wanted people to shut up and code they'd have personal offices or cubicles


> I'm too young to have experienced anything else so I can't say it's definitively bad).

I'm not too young. Agile is definitely bad. It's a cancer on software development.


Standups in low performing teams degenerate into managerial oversight and "reporting". That's both demoralizing, and forces people who hate it out of the company. Standups in high performing teams are usually less useful because it doesn't really matter what process you use. Your best bet is one that lets them collectively agree on what to do, and then get out of their way.


A bit click baity.

The team experimented with cancelling stand-up AND started doing a version of 20% time with a strict rule about "fun projects only".

As with any process experimentation, mixing two initiatives at the same time makes it impossible to understand the results.


And only for a week! What does that prove?


Exactly! I can enjoy a vacation somewhere for a week, but living there might be a whole different thing.


Doesn't prove anything, the whole article is useless. If they did this over at least a few weeks, then maybe.


Anybody else a infrastructure engineer and do Agile?

We do and I just don't think it fits for our work. Maybe it's good for development but our work rarely fits within in a sprint (which is a week for us which I think makes it worse).

And I cannot stand stand ups. They feel like a waste of time. I'd much rather do two meetings a week to catch up on things and look at our tracker in between.


We do a "ScrumBan" style. Basically we do backlog grooming, sprint planning with 2 week sprints. We factor in that the oncall engineer will likely have less velocity that sprint and we're ok with carry over of some tickets (try to minimize this as much as possible).

If you're having issues with your work fitting into a sprint, have you dug into why? Are you breaking down the task into small enough units that make them more digestable in a sprints worth of time?

We also punted on standups, I never found them to be valuable and past experiences felt like they were more of a mechanism to get people into the office at a certain time. We do a once a week team meeting with an agenda that you can add to before hand. We discuss anything that needs to be discussed as a team and unblock anyone then. I trust everyone is doing work daily and I can check our sprint board without having everyone tell me what they worked on daily.


I think a ScrumBan style would work much better, with 2 week sprints.

Yes - things just take awhile to get done. We split things up as much as possible.

If we didn't have daily stand ups I think that would be helpful.

BTW I am the Lead who acts as both the product owner and scrum master.


Cancelling standups during a "fun projects only" hackweek doesn't say a single thing about the efficacy of the standup meeting. The costs of cancelling it, will only show up over the medium to long term.

Also, it makes me cringe a bit to see there are people who think number of pull requests are a good measure of productivity. It incentivizes blasting out a lot of quick, easy changes at the expense of doing more challenging tasks that may be essential for long term code health.


With JavaScript turned off, the link goes to an empty page. There's some template stuff, but no content.

Which could be taken as a rather funny take on "here's what happened" ;)


I know that the whole "it doesn't work without javascript" story sounds like "get off my lawn", but content authors, esp on HN, need to realise that quite a few of us refuse to browse the Web with JS enabled esp on mobile devices.

With JS the experience on the mobile web is garbage. It's difficult enough to find quality content as it is, we don't need all the added "benefits" of JS.


> but content authors, esp on HN, need to realise that quite a few of us refuse to browse the Web with JS enabled esp on mobile devices.

They kind of don't though, given this is such a tiny fraction of visitors


I realize it, I just don't care.


Is there any quality content that is hidden behind JS? From the comments here, OP isn't.


https://news.ycombinator.com/newsguidelines.html

Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful.


I mean, it's time to accept that JS is everywhere. Or, you can do something like Stallman, and have a remote machine send screenshots to you, so you don't have to run non-free JS.


On the teams I've been on that are actively doing software development (not in some pre-coding phase where we're still figuring out requirements or something like that), if there wasn't a stand-up individuals created an identical coordination mechanism in an ad hoc manner. This tells me that there is something valuable to stand-ups, even if we don't always love them. If a team's stand-ups are not effective, there are lots of things you can try: refocusing the team's attention, have someone other than the normal "stand-up leader" guide the conversation, or change the time so that it's next to another interruption (for example, right before most people get lunch... this has the added bonus of incentivizing people not to ramble).


There is an important piece of information they didn't take into account. They cancelled stand-up right before the Covid lockdown.

What they are tracking is not the effect of no stand-up, but the pattern of their workers during the lockdown. The April drop in pull requests can be explained by workers feeling overwhelmed after staying home for a month.


Daily stands ups are the quickest way to waste your time.Even if can limit the stand up to 5 to 10 minutes, a study from the University of California Irvine revealed that it takes an average of 23 minutes and 15 seconds to get back to the task at hand. That means you lose half an hour of work from each of your team members each day, 20 hours a month.

I trust my team to keep me updated if a ticket takes longer than expected. If it does, I can arrange a meeting with the required developers to discuss a way forward.


Well this is kind of a silly metric to validate the efficacy of standups. What you want to look at instead is given 2 teams, one with standups and one without, which one achieves their goals more often and has higher morale.


Stand-ups are pretty dumb. Yes, the idea is that they exist to surface and resolve impediments, but there are problems with that:

(1) impediments shouldn't fester for a significant fraction of a day, and usually don't require synchronous team-wide communication.

(2) stand-ups inevitably, even if timeboxed effectively, become either rambling or ritualized status meetings, because people very quickly learn how to resolve, or at least surface and start working to resolve, impediments without waiting for them.


> impediments shouldn't fester for a significant fraction of a day, and usually don't require synchronous team-wide communication.

It's very hard to make the call about when it's worth interrupting another team member. You're potentially setting back their work a significant amount, and it tends to feel like an admission of failure. Having a regular scheduled time to do it takes a lot of the sting out of it.


> It's very hard to make the call about when it's worth interrupting another team member.

If an issue can wait for a daily standup, it can even moreso be communicated and any necessary synchronization planned through asynchronous communication which doesn't require interruption at all.


If your organisation has a good async communication culture, yes. Many don't.


I would gladly pay the cost of standup in exchange for a team culture that is reluctant about interruptions.

Most people get both standup and constant interruption.


Yeah, that's why I built my startup. Status is not a discrete event like standups pretend, but you also need a tool set that lets you raise issues without breaking people's flow. The proper way for this to work is to have your workflow system enforce some structure on severity and types of communication, and just notify you in priority order when you're ready to handle stuff. Shameless plug: my startup is Uclusion (https://www.uclusion.com)


I don't know where you've been working, but that hasn't been my experience. Shrug.


Wow, I'm kinda impressed of all the negative comments here.

What's making a short and focussed daily synchronization meeting (aka: Daily/Standup) useful for me:

* Short and focussed, 15min max, no excuse

* Focus on impediments and try to figure out if the team can help.

* VERY short update on what I'm planning to do today (to make synergies visible)

* And the least important one I'd skip quite often: Short update on what was done yesterday. (Looks like, lot of ppl are focussing on this one)


It obviates the need for many more 'project planning' meetings and forces everyone to be present and answer questions. If done right they are excellent. Easily ruined by those with no discipline.


Classic army of apologists with 'you are doing it wrong'. Yes we get your intricate textbook philosophies but the average Joe, works at AverageCo and has an average Schmoe manager that takes your buzzwords, weaponizes it and turns our life into hell. So don't be surprised when people are angry with you. You invented the deadly rituals that an entire industry now suffers from.


The calendar picture is interesting. One of the problems I have with standups or any meeting first thing in the day is how it affects my mental state. That period directly after I start work is precious. It's when all the things I've had in my mind overnight are ready to be realised, and I'm calm and my mind is receptive to sitting down to a focused session.

Splurging a meeting into that period can completely destroy that precious time. I can have a whole morning of work just disappear because I can't focus properly after an interruption like that.

Another way of looking at it is that people understimate the cost overhead of having a meeting. For me, you can pad the time around it with about an hour before and after and assume my productivity will be severely impacted. In that context, a 15 minute standup is about the stupidest thing you can do for my productivity. If you're going to have a meeting, make it real and decent and worth the overhead of holding it.


The worst is the end of the day checkins. By that point I'm not sure what I worked on or sometimes where I even am.


During most of the time at <current company> I've had a standup in the morning, one in the afternoon, and I have to put my daily summary in a chat room so that more people (architects, CTO) know what I'm doing. I'm a developer.

In the past when I was a manager I hated making my team do standups. In fact, one reason I quit was that I got a new boss who was an agile evangelist and I had to implement things his way. I didn't like how it made us less efficient and eventually quit.

One thing I did as a manager was for pre-sprint planning each developer would meet with the product manager for 10mins, one on one, which the team loved by the way. Instead of giant 1-2 hour grooming session.

I think I was an effective manager, but no company wanted to hire me because nobody works like that, so I went back into development.

I hope that my company keeps growing so I can do the things the way I want and keep as much BS as I want out of my life (or delegate it, I guess).


A couple observations: First there is a lot of "no true Scotsman" in the comments here, saying, for example, thaht they were not doing standups correctly. Secondly "Agile metrics" is the "diet snacks" of project management. Yes, their metrics improved. But does that really tell you if they made great high-value software?


As hardware engineer that does a hybrid software/hardware role on a team that uses sprint/scrum planning, I find it a terrible idea for a lot of applications. It is great for certain situations but I find the discussions more about what task we should do rather than what problems we should solve and the value added. If things are breaking on a product/project because you didn't know about some upstream or downstream interface, the company itself has an underpinning issue on transparency and ownership. I have rushed hardware projects (expensive mistakes) involving capital equipment (expensive) and everything interfaced correctly given the fact that the ownership and responsibilities were transparent with decent planning in the beginning.


The worst thing about standups is that they tend to be scheduled in the morning. Half of the team I manage are night owls. They suffer when they have to wake up in the morning just to attend a short meeting. That’s why I do everything I can to cancel standups. People become more productive because they gain more flexibility. Now they can work on something till the evening if they are in the zone, without worrying that they have to wake up early the next day. Works even better now that everybody is working from home.


Many years ago I read a post-mortem about the Carmageddon game. They had their management, finance, HR etc in London and all their devs in Sydney. This worked extremely well the post-mortem said, because everyone was at work at the same time...


I'm one of those night owls, thank you. I've had to deal with early morning standups in the past and it was soul crushing and a huge net-negative for my work.

Fortunately my current team does 11:15 which works great, especially from home.


Seriously, does anybody do literal standup meetings anymore during coronavirus and work from home? Or any of the other agile busywork chores? It always struck me as ridiculous to create task cards like in kindergarden, especially in IT. The inability to manage projects using computers is totally unconvincing especially when your team is tasked with creating computer programs. I hope we can finally get rid of agile bs rather than skeuomorph physical task boards and cards into team workflow software.


Since lockdown started, we switched to 3-Ps - everyone post 3 micro tasks they are working on today on a team discord channel before the meeting starts, at 9 we all hop on a team call and go over all the 3ps.

short and sweet.

and gives enough insight for people to ask for help or just get a feeling of progress...

tricky sometime not to list macro tasks, which takes more than a day to complete. but other than that. its also nice to force every on to think about and commit to a few small things they want to work on for the day.


Stand ups are supposed to be good if it has a focused purpose but eventually it morphs into a “I’m continuing to work on X and no blockers”. Then everyone resents what a waste of time it is because the team basically knows 80% of what everyone is already doing. Or the blockers/issues/new features they have won’t be sufficiently explained in the stand up, and everyone pretends to understand or care for it.


> I’m continuing to work on X

Means there is a blocker and the person is stuck or meandering and can't or won't explain it. Major yellow flag.


This seems like it's just a click-baity ad for their productivity analysis tools. I struggle to find a single thing of value in this post.


I don't understand how anyone can tolerate stand ups, how is this not micromanagement?


There is a really important part here I don’t is picked up on. One reason why it’s a ‘stand up’ meeting is because you’re supposed to be doing just that - it helps keep the meeting short and to the point. A really good example of this is the Privy Council. Queen Victoria got tired of long meetings with her Council, so she just kept standing during it, meaning everyone had to as well and couldn’t drag on. They still stand up today. This doesn’t translate well to remote working but like others are saying, the idea is to keep things brief and on point. Longer conversations can follow after.


That heatmap calendar was upside-down from the typical calendar UIs which I've used; it showed time flowing bottom-to-top rather than top-to-bottom. Is this the typical style for Haystack or related tooling?


This sounded like: we changed our routine and then had our most productive week ever. While I think there is a point to what they are saying, I wouldn't take the fact that they had a great week as proof of a better work methodology. If people had voted to have ice cream every morning they might also have had a really productive week because ice cream is fun and changing the routine is fun. But I wouldn't bet the farm on making a company more productive in the long run with ice cream breakfasts.


I vaguely recall research about process changes reliably boosting productivity temporarily but eventually reverting to the mean. Does anyone recall if that effect has a name or a canonical study?


You may be thinking of the novelty effect: https://turnedtwenty.com/productivity-isnt-related-technolog...


That's exactly what I had in mind. Great article. Thanks!


https://uploads-ssl.webflow.com/5ed57622ee14fb96d022d544/5f6...

Is this list representative of the entire scope of the sprint? Unclear from the article. If so, while the sprint was arguably successful in that the engineers felt good about it, it didn't really succeed in improving the customer experience directly.


The biggest point for me from the article isn’t the stand ups.

It’s that their fun projects are, mostly, improving their quality of life while working. Improving deployments, faster compilation, analytics... those aren’t fun because pure fun, those are just necessities that should have been tackled earlier.

Improving that kind of stuff always makes development less frustrating, narrowing the time between something is coded and something is running in production.


The only person that should stand up is the idiot who calls a daily meeting for an hour. These things are only to allow managers to micromanage.


In my opinion daily standups are pointless when there is no short term delivery goal. In my dream company standups, or better dev meetings, would peter out to about once a week and then ramp up as the team approaches a delivery.

I once calculated that daily standups, sprint planning, sprint retrospective, sprint demo, and for some sprint of sprints consume one full day of the week. Now unless the Agile ceremonies make the team at least 25% more productive, to make up for the full day "lost", in my opinion, it is counterproductive.

But none of those activities made our team more productive, effective or deliver faster or better. Our dev teams had a built a great product that customers loved and a customer service that customers frequently lauded us for. In fact, customer loved so much they moved some of their staff into our offices and asked if we had any other product/services to sell to them! (Go figure) We had achieved all this without doing the Agile thing. We simply met and talked though issues. Senior engineers were given the freedom to innovate on the modules that they delivered. It was great, and it worked.


Your comment is a symptom of a larger problem. Sprints make the assumption that you've got some set block to "work on these things". It's just not true. Business is a live environment and priorities change quicker than that for both good and bad reasons. You should be asking the question "Is this something I should be doing" EVERY time you take a task, so doing that once a sprint isn't often enough.


One place a standup can help is when saying what you’re doing today is a farce, because the moment you get out of this meeting someone is going to preempt you to do something else. Showing up every morning and saying you’re working on the same thing because you made no progress the day before is supposed to lead to your manager intervening.

That’s great during the induction phase, but if that quality is still valuable to you a year later? Run.


From a pure engineering standpoint, you're correct. But after starting my own company I have a different opinion: The idea that any work is "Worth doing" more than 10 minutes ahead of time is kinda specious. Everything needs to be evaluated against what's going on RIGHT NOW. People aren't necessarily being unreasonable to interrupt, it's just that the whole picture might not be obvious. Of course there are those who interrupt when they know better, but no process will stop that.


We get stuck on arguments of 'yes/no' a lot and the healthier discussion is usually about degrees.

One developer per team getting pre-empted every day, a little sketch but probably okay (as long as it's not the same couple of people).

Most developers getting pre-empted every day?

Management theory suggests that the managers are supposed to worry about strategy and the developers about tactics. I can't say I agree (because blocking senior devs out of strategy conversations is suicide), but I've watched and heard of many managers who either do neither, or can't take of the developer hat and spend a lot of time talking about tactics (which is a particularly upsetting form of micro-managing).

The 'deal' with Agile was to put a lower bound on the project shifting priorities measured in days, not hours, or failing that, to paint a giant target on the organization's complete lack of strategic thinking.

If you can't strategize a couple of days out, that's not the developers' fault. That's you not being able to do your most important job.


As someone who has worked mostly in a consulting context, "Fun projects ONLY" is... interesting


I wanted to quote something from the “retrospective summary” but it was a photo of the text!


The company I am currently in never had standup, everything is communicated in Slack and Jira and everyone works well together for many years already. This article feels more like a promotional piece for their own SaaS lol


I'm a scrum master, but I'm happy to not do daily standups anymore. I prefer to work harder on todos and concepts and enabling teams to do their work written without talking.


Why is there activity 24 hours a day? That can't be accurate?


A lot of bologna in this thread. Time boxing works, full stop.


OMG your managers must be feeling like they are losing control and scared their importance is diminishing.

Who cares that you are getting more done.... Will somebody please think of the manager's poor egos!


There are so many things that are not FUN, but have to be done anyway. And more often than not the not-fun things are the direct consequence of the "FUN" projects.


Honestly, if you think spending 15 minutes (we’re closer to 10 though) talking to your team to ensure that you know what others are working on and they know what you are working on, then I don’t want to work with you.

It’s not wasted time, and even if you don’t care what I’m working on I still care that you know so that we don’t spend two weeks building something only for you to go “Oh, that won’t work after the changes I made to the core.... why didn’t you come by my desk and ask me “are you intending to change the core code in a way that invalidates all assumptions we had two weeks ago when we started working on this?” And do so like clockwork every day, even though I’d answer no 6 times before suddenly answering yes?

“But we already communicate in the team outside of the Stand-up!” You say. Ok then, tomorrow at your standup, have everyone go though someone else’s points, I’ll say what you did yesterday, if you have blockers and what you’ll do today. If everyone does this flawlessly, then yes the daily is wasted time, but for every mistaken assumption you hear, that is a potential mistake or missed opportunity or just general annoyance you avoided simply by talking 10 minutes together.

Now don’t get me started on the number of bad excuses that you avoid by having daily stand ups that’s a whole other subject, but also an extremely valuable element. “I’m waiting on Kevin to finish X” “Does Kevin know this?” “Yes of cause! “ Kevin: “Wait what? Err what am I supposed to be doing? That’s not on the board”. Etc.


I think spending 15 minutes is great.

But in 15 years, any time a standup was below that target, people commented on how unusual it was to be done already.

The standup is either early enough in the morning that it becomes a passive aggressive way to get people to show up 15 minutes early to work (because if you try to show up on time, you'll be late for a short meeting, essentially missing it), or it is late enough that early risers have to avoid flow state tasks early in the morning or also miss the meeting.

If you are in the middle of something, a 15 minute meeting clears working memory every bit as much as a 3 hour meeting. So if you're going to lose your spot, you might as well get something else out of it. Which contributes to the "but it's never 15 minutes" phenomenon.


I just got out of my team's standup. MY team has 8 people. The standup lasted 6 minutes. I think the people who complain about this, are the ones who have a reason to complain. You don't hear the success stories.


> I just got out of my team's standup. MY team has 8 people. The standup lasted 6 minutes. I think the people who complain about this, are the ones who have a reason to complain. You don't hear the success stories.

I'm not sure if I'd count a 6 minute standup as a success story. My guess is the only person deriving any value from it is some kind of manager who's tracking status, and pulling everyone into a meeting room to do that is mainly just a convenience for that person.

The kind of information that can be conveyed in less than 1 minute per person is likely information that can be collected less disruptively in other ways.

From my perspective as a developer, the best "standups" were the ones that actually deviated from orthodoxy, where we talked about some technical issue or something.


There are many templates for failure, and the funny part is that often the people who contribute to the failure are the ones complaining. But in all cases a good scrum master should be picking up on this and fixing it.

Most typical one is that a team member wants to go deep into details about a task which isn't important and not the case. And after explaining for 10 mins about how they where brilliant in so many ways, they complain when the rest of the team "wastes" their time spending 5 min in total explaining why that brilliant feature was actually not needed which is why it wasn't on the board and no-one asked for it etc. The solution here is to repeat time and time again what the purpose of the meeting is, and cutting people off mid explanation when they go outside their timebox Note though, don't do individual timeboxes unless you are facing this specific issue, it's not good overall but sometimes you need to correct behavior.

Then there are cases where team members aren't paying attention to others and complain the stand-up is wasteful because they never learn anything new anyways, but when you talk to other team members that person spends the rest of they day asking questions that where already answered at the daily. Obvious here you need to do some coaching for that specific member, but I've found it also helps to let them not do their own points, either skip them completely or do them for them. My experience is that it's often coupled to that person going through what they need to say and forgetting to listen.

And on and on. There are so many cases where teams need to correct bad habits rather than complain about the stand-up being there. But sadly the retrospective is often the first thing to go out the window on teams, and they never get to discussing overall how the process is going, and then the daily stand-up gets changed into a 30 min status meeting, and people start hating it.


LPT: schedule your standup for the 15 min before lunch. It’s an almost automatic way to ensure that it finishes quickly. No one wants to be the one that’s making teammates hangry. It also means the meeting never interrupts a developer’s flow since they were going to break for lunch anyways.


This also means your team's day does't start until lunch.


Why do you think the daily stand-up should be the days starting point? That's not a requirement and not at all practical. If you have to skip a stand-up some day because of a dentist appointment or other meeting, do you just not do anything for the rest of the day?


Um, no. My day starts at 7:30 or 8:00 am. Standup is at 11am. I'm about 1/2 done with the day when standup happens. Other folks on my team start work at 10:00 am, so it's closer to the start of the day. I prefer having 1/2 day to get stuff done by the time standup rolls around.


Have you forgotten to have retrospectives? Yes, the first 2 weeks, the stand-ups is badly place, then the team talks about it and chose a different time. (Remember the team decides the time, not management or Product owner), management only gets to decide that you are doing scrum, which means you need to have the daily stand-up.

If you've goon 15 years without any stand-up being under 15 min, then you are doing something wrong. Is your team absurdly large? Is your scrum-master not fluent in scrum? Does no-one in your company understand how a time-box works? Or do you insist on bringing up lengthy technical discussions that you could perfectly well take with the 1-2 people involved outside of the stand-up? There are tons of ways to do it wrong, and pretty much every single one comes back to people not understanding what the stand-up is and isn't for.

It's popular to shit on scrum, but a lot of the criticism comes out like someone going "Programming in C is rubbish, it always throws segfaults, and it's impossible to create good software in a programming language that isn't pure functional" It's an opinion sure, but it's based off of being bad at coding C and preferring to code in Haskell, where you might ask the person if they had considered actually learning C before shitting on it.

> If you are in the middle of something, a 15 minute meeting clears working memory every bit as much as a 3 hour meeting.

Getting interrupted for a 5 min talk with a colleague is just as interrupting to your flow. Don't pretend to claim that everyday in your 15 years of scrum you have accomplished absolutely nothing on a day if there was both a daily standup, lunch, and a person asked you question.

Yes interruptions are bad and should be minimized.. which is why having 15 min condensed to get everyone aligned is better than having 5 people dropping by randomly to ask "did you commit the feature yet?" "Was it me or you who was supposed to do X" "You do know that I'm waiting for you to finish Y right?" "Are you waiting on me to do Z, cause I prefer doing X first, but no-one needs that yet". And again, if a team has more than 15 min total of those kinds of interactions during a day, you need to reflect and improve. If you have less than 15min, then great, everything is cleared up after the daily scrum.


Agile retrospectives are supposed to include discussion about switching up your process to deal with a problem.

Lean management is about picking a small number of processes that are easy to remember and keep backlogs ('inventory') from becoming a liability. And then sticking with them.

I've heard it argued by a former mentor, and people who write books, that Scrum is/has become a Lean process. I still haven't found a counterargument that I think will convince any of them.

A process that is meant to engage everyone in fixing everything but the sacred cow draws attention to the sacred cow. The dissonance is something that people who spend all day thinking in terms of logic prefer not to look at, and so this makes some people angry, others sad, and everyone uncomfortable.


> Have you forgotten to have retrospectives? Yes, the first 2 weeks, the stand-ups is badly place, then the team talks about it and chose a different time. (Remember the team decides the time, not management or Product owner), management only gets to decide that you are doing scrum, which means you need to have the daily stand-up.

Sure, that's the orthodoxy, and assumes the team is actually empowered to do that, but agile-as-practiced often doesn't actually address the problems that it was supposed to solve. In many ways it just replaced one set of ceremonies with another, leaving the fundamentals unchanged.


It's interesting--I completely and utterly agree with out intellectually. But when I look back on many teams I've been on in many companies, daily standups achieve this sort of psychological weight of monotony. Even when they're below 15 minutes they take on a dread.

I don't think this is exclusive to standups: any type of process done repetitively over time can get this upward curve of increasing monotony, even if it doesn't lose its inherent usefulness.

The very act of changing or intervening in a monotonous process might be a boost for people, and to your point is not an argument against the usefulness of the process. I've equally had teams not doing standups get a boost from starting to do standups.

Coming from doing a lot of recommendation systems work, it's similar to how just changing algorithms around often leads to a temporary boost in engagement which then regresses back to the mean (same in general A/B testing).

When I'm managing a process and someone comes to me with a process change suggestion, and I feel like I am well-stocked with evidence as to why the existing process makes sense and is efficient, I now have a meta-assessment where I consider the change because it will at the very least mix things up and introduce changes to thinking. Obviously that is not to be done willy nilly, but my younger self would have pushed back on process changes that were not inherently superior to the existing ones.


There's an in-between here. Daily standups just aren't a great fit in many cases... weekly standups will tend to work better in these cases. At the end of the day it boils down to the difficulty of the tasks to be executed and how much R&D and design work there is. The more R&D heavy your workload the more impractical daily standups tend to be.


Yea, we did stand-ups Mon, Wed, Fri, which tended to be a good balance. Still able to let people know what you are doing, but not having to be forced to do it everyday as if you are children.


> It’s not wasted time, and even if you don’t care what I’m working on I still care that you know so that we don’t spend two weeks building something only for you to go “Oh, that won’t work after the changes I made to the core.... why didn’t you come by my desk and ask me “are you intending to change the core code in a way that invalidates all assumptions we had two weeks ago when we started working on this?” And do so like clockwork every day, even though I’d answer no 6 times before suddenly answering yes?

I thought the whole point of orthodox standups (and one of the brain-dead things about them), was that you weren't supposed to have discussions at that level of detail.


You are absolutely correct and people not knowing this results in a "standup" that balloons into a one-hour verbal trash bin. This is the issue my company has. Daily "standups" that can take 30-60 minutes.

BUT WAIT HOLD ON, it's 15 minutes of "standup" and 45 minutes of "parking lot." eye-roll

This is every single day, by the way. Our previous manager got the picture and reduced these to three times a week with hard time limits. Then a new manager came on and put daily "standups" back on, after apologizing that he was adding a meeting to our no-meeting day, lol.

I'm dead inside.

It also psychologically feels bad when you have the same update every day (e.g. working on a long-term project) or if you have no update. It's also really fucking stupid to have a "standup" on Friday morning and another on Monday morning.

I'm dead inside. I'm dead inside. I'm dead inside.

Also I take any opportunity to vent about these stupid "agile" methods, sorry.


I know this isn't your place to fix, but honestly align with your scrum master and just stage a walk-out of the "parking-lot" meeting for you and the team. You should not be required to attend this.

After doing this a couple of times people will realize that there is something wrong if you have to spend 45 minutes a day digging deeper into issues. Poorly planned spring backlog? A non-existing product backlog? There could be many issues, but trying to "patch" them by doing things wrong.

> Also I take any opportunity to vent about these stupid "agile" methods, sorry.

So I'm sure you've raised these concerns at the end of every iteration at the retrospective right? Please tell me that you didn't throw out the retrospective and the process for venting frustrations to facilitate change and then start changing the process completely and then end up being bad at this thing you are doing which definitely wouldn't be scrum then.


Currently, a lot of the members on our team just miss standup entirely. For example, I missed the last 3 days of standup. Showed up today to re-iterate that I'm making some prod changes. Our sprint backlog and sprint planning meetings are a disaster, too. Watching our manager struggle every single time with jira is just.... mind-numbing. We complained about those and did get some changes made. For example, our sprint planning "meeting" went from two 1.5 hr meetings (one before lunch, one after) to one 1.5 hr meeting before lunch. I sometimes miss those, too.

I raised these concerns with this manager when they first started (specifically about the number of meetings AND the daily standup). I raise them in the retrospective every time we have one. I raised them with my engineering team manager. I raised them in those anonymous feedback things.

We're currently in the process of getting this manager out of our team. Our manager went on vacation and our productivity went up by some crazy amount, lol. The only thing keeping us stuck at this point is the current covid situation (long story). But normally, I'm pretty sure they would have been gone as of a month ago or so.

It's an organizational thing, though, not just that manager specifically. Half the battle is getting upper management to listen to our concerns and do something about it.

But the reason our last manager was so good about these things is because he had clout within the company and the assertiveness to say "no, that isn't ok."


Yeah, standups are for triage. If someone raises an issue then you work out who they need to talk to about that and arrange for that to happen. The details get hashed out in the separate smaller meetings (or 1:1 conversations).


> Yeah, standups are for triage. If someone raises an issue then you work out who they need to talk to about that and arrange for that to happen. The details get hashed out in the separate smaller meetings (or 1:1 conversations).

Honestly, I expect competent developers to be able to do that on their own, without needing someone to make arrangements or having to wait for a standup.


It can be convenient to have a set time each day. Because it means non-urgent issues can be taken care of without disrupting people while they're in the middle of something.


I think the disparity is that, for most organizations, Standup isn't "talking to your team to ensure that you know what others are working and and they know what you are working on", but instead "A person gives vague generalizations about a story/ticket number, the rest of the team pretends to listen."

And yes, sure, that is objectively not the point of the meeting and blaming the meeting for people misbehaving isn't right. But it's a cowpath argument to me. If the meeting is in service of a team and their collaboration, collaborate in the ways the team finds most meaningful. Do not force a team to pretend to be collaborating.


Except that a stand up doesn’t actually solve the problem you are referring to. People don’t pay much attention to what you’re working on in stand ups since it’s most probably not relevant to what they’re working on at the time. It is unreasonable to expect people to have perfect foresight that what you’re working on is going to be relevant to them 2 weeks down the line. There are better ways to solve that problem but stand ups is not one of them.


> It is unreasonable to expect people to have perfect foresight that what you’re working on is going to be relevant to them 2 weeks down the line.

I would understand if you said 2 years or 2 months. But if your road-maps and plans change so rapidly that you can't even assume that features coordinated one day will still be relevant 2 weeks after... then how on earth do you have a functioning team without daily communication? And if you do have daily communication, why not concentrate that to a single max 15 min period to reduce being interrupted in flow?


The nature of changes is that you cannot predict them in advance.

Even if you knew your roadmap for 2 months and were operating perfectly, something unpredictable could happen, as things do. Such things don’t give you any kind of notice before they happen.

In such an event, you can’t be expected to remember something someone told you 2 weeks ago in passing anyway. Standups are a short but heavy information dump and are not good at facilitating recall as time goes on. This is true especially if you are operating in a rapidly changing environment such as a startup.


In another system, like XP, the standup might allow you to absorb a lot more info about your peers. Within the metronome of Scrum, too many people are under time pressure to save face and are likely to say their but and tune half of what everyone else says out entirely.


I completely disagree. As a developer, standups have always ended up devolving into the bane of my existence, and now I only work for companies that don't do them (or at a minimum, allow them to be async).

Not all of us enjoy being micromanaged.


Standups aren't the place to hash this out, sprint/epic planning is.

Standups are for managers and 99% of the time can be done asynchronously. If you have to know what everyone else is doing in order to be effective at your job, your planning process needs fixing.


How would the standups be for managers? They don't attend. Even the scrum master is not required to attend, only required to ensure the meeting happens (which for most teams often means the scrum master has to attend, but still.)


I've never had a standup my manager wasn't at. I know they're not supposed to but like, theory vs. practice etc.


Standups are also for people who like the illusion of control that comes with knowing what everyone is working on and having a say in every single decision/work.


Standups (weekly, not daily) worked pretty well for us at 5-20 people: maybe 5-12 devs and 2-8 other stakeholders. Smaller than that, and communication was so easy and natural we didn't need standups. Bigger, and it became tedious and low signal (everyone didn't need to know everything).

We now have more than 50 devs, and we've remained quite flat and autonomous. It would be literally impossible for me to track what all the other devs are working on, never mind going over it every day in 15 minutes. It probably works better for siloed dev/product teams that stay under 30 people, but that's not how we work.

I share all this to give perspective on a pretty bold statement: "If you [don't like standups], then I don't want to work with you." Ten people is a good size for standups, and I think you may be overgeneralizing your experience when judging people who don't like standups.

Even still, I'm curious how much is changing daily to warrant daily standups? We have a rotating "release team" who runs QA and ultimately performs releases, and they check in daily. But daily checkins for feature development seem very frequent to me.


Our team doesn't do daily standups as everyone pretty much knows what other people are working on. There's communication on Slack. There's a list of issues and/or roadmap items that are assigned.

Then again, we have a small and high functioning team where there's no "waiting for X to finish Y" or blockers that aren't resolved immediately via communication on Slack. There's never a lack of issues to work on. Nothing assigned to you? Well, pick something from the list of issues or something on the roadmap, communicate to the team that you're working on it, communicate when you're done.

For a team of 6, 15 minutes a day is 90 minutes of productivity. That's 7.5 hours a week, pretty much almost a whole day of productivity for a person.

Whether standups are great for your team or not depends on the makeup of your team and personnel, the size of your team as well as the nature of the work and how work is divvy-ed up. I've found success on teams with and without standups, and I'll say that not having 15 minutes of the start of your day spent on being in a meeting is absolutely refreshing


In my opinion standups are waste of time when they are mandated by some boss. When they are used as head count moment to see everyone is in the office working on things. Then it turns into status report for that manager and maybe he starts even micro managing people by handing them tasks and asking questions to each person.

If standup is needed by the team and it feels natural then it probably is useful. Nowadays with remote work I kind of like to have at least 10 mins to see people that I am working with each day.


Imagine having to speak and say what you are doing in about 2 minutes. The horror. Part of your job is communicating what you are doing to others. It is common courtesy and a social skill. Cultivate it.

Stand Ups by nature are to be quick. It is why YOU DON"T SIT.

You can do them over Teams, Zoom, Slack.

Companies allocate millions to billions of dollars for projects and have a need to know how things are progressing and if there are issues and resources that can be brought to bear to solve them.

If your manager or "Boss" is micro-managing you to death, then leave. The culture is toxic and a 10 minute stand up is the least of your issues.


That's not communicating, a daily standup IS micro-managing. It's an incredibly destructive and soul-crushing anti-management technique.

No-one needs to have daily updates. Weekly, twice weekly, maybe, daily is simply treating people like small children.

Communication is a two-way street, not irrational cargo culted standups.


Found the bug in your process in line 1. Managers shouldn't be attending your daily stand-up.


I find the whole standup discussions hilarious. Primarily because the same discussion will always have massive proponents of stand ups offering at least 2 completely contradictory justifications for stand ups.

1) Standups are for knowing what your team is up to. 2) Standups are for removing blockers.

If (1) is correct, then let’s just call them what we always did before the SW Project Management Industry decided to buzzword it. Status updates.

And if they are status update meetings, then the simple question becomes why they should be daily. Their cadence should be dependent on the type of work the team is doing. If the type of work you’re doing means the majority of your work items are done in a day or less, then by all means have a daily status update meeting. However, if like many teams, the majority of your work are items which take 2-3 days, if not weeks, to complete, then why not just do 1-2 status update meetings a week?

And when it comes to removing blockers, why have a daily meeting at all. Why not do it in an async format using mailing lists (or Instant message/Teams/Slack/etc) instead. That ensures you’re not blocked waiting for the standup, and everyone is aware of your blocker as soon as is convenient for them.

In practice, however, Standups tend to be a mixture of both (and that’s how they are usually defined...what you did yesterday/what you will work on today is status updates, and blockers is about removing impediments). And that makes even less sense from a purely theoretical perspective (never mind the scores of practical experiences where it’s been a disaster), because those 2 tasks have different ideal cadences. Blockers are something that should be shared immediately, as they happen. Status updates, however, should have a far slower cadence, where you need to balance the need to keep the team informed about your work, and share progress towards goals, with the fact that each update is an interruption, and so the ideal cadence would be dependent on the nature of the work the team does.

The idea of a daily standup is a good fit only for teams whose work happens to be such that once a day happens to be an appropriate cadence for their status updates. And even then it’s not a good solution for the blockers removing aspect.


We occasionally spend 20 min on Tuesday and Thursday, at around 14:00. That's enough for us. But then again, we're in a very unusual position as a team.


You're conflating not knowing (or caring) what's going on with a meeting. You absolutely should care what's going on with a team, because if you're work isn't affecting each other there's little reason for you to be a team. That communication shouldn't be every day though, it should be constantly available to whoever needs it at the time they need it.

Software can achieve this, and it's what my startup is trying to make happen. The key is to unify status-as-in-state with status-as-in-active-communication so the two can inform each other.


This suggests a fun exercise:

Once a week, maybe right after each person says what they did, everyone gets randomly assigned a person and they have to explain what that person did last week.

The goal of this exercise: Make people actually pay attention to what others are doing and ensure they really understand it (and feel empowered to ask questions if they don't)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: