The pointlessness of daily standups(codethrasher.com)
codethrasher.com
The pointlessness of daily standups
https://codethrasher.com/post/2019-10-06-the-pointlessness-of-daily-standups/
298 comments
Back when I first started doing daily standups at jobs almost 20 years ago -- when agile/xp was first starting to buzz -- it honestly felt like a breath of fresh air and explicitly something that management would _not_ want. Quick, informal, brief checkpoint with your coworkers, then back to work. We had a group of almost 20 engineers & QA people in a circle, but it went quickly and inobtrusively... nobody spoke for more than a few seconds. We all knew what everyone else was doing, and could go offline and have a discussion afterwards if necessary.
It was a meeting for ourselves, not for management. There were no status reports to management, no gantt charts, no percentage estimates of completion, etc. Just: here's what I'm doing/not doing.
Fast forward a decade or two and I've seen good and bad use of this meeting form. But I still think it's a good idea, it just requires discipline to stop people from hogging air space or veering off into tangents.
It was a meeting for ourselves, not for management. There were no status reports to management, no gantt charts, no percentage estimates of completion, etc. Just: here's what I'm doing/not doing.
Fast forward a decade or two and I've seen good and bad use of this meeting form. But I still think it's a good idea, it just requires discipline to stop people from hogging air space or veering off into tangents.
"It was a meeting for ourselves, not for management. There were no status reports to management, no gantt charts, no percentage estimates of completion, etc. Just: here's what I'm doing/not doing."
That's my understanding of what a standup is supposed to be, and it's what my experience of them has been. THIS is useful. It's in particular useful if you have devs on the team who tend to get kinda "wound around the axle" on problems rather than speak up or seek help.
There will always be devs who think any meeting is by definition a waste of time, and you can't make those people happy, but a true brief standup meeting as described here is SUPER useful.
(Daily's probably too much though.)
That's my understanding of what a standup is supposed to be, and it's what my experience of them has been. THIS is useful. It's in particular useful if you have devs on the team who tend to get kinda "wound around the axle" on problems rather than speak up or seek help.
There will always be devs who think any meeting is by definition a waste of time, and you can't make those people happy, but a true brief standup meeting as described here is SUPER useful.
(Daily's probably too much though.)
Like many things, if it works for you and doesn't turn negative, then that's great and more power too you.
Personally, when I lead a team, I keep abreast of what people are working on and ask them if they need help, or tell one of the more suited senior guys to offer a hand if it's an area I can't easily help in.
I imagine the standup helps more when you're lead is a non-technical scrum master guy who doesn't have much of a personal relationship with the team.
On the latter point I typically buy my team members fancy coffees and the occasional lunch, and it's easy to get on with them if you care about their careers, so I've never needed a standup.
Personally, when I lead a team, I keep abreast of what people are working on and ask them if they need help, or tell one of the more suited senior guys to offer a hand if it's an area I can't easily help in.
I imagine the standup helps more when you're lead is a non-technical scrum master guy who doesn't have much of a personal relationship with the team.
On the latter point I typically buy my team members fancy coffees and the occasional lunch, and it's easy to get on with them if you care about their careers, so I've never needed a standup.
That's the point: the stand up is for the team, not the manager. She/he should stay out of it.
That's a difficult argument? Is the manager not part of the team? Depends on the org, I guess.
Either way, I'm not so sure the statement means much. The point of agile is to do what's helps, so if a standup is useful for the above reasons, it's entirly possible that another approach solves the same problem, negating the need for the standup.
Either way, I'm not so sure the statement means much. The point of agile is to do what's helps, so if a standup is useful for the above reasons, it's entirly possible that another approach solves the same problem, negating the need for the standup.
It definitely depends on the structure of the org. But I do make a distinction between management and team lead. On some teams the management is technical and involved in daily tasks. In others, less so.
But the key thing is that the daily standup is NOT a status report for management! That should not be its purpose! It is for the team members to sync with each other, not a daily report for task management.
But the key thing is that the daily standup is NOT a status report for management! That should not be its purpose! It is for the team members to sync with each other, not a daily report for task management.
I don't disagree and for the record I'm an engineer. I don't think my points are actually counter to yours. :)
Not every group interaction requires every member of the group, not sure what's hard to grasp about that.
The manager has plenty of other ways to gather status updates and feedback as you note.
The manager has plenty of other ways to gather status updates and feedback as you note.
> not sure what's hard to grasp about that.
Your tone is slightly rude considering you're essentially agreeing with me.
You'll need to note the entire thread for the context of my discussion. I was specifically saying a good tech lead and other senior engineers can help engineers get unstuck without actually necessitating a standup.
For me, standups are fine if the team actually want to do them and find them useful, but 9 times out of 10 they're enforced by someone non-technical and require the entire team listen to people drone on justifying what they did yesterday.
Personally, I find the assumption that I can't communicate with fellow engineers without such a thing pretty insulting, but do understand that some of us do struggle with this thing, so it's different strokes for different folks.
Your tone is slightly rude considering you're essentially agreeing with me.
You'll need to note the entire thread for the context of my discussion. I was specifically saying a good tech lead and other senior engineers can help engineers get unstuck without actually necessitating a standup.
For me, standups are fine if the team actually want to do them and find them useful, but 9 times out of 10 they're enforced by someone non-technical and require the entire team listen to people drone on justifying what they did yesterday.
Personally, I find the assumption that I can't communicate with fellow engineers without such a thing pretty insulting, but do understand that some of us do struggle with this thing, so it's different strokes for different folks.
I seem to remember a time when standups did not necessarily involve the product owner. I feel like a lot of things have changed in Scrum that have progressively brought more of management into its ceremonies in ways that have actually disrupted a lot of the early goals of the process.
Interesting, yeah, we were doing something closer XP, not Scrum. I've never done Scrum. Haven't done "agile" in the last 10 years, as it's not really a thing where I work now.
But yes, in XP, the 'customer' or 'product owner' would not attend a daily standup. The purpose of the meeting was for developers to sync and maintain velocity and social and work cohesion.
Meeting with customer/PM was something that happened at the end or start of iteration.
But yes, in XP, the 'customer' or 'product owner' would not attend a daily standup. The purpose of the meeting was for developers to sync and maintain velocity and social and work cohesion.
Meeting with customer/PM was something that happened at the end or start of iteration.
What use is knowing what 20 other people are doing today? Are you interacting with all of them? Interesting to know what projects they're working on, but I can be told that once a month if I haven't already got that while chatting to them at the coffee machine. A 20 person meeting for each to speak for a few seconds is to me very theatrical - drop a sentence in a chatroom. If I'm not working directly with you I'm not going to read it, nor listen to you in a stand-up.
In an 'agile' process people should only be working on any particular 'story' for 3-5 day period. Everyone on the team should be interested in what they other people are doing, because they may in turn be pulled into work on some part of it next. In a healthy team everyone should be invested in the success of the product, and have some knowledge of most aspects.
Frankly, once things scale beyond that, where you have large teams of people disinterested in what's happening beyond their choice of specialization -- "agile" starts to not be a good match anymore.
Frankly, once things scale beyond that, where you have large teams of people disinterested in what's happening beyond their choice of specialization -- "agile" starts to not be a good match anymore.
Yea, the minute the managers stick their beaks in the whole vibe turns sour
> What people are working on is usually unrelated and of no interest to each other
I think this is the key difference between teams that like stand-ups and teams that don't. In the teams I've worked in, our work was highly relevant to one another, so knowing daily where everyone was with their tasks is usually interesting to everyone.
I think this is the key difference between teams that like stand-ups and teams that don't. In the teams I've worked in, our work was highly relevant to one another, so knowing daily where everyone was with their tasks is usually interesting to everyone.
I second the above comment, this is indeed the difference between a team and what shouldn't be a team. If people at a standup are talking about unrelated things then they indeed shouldn't be having standups, much less be considered a team in the first place. What's happening in standups and probably other meetings are symptoms of a structural issue people are either not seeing or failing address.
My rule of thumb for assessing a team is based on two simple questions: 1. Do people in the team work towards the same goal? 2. Do people in the team depend on each other? If the response to both questions is positive then by all means, have standups. In other cases, have a good look at whether it makes sense to call them a team in the first place.
My rule of thumb for assessing a team is based on two simple questions: 1. Do people in the team work towards the same goal? 2. Do people in the team depend on each other? If the response to both questions is positive then by all means, have standups. In other cases, have a good look at whether it makes sense to call them a team in the first place.
unrelated is relative. If I'm working on bug A and bob id working on bug B, I don't give a shit that bob is having to go talk to cathy in accounting about something.
They're unrelated tasks because there are no dependencies between them, and there is absolutely no reason why I should have to sit through bob talking about his day.
They're unrelated tasks because there are no dependencies between them, and there is absolutely no reason why I should have to sit through bob talking about his day.
But the point of these, at least to me, is that someone on the team may know a way to get the problem solved without talking to Cathy in accounting. Sure, sometimes you listen to unrelated tasks, but many times (in my experience), somebody on the team can offer a bit of advice that helps everyone move faster.
EDIT: Spelling.
EDIT: Spelling.
and now the "standup" has devolved to a design session, and I don't want to have to stand there while bob and betty have a discussion about it.
The point of the standup is to figure out you need that design session, not to conduct it then and there.
Take ownership of the standup, don't just passively sit there and then complain afterwards what a waste of time it is.
Take ownership of the standup, don't just passively sit there and then complain afterwards what a waste of time it is.
It certainly can. We try to take those types of discussions offline though--Bob and Betty can have that talk after the standup.
And to clarify, I also find daily standups to be tedious and generally unhelpful. Once or twice a week seems to be the sweet spot (for me/my team).
And to clarify, I also find daily standups to be tedious and generally unhelpful. Once or twice a week seems to be the sweet spot (for me/my team).
right, Bob and Betty can have that discussion elsewhere. all of it. We don't need a standup for Bob and Betty to figure out they need to have that discussion.
But as the article points out, knowing daily where everyone was with their tasks isn't something that needs a formal meeting. I've worked in highly integrated teams, too, and easily got by with one team meeting a week.
Depends on the size of your team. Once you get to 10+ people in a team, it's hard to spread information effectively with 1:1 communication. What I've liked about standups in teams of that size is the opportunity to kick of unexpected brainstorming because you mention what you're working on and someone mentions they have expertise/ideas in the area that you didn't know about.
There are of course many ways to run a productive team.
There are of course many ways to run a productive team.
In my experience, 10 is way too many for daily standups! Thats when they start getting dragged out from 5 minutes to a 45 minute snore-fest, hearing every little needless detail from someone elses problem that I have no need for!
I find the team needs to be at most 6 people, otherwise you probably need to split the team for daily standups to work.
I find the team needs to be at most 6 people, otherwise you probably need to split the team for daily standups to work.
That wasn't my experience, but it definitely takes an emphasis on brevity to prevent that. We found two techniques that helped with bigger teams:
1. Everyone explicitly has the responsibility to say "this is going too deep, let's continue it outside of standup" when needed.
2. Having a timer visible that resets after each person's update. This makes it clear when one person's update is taking too long. We were able to get rid of the timer once we had the flow down.
Also, it's crucial that everyone on the team feels comfortable saying: "these standups aren't a good use of our time, let's make a change". That's how those techniques were introduced.
1. Everyone explicitly has the responsibility to say "this is going too deep, let's continue it outside of standup" when needed.
2. Having a timer visible that resets after each person's update. This makes it clear when one person's update is taking too long. We were able to get rid of the timer once we had the flow down.
Also, it's crucial that everyone on the team feels comfortable saying: "these standups aren't a good use of our time, let's make a change". That's how those techniques were introduced.
I consult and I've been at places where a 4 person standup take a half hour. Usually then I start telling people "We don't solve problems in stand up."
I've also worked at places where a 20 person standup took < 10 minutes and helpful b/c sometimes someone not on your team will know how to fix your blocker and just help you out afterwards.
I think as long as you have a standup czar or just post your updates to slack, then it's a super useful meeting. If it ever goes over 10 minutes then whoever is running it is just making everyone late for work.
I've also worked at places where a 20 person standup took < 10 minutes and helpful b/c sometimes someone not on your team will know how to fix your blocker and just help you out afterwards.
I think as long as you have a standup czar or just post your updates to slack, then it's a super useful meeting. If it ever goes over 10 minutes then whoever is running it is just making everyone late for work.
How about when your PM who doesn't understand Agile in the slightest combines two 5-10 person teams in a single, painful 3x-weekly standup.
> Depends on the size of your team.
Why does it depend on the size of your team? Teams involved in agile development (where they do the whole daily standup kerfuffle) are supposed to not get to 10+ people. That's like the third thing on the agile coach's slide.
Besides, why does it take a full-team standup to find out someone has expertise and ideas in an area that you didn't know about? Are the lead developers/managers sleeping at their desks? Guiding and bringing people together is one of the things they're paid for. They should know who's good at what, and steer the right people (or the right tasks) towards them. If they aren't doing their job, what the team needs is people who do, not one more thing that developers have to figure out on their own time.
As for brainstorming -- it shouldn't be unexpected in the first place. Not on a regular basis, anyway. If a developer needs that brainstorming session, they should have the means to make it happen, with only the interested people attending. If they need it, but don't know they need it -- especially common, and especially excusable for junior developers -- that's why we have lead developers and managers.
And meetings are not the only way to spread information! If a team has 10, 15 members or more and it's spreading information by word of mouth alone, whether 1:1 or in meetings, that's already a problem. At that point you should have things documented. New members should have an M that they can RTF and ask experienced team members about. If a team got to that size and the only way to spread information is in person, that's something they should remedy, not keep doing!
Why does it depend on the size of your team? Teams involved in agile development (where they do the whole daily standup kerfuffle) are supposed to not get to 10+ people. That's like the third thing on the agile coach's slide.
Besides, why does it take a full-team standup to find out someone has expertise and ideas in an area that you didn't know about? Are the lead developers/managers sleeping at their desks? Guiding and bringing people together is one of the things they're paid for. They should know who's good at what, and steer the right people (or the right tasks) towards them. If they aren't doing their job, what the team needs is people who do, not one more thing that developers have to figure out on their own time.
As for brainstorming -- it shouldn't be unexpected in the first place. Not on a regular basis, anyway. If a developer needs that brainstorming session, they should have the means to make it happen, with only the interested people attending. If they need it, but don't know they need it -- especially common, and especially excusable for junior developers -- that's why we have lead developers and managers.
And meetings are not the only way to spread information! If a team has 10, 15 members or more and it's spreading information by word of mouth alone, whether 1:1 or in meetings, that's already a problem. At that point you should have things documented. New members should have an M that they can RTF and ask experienced team members about. If a team got to that size and the only way to spread information is in person, that's something they should remedy, not keep doing!
Lead developers and managers can't keep track of all the minutae that people have worked on in their careers.
For a concrete example: if I track a performance problem down to a small part of an open-source piece of software, it isn't realistic for managers/lead developers to know if anyone on the team has experience with that piece of the software. But if I mention that in standup, it will immediately be clear if anyone has expertise that is valuable.
I've never seen a high performing team that didn't regularly have ad-hoc brainstorming sessions (i.e. you say what you are planning to do and someone says "have you considered this"). Like I said, there are many runs to run a productive team, but standup can be a good place to start that discussion.
For a concrete example: if I track a performance problem down to a small part of an open-source piece of software, it isn't realistic for managers/lead developers to know if anyone on the team has experience with that piece of the software. But if I mention that in standup, it will immediately be clear if anyone has expertise that is valuable.
I've never seen a high performing team that didn't regularly have ad-hoc brainstorming sessions (i.e. you say what you are planning to do and someone says "have you considered this"). Like I said, there are many runs to run a productive team, but standup can be a good place to start that discussion.
> Lead developers and managers can't keep track of all the minutae that people have worked on in their careers.
Keeping track of people's skills and expertise is part of their job description. If they don't, how are they going to help them develop and steer their careers? Not knowing every single thing they've worked on is one thing, but knowing (as in your example) who is likely to have used that piece of software, or who has experience troubleshooting performance problems involving that piece of software's functionality, is definitely their responsibility.
> For a concrete example: if I track a performance problem down to a small part of an open-source piece of software, it isn't realistic for managers/lead developers to know if anyone on the team has experience with that piece of the software.
Certainly -- but that doesn't justify having a stand-up meeting every day. It's not realistic for managers/lead devs to know if anyone on the team experience with a particular piece of software, but it is realistic for them -- or for any developer, for that matter -- to be able to find that out without dragging everyone from their desks for half an hour or more.
Keeping track of people's skills and expertise is part of their job description. If they don't, how are they going to help them develop and steer their careers? Not knowing every single thing they've worked on is one thing, but knowing (as in your example) who is likely to have used that piece of software, or who has experience troubleshooting performance problems involving that piece of software's functionality, is definitely their responsibility.
> For a concrete example: if I track a performance problem down to a small part of an open-source piece of software, it isn't realistic for managers/lead developers to know if anyone on the team has experience with that piece of the software.
Certainly -- but that doesn't justify having a stand-up meeting every day. It's not realistic for managers/lead devs to know if anyone on the team experience with a particular piece of software, but it is realistic for them -- or for any developer, for that matter -- to be able to find that out without dragging everyone from their desks for half an hour or more.
It's a matter of effort for reward. I get the sense from you that you find standups to be miserable so any way to get rid of them is worthwhile, even if it's less efficient (and having managers/lead developers track who is working on what specific piece of software and organize conversations to make sure the right people are talking to each other is not efficient).
In my experience, standup has almost no cost and is generally enjoyable - people typically like talking about what they are doing and getting thoughts/advice. But if your standups are "half an hour or more", they clearly don't have much in common with the standups I've done. I would propose that maybe the problem is your standups are poorly run, not that the concept itself is bad.
In my experience, standup has almost no cost and is generally enjoyable - people typically like talking about what they are doing and getting thoughts/advice. But if your standups are "half an hour or more", they clearly don't have much in common with the standups I've done. I would propose that maybe the problem is your standups are poorly run, not that the concept itself is bad.
I find stand-ups pretty fun, too, but that's all -- and it's definitely not an experience that everyone finds enjoyable. We all like to talk about what we're doing. Some of us, myself included, gladly jump at every chance to do it, including stand-ups. Others, though, see the whole standup thing in terms that are closer to herding people into a meeting room and prodding them until they start talking.
As for timing: if you have a 10- or 15-people team, allowing for even just two minutes per person -- which is barely enough to cover a non-trivial problem -- easily gets you to 20-30 minutes. It gets shorter if all updates are in the form of "no news is good news", but then the meeting could have just as easily been an email. It also gets shorter if the problems really are so trivial that fifteen people can describe all of them, and their solutions, in a couple of sentences, so that no one talks for more than 30 seconds -- but then are these problems really so big that you need to hold a meeting that everyone attends, every single day?
I don't think the concept itself is bad -- just that the arguments for efficiency aren't convincing when it comes to large teams. I doubt that you can really disseminate useful information in this format, and even if you could, there are way more efficient ways to do that.
Edit: If these meetings are held just to make sure all updates are given regularly, often, and in the open, with all the consequences this has (good ones, like everyone being on the same page, and bad ones, like opportunistic managers taking the chance to use this as a way to pressure their team), that's great, but let's be frank and admit it.
As for timing: if you have a 10- or 15-people team, allowing for even just two minutes per person -- which is barely enough to cover a non-trivial problem -- easily gets you to 20-30 minutes. It gets shorter if all updates are in the form of "no news is good news", but then the meeting could have just as easily been an email. It also gets shorter if the problems really are so trivial that fifteen people can describe all of them, and their solutions, in a couple of sentences, so that no one talks for more than 30 seconds -- but then are these problems really so big that you need to hold a meeting that everyone attends, every single day?
I don't think the concept itself is bad -- just that the arguments for efficiency aren't convincing when it comes to large teams. I doubt that you can really disseminate useful information in this format, and even if you could, there are way more efficient ways to do that.
Edit: If these meetings are held just to make sure all updates are given regularly, often, and in the open, with all the consequences this has (good ones, like everyone being on the same page, and bad ones, like opportunistic managers taking the chance to use this as a way to pressure their team), that's great, but let's be frank and admit it.
If your "standup" is half an hour or more, it's not a standup, it's a status meeting that your org just happens to call a "standup".
A real scottish standup is a few minutes -- 5 or 10 minutes. 15 max if there are lots of people and lots of things to cover.
A real scottish standup is a few minutes -- 5 or 10 minutes. 15 max if there are lots of people and lots of things to cover.
This was all in the context of large teams, larger than the Agile methodology recommends.
How much useful stuff do you think a developer can fit in 20 seconds of speech -- which is about all they get if you want to fit a 15-people meeting in a ten-minute timeslot?
Once a team grows past a certain size, either you keep the discourse substantial -- and end up with 30-minute meetings -- or you cut everyone short, and end up with ten minutes of smiling and saying the right buzzwords.
How much useful stuff do you think a developer can fit in 20 seconds of speech -- which is about all they get if you want to fit a 15-people meeting in a ten-minute timeslot?
Once a team grows past a certain size, either you keep the discourse substantial -- and end up with 30-minute meetings -- or you cut everyone short, and end up with ten minutes of smiling and saying the right buzzwords.
> How much useful stuff do you think a developer can fit in 20 seconds of speech
1. What did you do yesterday?
2. What are you doing today?
3. Any blockers?
1. What did you do yesterday?
2. What are you doing today?
3. Any blockers?
With the amount of churn that there is in a lot of companies, it's unreasonable to expect anyone to do much of anything except bail water and try to keep things going within a handful of compass points of the correct direction.
My company is blessedly stable, but for instance at my wife's employer, there are teams that have had 300% turnover in the two years she has been there.
I think this kind of endless short-term firefighting is part and parcel with the micromanagement that daily standups embody. When nobody actually has any experience, or built any trust over time, the whip lays on heavier to keep people in line and pulling in the same direction.
My company is blessedly stable, but for instance at my wife's employer, there are teams that have had 300% turnover in the two years she has been there.
I think this kind of endless short-term firefighting is part and parcel with the micromanagement that daily standups embody. When nobody actually has any experience, or built any trust over time, the whip lays on heavier to keep people in line and pulling in the same direction.
What’s the point of knowing what the rest of 10 people are working on? You won’t remember all of it anyway. There is no need to add so much cognitive load to your brain every single morning. Engineers should imho start their day with clear mind.
To give ideas based on your experience. To raise questions that might not have been considered. To build a team instead of a collection of independent cogs. To know what expertise your teammates have so you know who to go to with a question in the future.
It really shouldn't be much cognitive load to listen to what other people are working on for 10 minutes. If it is, it might mean the standup is running at the wrong level of abstraction or perhaps you aren't really a team that has a shared goal.
It really shouldn't be much cognitive load to listen to what other people are working on for 10 minutes. If it is, it might mean the standup is running at the wrong level of abstraction or perhaps you aren't really a team that has a shared goal.
You can either have 15 minute quick standup or you can have a meeting to give ideas, raise questions and know my teammate's expertise.
> If it is, it might mean the standup is running at the wrong level of abstraction or perhaps you aren't really a team that has a shared goal.
Or maybe the problems other people are working on will take more than 10 minutes for any reasonable input.
> If it is, it might mean the standup is running at the wrong level of abstraction or perhaps you aren't really a team that has a shared goal.
Or maybe the problems other people are working on will take more than 10 minutes for any reasonable input.
IMO standup shouldn't be where the conversation takes place, it's where the conversation starts, to be picked up after standup/in a separate meeting.
Bingo - the whole idea of any meetings before lunch is absurd. Your brain does 90% of its best thinking between wake up and lunch... why waste that on meetings? Sorry for the sidebar... I’m loving this thread. I’ve been telling my wife for years that daily huddles are a scam that manipulative management types do “to maintain momentum” or the appearance of it at least.
On the other hand, the Scrum Guide[1] recommends that teams have 3-9 people in them, and that more leads to poor coordination. Seems like an inverse "Goldilocks problem", Scrum standups are best when there are more than 10 people and less than 10 people in the team.
[1] https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum... - page 7
[1] https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum... - page 7
That aligns with my experiences, we aimed for 6, with a max of 8, with a min of 4.
I will say, Scrum was really helpful for us, but only because we took "iterate on your process" seriously, and had a culture where teams could experiment with their process.
In the end we outgrew it, but Scrum helped us reach the point where we could do so.
I will say, Scrum was really helpful for us, but only because we took "iterate on your process" seriously, and had a culture where teams could experiment with their process.
In the end we outgrew it, but Scrum helped us reach the point where we could do so.
I am absolutely not a believer in anyone who talks about agile techniques as having 'Rules'. That is a trademark of agile gone wrong to me.
Small teams are better, but not always possible. Agile is about having team mechanics that make your specific team more productive and changing them as your team changes.
Small teams are better, but not always possible. Agile is about having team mechanics that make your specific team more productive and changing them as your team changes.
In our experience, scrum teams couldn't scale past 8 members without becoming less effective. The effective communication required for a high performing team suffered, people would tune out in stand-ups etc.
I've done standups (not scrum, just standups) with up to 16 people and it was quite effective. It just required a concerted effort to keep it short.
The nature of the work probably also helped because tasks took a long time so on any given day only a handful of the people would have substantive updates.
The nature of the work probably also helped because tasks took a long time so on any given day only a handful of the people would have substantive updates.
I second that. I've founf that when the work of other people is relevant, you might have some inputs having worked on a related thing earlier that might help them.
> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.
I haven't ever felt this kind of pressure from management in my stand ups. We very rarely have anyone from management present anyway. The stand up exists for the benefit of the team, not management. It is not a status report for management.
I haven't ever felt this kind of pressure from management in my stand ups. We very rarely have anyone from management present anyway. The stand up exists for the benefit of the team, not management. It is not a status report for management.
It is a status report in companies doing "Scrum" - usually after CTO paid an Agile-with-a-capital-A consultant.
I've been a bit of volunteer agile coaching in my area, and yeah, one example that always stuck with me was that the product managers and BAs just got renamed product owners, and they sat in every retro and attended every stand-up.
Funnily enough they were never available to the team during planning. They had important meetings on a Monday...
I tried to empathise to them that "stand-up and retro are solely for the team", but no dice. They still wanted that command and control.
I've been a bit of volunteer agile coaching in my area, and yeah, one example that always stuck with me was that the product managers and BAs just got renamed product owners, and they sat in every retro and attended every stand-up.
Funnily enough they were never available to the team during planning. They had important meetings on a Monday...
I tried to empathise to them that "stand-up and retro are solely for the team", but no dice. They still wanted that command and control.
For some people, the manager-employee relationship is a strictly adversarial one, to the point that they make it a self-fulfilling prophecy by viewing every act of their manager (or employees) as malicious if not a perceived slight.
A lot of HN commenters have a tendency to project what ever experience they have with poor management onto all management in general. Poorly run teams have problems, poorly run projects have problems, poorly designed apps have problems... But well runs teams exist, and they use a lot of the same management tools as the bad ones. I’ve had both great and terrible experiences with standups. In a well run team, I love them. But in a poorly run team, getting frustrated with the idea of standup is about is misguided as getting upset with Jira for your managers shortcomings.
We started just doing our daily "standups" via slack. The whole point (imo) of the meeting is to identify blockers and/or slowdowns for what you're working on, and getting help if necessary. Reporting this status async over slack is great because it fulfills these needs without wasting anyone's time.
If you need help or are block, you report that. Otherwise, no need for a "status update". It also helps that we do this in our eng-only channel, where no product/upper management are in, so only our team is privy to the information.
The one downside is that it can be a bit more difficult to get help on something highly important if everyone is tunnel-visioned. Luckily, we have a great engineering manager who helps orchestrate help in those situations or steps in personally if someone is blocked.
If you need help or are block, you report that. Otherwise, no need for a "status update". It also helps that we do this in our eng-only channel, where no product/upper management are in, so only our team is privy to the information.
The one downside is that it can be a bit more difficult to get help on something highly important if everyone is tunnel-visioned. Luckily, we have a great engineering manager who helps orchestrate help in those situations or steps in personally if someone is blocked.
> What people are working on is usually unrelated and of no interest to each other
If that is the case, then why are you even in the same scrum team? What you have there is not a team by the sounds of it.
If that is the case, then why are you even in the same scrum team? What you have there is not a team by the sounds of it.
> "It's hard to come up with different things to say on the meetings, as there aren't many things that have changed since yesterday."
If you're still working on the same issue, then just say that. Keep the standup short. Of course this can also be a good time to notice a lack of progress; if you're spending days on an issue with little progress, are you stuck? Was the story badly defined? There could be very good reasons why it's taking longer, but again, the standup is a great time to notice these things and check if there's a way to help the issue along.
If you're still working on the same issue, then just say that. Keep the standup short. Of course this can also be a good time to notice a lack of progress; if you're spending days on an issue with little progress, are you stuck? Was the story badly defined? There could be very good reasons why it's taking longer, but again, the standup is a great time to notice these things and check if there's a way to help the issue along.
This just sounds like a bad/inappropriate use of a tool. I wouldn't think that a team of people working on unconnected items should have any meetings at all, let alone a daily stand-up.
As others have said, when you're working on a team where there is significant interplay or varied, related experience, they're really useful. We work on an OS and have members of the team who happen to have experience using infra and tooling. There's no way you would necessarily know this without saying "Oh, I was struggling with this bit of stats collection infra" and somebody else says "Yeah, I worked on that on x project, y years ago. Let's chat after stand-up."
There are obviously other ways to seed this kind of thing, but brief stand-ups seem a good way of doing it.
The other thing that we tend to do is just say "Oh, I did x that doesn't really relate to the project yesterday, but that's not very interesting" and leave it at that.
As others have said, when you're working on a team where there is significant interplay or varied, related experience, they're really useful. We work on an OS and have members of the team who happen to have experience using infra and tooling. There's no way you would necessarily know this without saying "Oh, I was struggling with this bit of stats collection infra" and somebody else says "Yeah, I worked on that on x project, y years ago. Let's chat after stand-up."
There are obviously other ways to seed this kind of thing, but brief stand-ups seem a good way of doing it.
The other thing that we tend to do is just say "Oh, I did x that doesn't really relate to the project yesterday, but that's not very interesting" and leave it at that.
> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.
Spot on. In many companies standup are used to put people on the spot and pressuring them to show progress and so on.
It's amazing how many people on HN don't realize that.
Spot on. In many companies standup are used to put people on the spot and pressuring them to show progress and so on.
It's amazing how many people on HN don't realize that.
> It's hard to come up with different things to say on the meetings, as there aren't many things that have changed since yesterday.
If you can't find something to say for a minute about a day's worth of work then you probably need to be rethinking how you're spending your days.
If you can't find something to say for a minute about a day's worth of work then you probably need to be rethinking how you're spending your days.
> Its an interruption on your work just when you just got started in the morning, now you have to stop and go to a meeting.
> if you need help you ask it anyway on the spot, there is no need to wait for the next standup for that.
I thought part of the reasoning for standups was to synchronize your interruptions, so instead of breaking people's flow throughout the day, you can line up all the cross-cutting concerns at the beginning of the day.
> if you need help you ask it anyway on the spot, there is no need to wait for the next standup for that.
I thought part of the reasoning for standups was to synchronize your interruptions, so instead of breaking people's flow throughout the day, you can line up all the cross-cutting concerns at the beginning of the day.
"What people are working on is usually unrelated and of no interest to each other,"
It sounds like you are not a team in the sense of a coherent body creating added value, but a line organization mandated agglomeration of talent under a specific manager.
When actually working together quick stand ups make sense, but for individual contributors they add very little added value.
However, the only way to know if the dailys are unnecessary or not, is not how they feel like, but what happens when you remove them.
All coordination work feels unproductive. But after a specific complexity is reached coordinated efforts of communication are the only way in which a large body of talent can function in a sensible way together.
It sounds like you are not a team in the sense of a coherent body creating added value, but a line organization mandated agglomeration of talent under a specific manager.
When actually working together quick stand ups make sense, but for individual contributors they add very little added value.
However, the only way to know if the dailys are unnecessary or not, is not how they feel like, but what happens when you remove them.
All coordination work feels unproductive. But after a specific complexity is reached coordinated efforts of communication are the only way in which a large body of talent can function in a sensible way together.
when really working together, standups are superfluous.
I’ve seen standups with 20 people where 2 or 3 talked for more than 10 minutes. That’s not what it’s meant to be.
While I would also like to do the daily status email, I see value in doing a synchronized standup. It helps planning for the day.
Not all people are great communicators and I’ve seen lots of developers spend days on tasks which should take 1 or 2 hours max. Standups highlight these issues, but you need to listen and go to these people in private to understand their problems. And you should absolutely take up people if they offer to help you.
I tend to bring pen and paper to remember what I wanted to say and to note when I here something that’s relevant to me.
While I would also like to do the daily status email, I see value in doing a synchronized standup. It helps planning for the day.
Not all people are great communicators and I’ve seen lots of developers spend days on tasks which should take 1 or 2 hours max. Standups highlight these issues, but you need to listen and go to these people in private to understand their problems. And you should absolutely take up people if they offer to help you.
I tend to bring pen and paper to remember what I wanted to say and to note when I here something that’s relevant to me.
Its highly dependent on personality of course, but Ive also seen this. A person that REALLY likes to talk for 10 minutes about details... which nobody really cares about. He even understood that it was not what anyone else wanted, but he thought "the standup is useless unless I get to say something elaborate and long-winded!"
He could not understand that "I had not trouble yesterday, and today I will keep going on my task" could be a useful update to the team. I mean, in general it isn't but when something unexpexcted happens you are supposed to say it, not something unique for every day. 90% of my dailies are basically: "I am still working on X, and its moving forward, continuing today".
He could not understand that "I had not trouble yesterday, and today I will keep going on my task" could be a useful update to the team. I mean, in general it isn't but when something unexpexcted happens you are supposed to say it, not something unique for every day. 90% of my dailies are basically: "I am still working on X, and its moving forward, continuing today".
> I’ve seen standups with 20 people where 2 or 3 talked for more than 10 minutes.
Did the scrum master not feel able to intercede? Protect the process etc.
Did the scrum master not feel able to intercede? Protect the process etc.
The scrum master shouldn't exist.
I agree, when the team is working, everyone's a scrum master :)
Standups with more than 6 people will already create a meeting of at least an hour. I mean, standups help is small teams to keep everyone excited (if you all agree on it!), and nobody likes meetings, so if it looks like a meeting and people need a 'token' to speak, then the point of the get-together is already far gone.
Why not join the meetup with afterwork drinks? That way you can really say what blocked you ánd talk about the things that you'd do in a standup...
Why not join the meetup with afterwork drinks? That way you can really say what blocked you ánd talk about the things that you'd do in a standup...
> Why not join the meetup with afterwork drinks?
That excludes certain segments of your workforce in ways that make HR sweat. Parents, alcoholics, people of faith... you've made attending the meetup more difficult.
That excludes certain segments of your workforce in ways that make HR sweat. Parents, alcoholics, people of faith... you've made attending the meetup more difficult.
Why not join the meetup with afterwork drinks?
Mandatory after work 'fun' can be highly controversial.
Mandatory after work 'fun' can be highly controversial.
> Standups with more than 6 people will already create a meeting of at least an hour.
Not my experience, teams of that size I’ve been on do standup in 10-15 minutes.
Not my experience, teams of that size I’ve been on do standup in 10-15 minutes.
So the way to fix dysfunctional meetings is not to split them into manageable sizes, but rather shift them into some sort of impromptu unpaid overtime, and bribe your staff with alcohol in hopes that they won't notice?
I commented on another post a while ago that the simplest way to "do Agile right" is to give the developers more power. There's just no other way. Whether that means: ownership, reporting direction, I don't know, but people can feel it, power is power.
I don't mean to imply this is a panacea. "Doing Agile right" is one thing, but business is about more than software development, and an engineering-led organization can of course ignore financial or marketing realities.
But there's an expertise-for-the-job phenom going here. Managing software development is a skill. It requires "navigating ambiguity," that favorite phrase of managers. It requires being able to expect and roll with punches, and chart a new course---every few minutes to every few months, depending on the context.
I suspect the best thing would be for boards to take a more active interest in their company's SD activities. Bring the CTO in, figure out the tech landscape the company is confronting. "Giving devs more power" is probably a no-sell, but "boards taking software seriously" might fly. And when you do that, you unavoidably become the devs who already have power.
I know, a digression, sorry. But it's just night-and-day, the diff between technical and non-technical management.
I don't mean to imply this is a panacea. "Doing Agile right" is one thing, but business is about more than software development, and an engineering-led organization can of course ignore financial or marketing realities.
But there's an expertise-for-the-job phenom going here. Managing software development is a skill. It requires "navigating ambiguity," that favorite phrase of managers. It requires being able to expect and roll with punches, and chart a new course---every few minutes to every few months, depending on the context.
I suspect the best thing would be for boards to take a more active interest in their company's SD activities. Bring the CTO in, figure out the tech landscape the company is confronting. "Giving devs more power" is probably a no-sell, but "boards taking software seriously" might fly. And when you do that, you unavoidably become the devs who already have power.
I know, a digression, sorry. But it's just night-and-day, the diff between technical and non-technical management.
> I even saw once a developer on his last day throwing the speaker's token (a teddy bear) to the trash can LOL!
Are we talking adult employees here? :D Anyway, if I ever become employed, and will have to work on-site, I want the comfort token to be a stuffed baby gnu.
https://shop.fsf.org/gear/stuffed-baby-gnu
Are we talking adult employees here? :D Anyway, if I ever become employed, and will have to work on-site, I want the comfort token to be a stuffed baby gnu.
https://shop.fsf.org/gear/stuffed-baby-gnu
I like that symbolism - it's the optimism of the open source community being soiled, manhandled, and molested all in an effort to please management.
"What people are working on is usually unrelated and of no interest to each other, and if you need help you ask it anyway on the spot, there is no need to wait for the next standup for that."
Exactly this... I couldn't care less what dev-no-3 is working on since its not impacting me and I could bet no one cared much what I said except the scrum-master.
Exactly this... I couldn't care less what dev-no-3 is working on since its not impacting me and I could bet no one cared much what I said except the scrum-master.
I wonder if an end-of day stand-up might have benefits.
A chance to briefly set out any blockers you anticipate for tomorrow/stuff you will need from other people.
But just as important; an end of day marker 'we're done - piss off home now - no working late'.
A chance to briefly set out any blockers you anticipate for tomorrow/stuff you will need from other people.
But just as important; an end of day marker 'we're done - piss off home now - no working late'.
I feel that end of day is more variable than start of day, especially if end of day means "Go Home!". Some people have kids to pick up from school/day care and leave at 3, while others like to come in later and/or take a long lunch and work until 6-7. Saying everybody must be in by 9.30 is probably easier to coordinate that saying everybody must stay until 5 and then go home at 5.15.
I've done both and I personally prefer beginning of day. Standups are usually (in my experience) the beginning of a conversation or a brainstorm and that works better when there is time left to continue after standup. If they are just reporting what you did then end of day might be better, but that sounds like a bad standup.
I worked in a Boston based team from Budapest. I did EOD standups all the time. It was nice I did not have a hard time remembering what I did during a day. I usually had one hour to short out any blockers before I finished working.
There are just as many issues with that as the beginning of the day, IMO. What constitutes the end of the day, for example? It isn't unusual for teams to have someone who comes in really early and leaves early. Or someone else who comes in late and leaves late.
Early enough for the 6-3 worker might be well before the end of the day for a lot of others.
Early enough for the 6-3 worker might be well before the end of the day for a lot of others.
>> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.
So true. At the last company I worked, the daily standups became absurd. We were forced to use a physical board which was always out of synch with GitHub and we were just repeating the same stuff that we already knew everything about.
Also, we had scrum retrospectives in which the new scrum master was throwing a yellow ball at someone when it was their turn to talk. WTF?! Does management think our brains stopped growing after the age of 5? You have a room filled with potentially brilliant engineers and you're treating them like toddlers. Do they seriously think that this is the right way to build a company which will make an impact on society?
What the hell is wrong with managers these days? Is there some kind of virus going around which is turning them into idiots or is there a global conspiracy to only promote idiots into positions of power?
So true. At the last company I worked, the daily standups became absurd. We were forced to use a physical board which was always out of synch with GitHub and we were just repeating the same stuff that we already knew everything about.
Also, we had scrum retrospectives in which the new scrum master was throwing a yellow ball at someone when it was their turn to talk. WTF?! Does management think our brains stopped growing after the age of 5? You have a room filled with potentially brilliant engineers and you're treating them like toddlers. Do they seriously think that this is the right way to build a company which will make an impact on society?
What the hell is wrong with managers these days? Is there some kind of virus going around which is turning them into idiots or is there a global conspiracy to only promote idiots into positions of power?
> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.
When I was a manager, I always found it to be far more effective to have team members apply psychological pressure to their peers, rather than apply pressure from the top down.
Standups are best avoided by managers. I never felt the need for yet another meeting. In fact, an excessive number meetings are one of the main reasons I got out of the management business.
When I was a manager, I always found it to be far more effective to have team members apply psychological pressure to their peers, rather than apply pressure from the top down.
Standups are best avoided by managers. I never felt the need for yet another meeting. In fact, an excessive number meetings are one of the main reasons I got out of the management business.
> Everyone on the teams I worked on seemed to think that standups where useless
It sounds like a bigger a problem then standups; if everyone feels they are useless why is there no forum in which this meeting is being discussed and removed or recalibrated? It sounds like the team doesn't own their own process or doesn't talk to each other about process
It sounds like a bigger a problem then standups; if everyone feels they are useless why is there no forum in which this meeting is being discussed and removed or recalibrated? It sounds like the team doesn't own their own process or doesn't talk to each other about process
[deleted]
Don't agree with this assessment at all, we do stand-ups and it rarely takes more than 5 minutes. It help immensely with production as your colleagues often help keep things from falling through the cracks. (I.e. someone forgets something). Or they might be able to help you out, or further along because they've done something similar. When they do, you don't do it during the stand-up to not disrupt that.
Overal I don't think it's disruptive at all to do a short stand-up, constant nagging however is very disruptive. That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again. If you're working on something complex that can mean it takes an additional 10 minutes before you're back on track. That's the kind of disruption stand-ups can help prevent.
This of course only works if you actually stick to what the stand-up is meant for.
Overal I don't think it's disruptive at all to do a short stand-up, constant nagging however is very disruptive. That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again. If you're working on something complex that can mean it takes an additional 10 minutes before you're back on track. That's the kind of disruption stand-ups can help prevent.
This of course only works if you actually stick to what the stand-up is meant for.
It's a bad article. Standups shouldn't be disruptive at all. Just a couple of minutes to get some idea of what everybody is working on. Standups are in my experience much more effective at signalling blocking issues than slack. Nobody is going to spend their day checking what other people are doing on Jira, so the standup is the perfect time to inform everybody efficiently.
If any issues come up, you can discuss them immediately after the standup.
Long meetings are terrible, but short meetings are great. That's the whole idea behind the standup. If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day. It only has a measurable impact on your velocity if you're only a working an hour per day. And even then I'd guess it's useful to have a quick refresher about what you're working on.
If any issues come up, you can discuss them immediately after the standup.
Long meetings are terrible, but short meetings are great. That's the whole idea behind the standup. If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day. It only has a measurable impact on your velocity if you're only a working an hour per day. And even then I'd guess it's useful to have a quick refresher about what you're working on.
It sounds like you and your coworkers are failing to use your tools, and falling back to having a periodic meeting instead of fixing your process.
>Standups are in my experience much more effective at signalling blocking issues than slack.
Your messaging tool is not good enough to communicate urgency? You cannot send a message and say "this is urgent" and have somebody read it and respond in a timely manner? You would have better luck waiting until the next standup meeting?
>Nobody is going to spend their day checking what other people are doing on Jira
Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?
Here's how it works when you use your tools:
1. You have an urgent issue. You message the involved parties. Your message should communicate the urgency of the issue. They read it and respond / take action within an appropriate amount of time.
2. You want to know what your team is working on. You look at your issue tracker to see what everyone is working on. If you are curious about the status of any work in particular, you look at the details for that work. If there is insufficient information about its progress, you send the assignee a message (see #1).
>Standups are in my experience much more effective at signalling blocking issues than slack.
Your messaging tool is not good enough to communicate urgency? You cannot send a message and say "this is urgent" and have somebody read it and respond in a timely manner? You would have better luck waiting until the next standup meeting?
>Nobody is going to spend their day checking what other people are doing on Jira
Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?
Here's how it works when you use your tools:
1. You have an urgent issue. You message the involved parties. Your message should communicate the urgency of the issue. They read it and respond / take action within an appropriate amount of time.
2. You want to know what your team is working on. You look at your issue tracker to see what everyone is working on. If you are curious about the status of any work in particular, you look at the details for that work. If there is insufficient information about its progress, you send the assignee a message (see #1).
> Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?
In my experience most people don’t regularly post summaries of their progress on their ticket. Even getting certain people to update their ticket descriptions at all (to add test instructions or to reflect that they decided to do something other than originally described) usually requires reminders.
This may depend on team culture but in my experience a lot of people just aren’t written communicators.
In my experience most people don’t regularly post summaries of their progress on their ticket. Even getting certain people to update their ticket descriptions at all (to add test instructions or to reflect that they decided to do something other than originally described) usually requires reminders.
This may depend on team culture but in my experience a lot of people just aren’t written communicators.
We're all professionals - we can learn new skills when they're high-value (like updating tickets with written communication)
I don't like the sentiment that developers doing things out of their comfort zone (like using JIRA) is unreasonable. Just get over it and be a professional.
That said, it's on others to motivate the use of such tools. It's easier to get buy-in when everyone understands the value.
I don't like the sentiment that developers doing things out of their comfort zone (like using JIRA) is unreasonable. Just get over it and be a professional.
That said, it's on others to motivate the use of such tools. It's easier to get buy-in when everyone understands the value.
Or communicators at all. It's like pulling teeth to get some of them to expand on "oh, it's blocked, I have to talk to Bob"
It's not a bad article if it reflects the reality a considerable number of people face with this kind of cargo cult methodology.
A five minute meeting is not five minutes out of your day. Any scheduled interruption takes at least thirty minutes, probably more like sixty, out of productive time, as a flat cost, over and above the actual time of the meeting. It's all the time that you don't start biting into something worth doing because you look at the clock, and say "Oh fuck, I've got this fucking standup meeting in 20 minutes - I can't even get started on this before that rolls around and interrupts me." And it it all the time afterwards where you have had a bunch of shit laid in your lap that you have to spend some time following up on and frigging around with before you can get back to the work you already had planned to do.
A five minute meeting is not five minutes out of your day. Any scheduled interruption takes at least thirty minutes, probably more like sixty, out of productive time, as a flat cost, over and above the actual time of the meeting. It's all the time that you don't start biting into something worth doing because you look at the clock, and say "Oh fuck, I've got this fucking standup meeting in 20 minutes - I can't even get started on this before that rolls around and interrupts me." And it it all the time afterwards where you have had a bunch of shit laid in your lap that you have to spend some time following up on and frigging around with before you can get back to the work you already had planned to do.
You can't put 10 people in a room for a meeting for just a couple of minutes, that does not exist. The time people spend before the meeting not working just chatting around waiting, the natural inertia of the group it takes time to get everyone in a room.
Count the whole overhead time, from the moment people stop working normally waiting for the meeting, till the moment people come back to their seats, add up the extra coffee pause that people take afterwards that people would not usually take.
You are looking on average, at easily 15 to 20 minutes per person minimum a day, probably more.
Count the whole overhead time, from the moment people stop working normally waiting for the meeting, till the moment people come back to their seats, add up the extra coffee pause that people take afterwards that people would not usually take.
You are looking on average, at easily 15 to 20 minutes per person minimum a day, probably more.
Even so, 15 to 20 minutes on a whole day is nothing. It's less than what you lose on coffee or toilet breaks.
20 minutes is a lot of time, add that and at the end of the week you got around 2 hours, that's half a morning per week and close to a whole 8h day of work per month just on the time for standups.
It's not just the time itself though, it's the interruption that prevents you from starting longer tasks effectively.
Can't really account for that, work is not only about summing up minutes on a time tracking tool. There is rythm, there is acceleration, there is a productive state and there is deceleration.
Standups disrupt all that without any real benefit, other than serving as a daily reminder that you better hurry up with what you are doing - which most people don't need.
It's not just the time itself though, it's the interruption that prevents you from starting longer tasks effectively.
Can't really account for that, work is not only about summing up minutes on a time tracking tool. There is rythm, there is acceleration, there is a productive state and there is deceleration.
Standups disrupt all that without any real benefit, other than serving as a daily reminder that you better hurry up with what you are doing - which most people don't need.
20 minutes across my team of 12 is not nothing, it's 4 man hours. When I see it communicated in that manner, the sheer pointlessness of these daily meetings is very easy for me to identify.
Perhaps they shouldn't be disruptive, but in practice they were a daily drain. I'd be happy to never go to one again. Now every day I can come in to the office, can grab a coffee and get to work. Far more relaxing.
I'm curious, why were they draining?
Because you have to think upfront what are you going to say. You might me interrogated in front of everyone else about something that you are doing, and will have to come up with an answer on the spot.
This is obviously stressful, and psychologically pressures you to try to finish the task ASAP the day before, so that you can come up to the meeting and just say its done.
Which is the real actual benefit of the standup, and why managers keep doing it, despite they are obviously not needed and in most cases a waste of time.
The standup keeps everyone on their heels and feeling like their every breath is monitored and accounted for.
This is obviously stressful, and psychologically pressures you to try to finish the task ASAP the day before, so that you can come up to the meeting and just say its done.
Which is the real actual benefit of the standup, and why managers keep doing it, despite they are obviously not needed and in most cases a waste of time.
The standup keeps everyone on their heels and feeling like their every breath is monitored and accounted for.
If you are being interrogated to the extent that you have to plan what you are going to say, the standup is being run poorly IMO.
Everyone has to spend at least some time thinking ahead of time what they are going to say, and you probably do too.
Its the perception of yourself and your work from the eyes of the group that is at stake here, it's important and most people usually don't just improvise it.
Many times people have notes of what they want to say, which involves preparation, attention and energy put into it that would better be directed elsewhere.
Its the perception of yourself and your work from the eyes of the group that is at stake here, it's important and most people usually don't just improvise it.
Many times people have notes of what they want to say, which involves preparation, attention and energy put into it that would better be directed elsewhere.
I don't. Often it's "What was I working on again? Oh yeah, that one issue. And I reviewed some code. The thing I'm working on I hope to finish today, maybe tomorrow. That's it. Oh wait, I also deployed a thing."
It requires very little thought.
It requires very little thought.
I don't know, on a healthy team you should feel very comfortable giving an update on your work without having to prepare.
I've prepared for standup when I was new to a team, but it should pretty quickly get to the point where you don't need that. At least for my experiences, it's not like standup is a major factor in how teammates think of you - that comes from working together with people.
I've prepared for standup when I was new to a team, but it should pretty quickly get to the point where you don't need that. At least for my experiences, it's not like standup is a major factor in how teammates think of you - that comes from working together with people.
> Its the perception of yourself and your work from the eyes of the group that is at stake here
If your teams have so little trust in each other that you have to do all this preparation for a standup, then there are already much larger issues.
If your teams have so little trust in each other that you have to do all this preparation for a standup, then there are already much larger issues.
That's what happens when the PM (or other deadline-obsessed entity) is in charge though.
because they're unnecessary. I legitimately lose an hour a day due to them. I've started coming in late so I slide immediately into the daily standup because otherwise I fart around for the first 30-45 minutes until the standup starts.
There's just no deep work that can be done during that time, and that's every day.
There's just no deep work that can be done during that time, and that's every day.
I agree, that happens and it's really bad. When to hold standup is definitely an important question. I like first thing when people get in or two hours after everyone gets in.
> Standups shouldn't be disruptive at all. Just a couple of minutes to get some idea of what everybody is working on.
That's disruptive!
> Standups are in my experience much more effective at signalling blocking issues than slack.
If you are using Slack, you have already lost the battle for productivity.
> If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day.
Literally any interruption destroys your focus. A pending appointment destroys your focus. If you use Slack or E-Mail notifications, people never even attain focus, so in that sense it's not a loss.
> And even then I'd guess it's useful to have a quick refresher about what you're working on.
To a first approximation, nobody cares what you're working on. Nobody should care what you're working on. If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work.
Daily standups pre-suppose that there's always stuff to communicate and that everyone is always involved, but only once a day and only briefly. This is complete nonsense. You need to be able to adapt to the situation. You need a meeting? Have a meeting with whoever is concerned. Have a follow-up meeting. Take your time and focus on the issue, then nobody will even feel like time is being wasted.
That's disruptive!
> Standups are in my experience much more effective at signalling blocking issues than slack.
If you are using Slack, you have already lost the battle for productivity.
> If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day.
Literally any interruption destroys your focus. A pending appointment destroys your focus. If you use Slack or E-Mail notifications, people never even attain focus, so in that sense it's not a loss.
> And even then I'd guess it's useful to have a quick refresher about what you're working on.
To a first approximation, nobody cares what you're working on. Nobody should care what you're working on. If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work.
Daily standups pre-suppose that there's always stuff to communicate and that everyone is always involved, but only once a day and only briefly. This is complete nonsense. You need to be able to adapt to the situation. You need a meeting? Have a meeting with whoever is concerned. Have a follow-up meeting. Take your time and focus on the issue, then nobody will even feel like time is being wasted.
This sounds like an argument for having a single stand-up meeting instead of communication through slack and email spread throughout the day. It keeps the disruptions concentrated in a single, predictable moment.
> "To a first approximation, nobody cares what you're working on. Nobody should care what you're working on."
I care quite a lot what the people in my team are working on. Otherwise why are we even a team?
If you're not in a team, obviously things are different.
> "If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work."
It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.
> "To a first approximation, nobody cares what you're working on. Nobody should care what you're working on."
I care quite a lot what the people in my team are working on. Otherwise why are we even a team?
If you're not in a team, obviously things are different.
> "If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work."
It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.
> This sounds like an argument for having a single stand-up meeting instead of communication through slack and email spread throughout the day.
It's an argument for having meetings when you need them, with whoever you need them with, with no particular schedule or routine attached.
> I care quite a lot what the people in my team are working on.
Do you really? Or do you just want to signal that?
> Otherwise why are we even a team?
You are on a team because that's the unit of organization above the individual.
> It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.
If developers need to cooperate, you have a problem that you should avoid at great cost. Of course, sometimes cooperation is unavoidable, but it's not a good thing in and of itself. Don't let anyone tell you otherwise. Aim to split up your work to require minimal cooperation. This may sound like unconventional advice, but anyone with enough experience managing developers will likely agree.
It's an argument for having meetings when you need them, with whoever you need them with, with no particular schedule or routine attached.
> I care quite a lot what the people in my team are working on.
Do you really? Or do you just want to signal that?
> Otherwise why are we even a team?
You are on a team because that's the unit of organization above the individual.
> It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.
If developers need to cooperate, you have a problem that you should avoid at great cost. Of course, sometimes cooperation is unavoidable, but it's not a good thing in and of itself. Don't let anyone tell you otherwise. Aim to split up your work to require minimal cooperation. This may sound like unconventional advice, but anyone with enough experience managing developers will likely agree.
This seems overblown. Yes we all get interrupted - lunch, phone calls/texts, even the end of the workday are interruptions. To single out 'standup' as a particularly disruptive interruption may be exaggeration.
Of course, some interruptions like lunch or the end of the day are unavoidable.
Phone calls and texts? Don't let your developers do them.
> To single out 'standup' as a particularly disruptive interruption may be exaggeration.
It isn't an exaggeration, because a standup is also a pending appointment and a mini-presentation. A lot of developer types actually get stressed out about this, no matter how small.
Similar thing with responding to an e-mail. It's insane how much time some people spend on just a one line reply.
Just minimize these things, don't make them part of your routine for routine's sake.
Phone calls and texts? Don't let your developers do them.
> To single out 'standup' as a particularly disruptive interruption may be exaggeration.
It isn't an exaggeration, because a standup is also a pending appointment and a mini-presentation. A lot of developer types actually get stressed out about this, no matter how small.
Similar thing with responding to an e-mail. It's insane how much time some people spend on just a one line reply.
Just minimize these things, don't make them part of your routine for routine's sake.
If my options are a 15 minute standup vs. not being able to respond texts for the entire day, I prefer the standup.
> Don't agree with this assessment at all, we do stand-ups and it rarely takes more than 5 minutes
I do agree with it, because everywhere I've worked that does a daily standup does it wrong, and I think OA is more about those organisations.
For many old-fashioned companies, "doing agile" means waterfall + standups. Apparently that's all you need to reap that sweet agile-y goodness. The guy running the meeting doesn't enforce any structure, doesn't stop people rambling on for 10 minutes, doesn't try in any way to note or act on the points people raise. It's just about micro-management and cargo-cult development.
I'm sure with the right company a standup is a very useful tool. But wherever I've worked, it's been all about micro-management and a fundamental misunderstanding of what I actually need to do dev work (usually: a quiet office, no interruptions and time).
I do agree with it, because everywhere I've worked that does a daily standup does it wrong, and I think OA is more about those organisations.
For many old-fashioned companies, "doing agile" means waterfall + standups. Apparently that's all you need to reap that sweet agile-y goodness. The guy running the meeting doesn't enforce any structure, doesn't stop people rambling on for 10 minutes, doesn't try in any way to note or act on the points people raise. It's just about micro-management and cargo-cult development.
I'm sure with the right company a standup is a very useful tool. But wherever I've worked, it's been all about micro-management and a fundamental misunderstanding of what I actually need to do dev work (usually: a quiet office, no interruptions and time).
it's so true it hurts
You are just counting literally the time the first person starts talking till the last person ends, and even then its going to be closer to 10 minutes.
If you add up the time people have stopped working while waiting for the meeting, the time you take to gather people to a room, wait for the last one to arrive, start, go back, it's been 20 minutes total, and when standups derail and people start talking a lot it goes over half an hour.
You need to count the total overhead time. I mean come on, 10 minutes before the standup you are not really working full steam, right? You know you are about to have a meeting, so you are chatting with colleagues and checking email instead of working on your main tasks. That time should count too.
If you add up the time people have stopped working while waiting for the meeting, the time you take to gather people to a room, wait for the last one to arrive, start, go back, it's been 20 minutes total, and when standups derail and people start talking a lot it goes over half an hour.
You need to count the total overhead time. I mean come on, 10 minutes before the standup you are not really working full steam, right? You know you are about to have a meeting, so you are chatting with colleagues and checking email instead of working on your main tasks. That time should count too.
It's not even about the time, either. I do my best work in the morning. Almost every morning on my last project went like this: Get into work, grab a glass of water, bring up my todo list, start polishing off the first item, make 5 minutes of really good progress and the bam, standup.
The comparison isn't between the benefits of a good standup and nothing, it's between a good standup and whatever productivity you lost by interrupting the entire team (same as any meeting). You need to make sure it's worth it.
The comparison isn't between the benefits of a good standup and nothing, it's between a good standup and whatever productivity you lost by interrupting the entire team (same as any meeting). You need to make sure it's worth it.
> 10 minutes before the standup you are not really working full steam, right?
Some colleagues don't 'work' at all between getting to work and standup (opting for soft tasks like email).
Wasting 15 minutes for 5 people a day costs the company almost 6 man-weeks a year, or really a week per person. Providing that week as PTO/leave would probably result in tangible productivity improvements.
Some colleagues don't 'work' at all between getting to work and standup (opting for soft tasks like email).
Wasting 15 minutes for 5 people a day costs the company almost 6 man-weeks a year, or really a week per person. Providing that week as PTO/leave would probably result in tangible productivity improvements.
What? Every engineering team I've been on has done standups at their office/desk/bullpen. It literally takes exactly the amount of time of talking. Then we sit back down and resume work. You don't have to make it a full blown meeting. In fact, you shouldn't.
Yeah same here. Everywhere I've worked standups have been really beneficial and usually only last about 5 minutes. I think the issue here is maybe the team size and stand ups dragging on for too long?
I've been in teams where standups are short and to the point, and in teams where they drag on for way too long.
A few elements that I think contribute to long standups:
* A very large team (I've been in a marged team of 14 people once...)
* Getting too much into technical details: don't do that; have your technical discussions after the standup with only the relevant people
* People sharing their opinion (frustration) about blocking issues and that developing into a discussion. Again, leave it until after the standup.
When standups drag on for too long, it's time for the scrum master to step in and get people to keep it short.
A few elements that I think contribute to long standups:
* A very large team (I've been in a marged team of 14 people once...)
* Getting too much into technical details: don't do that; have your technical discussions after the standup with only the relevant people
* People sharing their opinion (frustration) about blocking issues and that developing into a discussion. Again, leave it until after the standup.
When standups drag on for too long, it's time for the scrum master to step in and get people to keep it short.
> * People sharing their opinion (frustration) about blocking issues
IMHO that would be okay, if not beneficial.
>and that developing into a discussion.
That not so much.
IMHO that would be okay, if not beneficial.
>and that developing into a discussion.
That not so much.
Agreed. Keep them short and focused. We use ours to review new PRs for the day and new requests that have come in from other parts of the company, in addition to covering blockers.
The PRs cover the “what did you do?” questions while getting eyeballs reviewing the work and for larger PRs we will schedule something. Keeps things moving well.
The inbound requests reviews keep us from having to have backlog estimating meetings as often since we are keeping up with it as they arrive.
If the time isn’t useful, find a way to make it useful.
The PRs cover the “what did you do?” questions while getting eyeballs reviewing the work and for larger PRs we will schedule something. Keeps things moving well.
The inbound requests reviews keep us from having to have backlog estimating meetings as often since we are keeping up with it as they arrive.
If the time isn’t useful, find a way to make it useful.
> That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again.
Walks in? Yes. That should be discouraged always.
Spamming on Slack? If that is a problem, you're doing Slack wrong. It's an asynchronous method of communication. Don't be buried in it or feel the need to respond to every message as it comes in. Check it during natural breaks or stopping points.
If something actually is urgent and requires your immediate attention, then they can break the above rule and walk up to your desk (or call you if you're remote).
Walks in? Yes. That should be discouraged always.
Spamming on Slack? If that is a problem, you're doing Slack wrong. It's an asynchronous method of communication. Don't be buried in it or feel the need to respond to every message as it comes in. Check it during natural breaks or stopping points.
If something actually is urgent and requires your immediate attention, then they can break the above rule and walk up to your desk (or call you if you're remote).
Some of my colleagues had a hard time with this. They would actually ask me to come to their desk whenever I had a question, and come to mine when I didn't answer fast enough (only after I had gotten them to understand I really preferred slack. Seems they never got the why though, despite making it very clear...)
Yep, there are some people who just don't get it, and it's hard to get them to. I find that most developers have a hard time even bringing up the issue with someone face-to-face, even though all it usually takes is: "Hey, just wanted to let you know, I really prefer having these sorts of exchanges over Slack. Otherwise I find it really disruptive to my day. Could we give that a try next time and see how it works out?" And you have to be willing to escalate if the behavior doesn't improve: "Listen, I asked if we could take care of these things over Slack, and I'd really appreciate it if you could accommodate me here." Then: "Hey, I know I keep bringing this up, but it's really important to me. I need to keep a lot of my day interruption-free in order to be productive. Please try harder to respect my time when coming to me for help."
It seems most developers aren't even comfortable with the first bit, let alone escalating things. Instead, most people just seethe and complain privately to other colleagues, and nothing changes. At the very least, the team's manager should be brought in to do a better job of protecting the everyone's time, and you'd think that would be easy for a developer to do, because it outsources any sort of confrontation. But it still often doesn't happen, for whatever reason. (Of course, if it's the manager who is the offender here, you're probably screwed if the diplomatic method fails.)
It seems most developers aren't even comfortable with the first bit, let alone escalating things. Instead, most people just seethe and complain privately to other colleagues, and nothing changes. At the very least, the team's manager should be brought in to do a better job of protecting the everyone's time, and you'd think that would be easy for a developer to do, because it outsources any sort of confrontation. But it still often doesn't happen, for whatever reason. (Of course, if it's the manager who is the offender here, you're probably screwed if the diplomatic method fails.)
> This of course only works if you actually stick to what the stand-up is meant for.
This is my big problem with agile, scrum, and friends. It's like communism; it only works if you "do it correctly." Russia? China? Cuba? Yea, they didn't do it right, but if it's done right, it's really really great.
I have only ever read about agile and scrum being done correctly. Obviously, I'm just one person, and my experience is limited, but at every company have I ever worked at or consulted for, the practice of agile and scrum is very different than what I read about.
I have experienced the less than 10 minute standup maybe a dozen times ever. Not that there is usually much to talk about. "Yesterday I worked on on X. Today I will keep working on X."
But somehow enough people in one place just seems to create so much friction. There's always a tangent. A: "By the way, how long do you think until we finish X?" B: "I don't know. Kind of depends on Y and Z. I never did Y before." C: "Oh, I did Y before, it's easy, you'll have no difficulties" and on and on.
I can see two possibilities:
1) My experiences have been not been representative of the industry as a whole. On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.
2) My experiences are representative. In this case, agile/scrum is so difficult for the average company to pull off, that it's kind of a rare occurrence.
The fact that angst-ridden articles like this one are such a regular occurrence on HN kind of makes me suspect that it's #2, not #1.
I'm just an engineer, so project management is not my area of expertise, but my layman's opinion is that an actually good project management system should "fail gracefully," as it were. You shouldn't need a 1 in 1000 level PM to pull this stuff off.
This is my big problem with agile, scrum, and friends. It's like communism; it only works if you "do it correctly." Russia? China? Cuba? Yea, they didn't do it right, but if it's done right, it's really really great.
I have only ever read about agile and scrum being done correctly. Obviously, I'm just one person, and my experience is limited, but at every company have I ever worked at or consulted for, the practice of agile and scrum is very different than what I read about.
I have experienced the less than 10 minute standup maybe a dozen times ever. Not that there is usually much to talk about. "Yesterday I worked on on X. Today I will keep working on X."
But somehow enough people in one place just seems to create so much friction. There's always a tangent. A: "By the way, how long do you think until we finish X?" B: "I don't know. Kind of depends on Y and Z. I never did Y before." C: "Oh, I did Y before, it's easy, you'll have no difficulties" and on and on.
I can see two possibilities:
1) My experiences have been not been representative of the industry as a whole. On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.
2) My experiences are representative. In this case, agile/scrum is so difficult for the average company to pull off, that it's kind of a rare occurrence.
The fact that angst-ridden articles like this one are such a regular occurrence on HN kind of makes me suspect that it's #2, not #1.
I'm just an engineer, so project management is not my area of expertise, but my layman's opinion is that an actually good project management system should "fail gracefully," as it were. You shouldn't need a 1 in 1000 level PM to pull this stuff off.
> On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.
Not a chance -- your experience mirrors mine over the course of the six or so companies that I've worked for. It's definitely #2.
They all fail in very similar ways: story points become hours/days; stand-ups devolve from status updates to daily team discussions; the backlog becomes irrelevant because new stories are created for each sprint; and, in companies which report velocity to senior management, story-point inflation.
Also, I've noticed that Agile transformations always create Agile zealots within the organization which seem to act to quell dissent. I'm not sure why this is, maybe the transformations are tied to bonuses or something, but it's a universal thing. There's always somebody running around telling you that you're team is Doing It Wrong when you bring up any legitimate criticisms of the process.
See:
> It's like communism; it only works if you "do it correctly."
Not a chance -- your experience mirrors mine over the course of the six or so companies that I've worked for. It's definitely #2.
They all fail in very similar ways: story points become hours/days; stand-ups devolve from status updates to daily team discussions; the backlog becomes irrelevant because new stories are created for each sprint; and, in companies which report velocity to senior management, story-point inflation.
Also, I've noticed that Agile transformations always create Agile zealots within the organization which seem to act to quell dissent. I'm not sure why this is, maybe the transformations are tied to bonuses or something, but it's a universal thing. There's always somebody running around telling you that you're team is Doing It Wrong when you bring up any legitimate criticisms of the process.
See:
> It's like communism; it only works if you "do it correctly."
“It help immensely with production as your colleagues often help keep things from falling through the cracks.”
But your job as a developer is to not have this happen. It’s nothing something that would be a nice to have, you’re supposed to always keep your team informed about potential gaps. The standup is designed to catch gaps but really that should be something you should already be doing.
But your job as a developer is to not have this happen. It’s nothing something that would be a nice to have, you’re supposed to always keep your team informed about potential gaps. The standup is designed to catch gaps but really that should be something you should already be doing.
Daily standups are often a panopticon for those who mine story points and their wardens that micro manage them. Anyone not coding (RE, BA, managers of any kind) usually don't need to justify their contributions to the team. It fits extremely well in the story point driven "agile" world where working on stuff that does not provide immediate business value, like code quality and technical debt, is highly discouraged.
I have seen so many dysfunctional standup cultures: Places where you had to showcase and exaggerate how much stuff you had to do and people were looking at you funnily when you said what you are doing in under a minute, places where discussion that only interested a third of the team were started and standups took half an hour, places where the managers interrupted and asked why stories took so long...
I have seen so many dysfunctional standup cultures: Places where you had to showcase and exaggerate how much stuff you had to do and people were looking at you funnily when you said what you are doing in under a minute, places where discussion that only interested a third of the team were started and standups took half an hour, places where the managers interrupted and asked why stories took so long...
I’ve worked at two of the FAANGs, and some of my teams had daily stand ups and some didn’t. Some teams had stand ups but didn’t track points or velocity of any kind. Others did.
When we were working to disambiguate deliverables or working on design or implementation, stand ups were useful. They held everyone accountable, when folks weren’t making progress because of some issue, it was super obvious - it gave management a really good insight into where things are and what blockers are.
Your characterization certainly doesn’t represent my experience. We went through phases of launching a products or services and focusing on them and then going back to pay off some of the tech debt until product management, engineers, and leadership arrived on the next set of big features.
When we were working to disambiguate deliverables or working on design or implementation, stand ups were useful. They held everyone accountable, when folks weren’t making progress because of some issue, it was super obvious - it gave management a really good insight into where things are and what blockers are.
Your characterization certainly doesn’t represent my experience. We went through phases of launching a products or services and focusing on them and then going back to pay off some of the tech debt until product management, engineers, and leadership arrived on the next set of big features.
> panopticon
"The panopticon is a type of institutional building and a system of control designed by the English philosopher Jeremy Bentham in the 18th century...[It] allows all prisoners of an institution to be observed by a single security guard, without the inmates being able to tell whether they are being watched."
Learned a new word and concept today. Thanks!
"The panopticon is a type of institutional building and a system of control designed by the English philosopher Jeremy Bentham in the 18th century...[It] allows all prisoners of an institution to be observed by a single security guard, without the inmates being able to tell whether they are being watched."
Learned a new word and concept today. Thanks!
Standups hurt more than help. As someone who managed fully remote teams in the past, what worked very well for us is a set of rules around in-house built task management system (something like Jira could work too).
1) Aim to take 2-3 tasks, do not take more, take 1 if the task is large, but usually, it's a sign of an overblown story.
2) Every day at the end of the day, write a "current status" comment. These comments are visible in the master panel, and I could take action the next day to help developers resolve roadblocks, if the resolution is taking longer, they can work on other tasks they claimed.
This effectively eliminated the need for standups, the whole team could sync using task "current status" updates, and chime in with help or advice. I was able to see the progress and issues without forcing people into a mess of a video call, and everybody could still stick to their preferred schedules and have personal lives.
1) Aim to take 2-3 tasks, do not take more, take 1 if the task is large, but usually, it's a sign of an overblown story.
2) Every day at the end of the day, write a "current status" comment. These comments are visible in the master panel, and I could take action the next day to help developers resolve roadblocks, if the resolution is taking longer, they can work on other tasks they claimed.
This effectively eliminated the need for standups, the whole team could sync using task "current status" updates, and chime in with help or advice. I was able to see the progress and issues without forcing people into a mess of a video call, and everybody could still stick to their preferred schedules and have personal lives.
This is my preferred method as well when leading a team.
Standups as intended are too brief to discuss the important details. This is why they end up ballooning to 30+ minutes at most companies, because anything shorter is of little value.
They also end up as a catch-all meeting for any topics that require the team's input; I dislike this because people are expected to provide input on the spot without really making any thoughtful considerations. If we want to have a discussion on a UI component, that should be done in a dedicated, prepared meeting, not at 8:30 in the morning when people are unprepared and said developer can take advantage of unpreparedness to obtain the consensus they want.
When I provide up-stream status reports, I like to have the developer's notes in front of me for a quick refresher. Plus, they serve as a good reminder on topics that need followup.
Standups as intended are too brief to discuss the important details. This is why they end up ballooning to 30+ minutes at most companies, because anything shorter is of little value.
They also end up as a catch-all meeting for any topics that require the team's input; I dislike this because people are expected to provide input on the spot without really making any thoughtful considerations. If we want to have a discussion on a UI component, that should be done in a dedicated, prepared meeting, not at 8:30 in the morning when people are unprepared and said developer can take advantage of unpreparedness to obtain the consensus they want.
When I provide up-stream status reports, I like to have the developer's notes in front of me for a quick refresher. Plus, they serve as a good reminder on topics that need followup.
Ours take 10 minutes, we use them to update people on how our work item is going (e.g. if smth is taking longer than expected) and specifically to give a sense of citizenship and culture. Otherwise we might as well remote in from various corners of the globe in shadowy rooms and talk using voice modulators. Sure, not everyone works like that but I personally like to put names to faces and gain a sense of personality behind the names in a git blame.
If you don't value those things then just be low key in your input, its literally 10 minutes of your day and has the potential to present an avoidable issue. To discard it as "management trash" is IMO a massive amount of disrespect toward your fellow team members. They can help and the stand-up opens opportunities for help. There's design work, review work, product management work, scheduling, triage, retrospectives. There's ample opportunities for efficiency gains in these areas during a stand-up outside of just writing code. If you think your job is just writing code then I can see how you might think they're useless but nobody's job is, we all work in teams.
If you don't value those things then just be low key in your input, its literally 10 minutes of your day and has the potential to present an avoidable issue. To discard it as "management trash" is IMO a massive amount of disrespect toward your fellow team members. They can help and the stand-up opens opportunities for help. There's design work, review work, product management work, scheduling, triage, retrospectives. There's ample opportunities for efficiency gains in these areas during a stand-up outside of just writing code. If you think your job is just writing code then I can see how you might think they're useless but nobody's job is, we all work in teams.
> its literally 10 minutes
Even if the meeting itself was instant it would take more than 10 minutes. You would have to stop whatever you're working on, even if you're in the middle of a valuable flow state. Then after the meeting you have to get back into whatever it was, which alone can take you more than 10 minutes depending on the depth of your work.
If that's not bad enough then what you talked about in the meeting can also linger. You'll think of problems others have had and it causes your mind to lose focus, now you have thoughts about your problem mixed with other problems. These meetings also tend to happen during the mornings, smack in the middle of the most productive hours of the day.
No, a daily standup takes much more time than 10 minutes.
Even if the meeting itself was instant it would take more than 10 minutes. You would have to stop whatever you're working on, even if you're in the middle of a valuable flow state. Then after the meeting you have to get back into whatever it was, which alone can take you more than 10 minutes depending on the depth of your work.
If that's not bad enough then what you talked about in the meeting can also linger. You'll think of problems others have had and it causes your mind to lose focus, now you have thoughts about your problem mixed with other problems. These meetings also tend to happen during the mornings, smack in the middle of the most productive hours of the day.
No, a daily standup takes much more time than 10 minutes.
Your job is more than just code. Your job is other people too. Live in a box all you like but you're completely discounting the value of ensuring other members of the team know what's going on with you over your current work item.
FWIW, imagine how a greenhorn might feel working on a team with you. If you feel like giving them some time of your day is a waste or that listening to their problems is a waste they're not going to feel enthused working on your team. Sure, that doesn't necessarily influence your current work item but it might contribute to overwork later if they leave for a team that actually makes them feel like they matter.
FWIW, imagine how a greenhorn might feel working on a team with you. If you feel like giving them some time of your day is a waste or that listening to their problems is a waste they're not going to feel enthused working on your team. Sure, that doesn't necessarily influence your current work item but it might contribute to overwork later if they leave for a team that actually makes them feel like they matter.
There's a big leap between never interacting with other people and my claim that standups in fact takes longer than 10 minutes.
Breaking my state of flow is also something I don’t like about stand ups. And yes, they tend to be in the morning when I have my most productive hours.
One solution I found is to write a quick status in the chat and excuse myself from the stand up.
Sometimes I finish 20 minutes before the stand up and think about what to do next. I usually won’t go into deep work but plan something, write my todo list on paper or review some PR to make use of the amount of time that’s to small to get into flow.
One solution I found is to write a quick status in the chat and excuse myself from the stand up.
Sometimes I finish 20 minutes before the stand up and think about what to do next. I usually won’t go into deep work but plan something, write my todo list on paper or review some PR to make use of the amount of time that’s to small to get into flow.
You should be able to figure out a good daily time for your team that doesn't involve breaking out of the middle of a flow state. Maybe when everyone is expected to be in the office, or even right after lunch?
The risk is always there. Say you schedule it at 8 in the morning? Then you might interrupt the people who come in earlier. Schedule it before or after lunch? Unfortunately people eat lunch at different times too. Schedule it at the end of the day? Then the daily standup loses it's effectiveness (while you risk interrupting people who flow later in the day).
There is never such a time, if you allow any kind of flexibility or self-direction in scheduling. Moreover, if you are customer-driven, you will wind up with having calls here, there, and everywhere, that some subset of your people will be on that clash with any potential standup time.
> its literally 10 minutes
Literally, it's not 10 minutes. Count the time that you have stopped working and people are chatting waiting for the meeting, checking their email when they would not otherwise do so, not working on their main tasks.
20 minutes to half an hour of time not usable for main tasks is a more typical estimate.
Literally, it's not 10 minutes. Count the time that you have stopped working and people are chatting waiting for the meeting, checking their email when they would not otherwise do so, not working on their main tasks.
20 minutes to half an hour of time not usable for main tasks is a more typical estimate.
Mine is timed and its ten minutes and that's with me stretching out a little. If we were determined to make it small it could be five.
We have six people in the stand-up.
If you're so sad about being interrupted then maybe you're taking on too much work?
We have six people in the stand-up.
If you're so sad about being interrupted then maybe you're taking on too much work?
Well, the act of timing changes everything. it will affect the total duration as people will deliberately hurry up.
That is actually a good idea, but it's the first time I heard about it. In most companies, this is not done. Also, it's not just the literal time of the meeting.
It's the time people spend waiting for the meeting, chatting, reading email instead of working on their main task for the day.
It's about the interruption cost and the disruption of what you were doing, not about the literal cost in minutes.
Also, most developers don't have a saying in how much work is assigned to them. Usually, they are over assigned already and the cost of the standup is not accounted for in how long tasks should take.
Add all standups of a week, and you have half a morning of work per week down the drain. That's a lot and again that is literal total time only, and does not account for interruption cost.
That is actually a good idea, but it's the first time I heard about it. In most companies, this is not done. Also, it's not just the literal time of the meeting.
It's the time people spend waiting for the meeting, chatting, reading email instead of working on their main task for the day.
It's about the interruption cost and the disruption of what you were doing, not about the literal cost in minutes.
Also, most developers don't have a saying in how much work is assigned to them. Usually, they are over assigned already and the cost of the standup is not accounted for in how long tasks should take.
Add all standups of a week, and you have half a morning of work per week down the drain. That's a lot and again that is literal total time only, and does not account for interruption cost.
If work are assigned to devs, then you are not doing agile anyway. It's supposed to be a pull system of tasks
Daily Standups do make sense to some.
In an ideal world everyone would be perfectly professional and not need any supervision at all. In the real world some times you might be in a rough period or have some other problem that makes concentrating hard. In an ideal world the thought of getting a paycheck would be enough motivation. Sometimes it isn't.
A daily standup, if done well and short, helps one to focus on what's important, sets the tone for the day, and unites the team as a tribe.
When one is not motivated enough by looking a big fat dashboard with tickets pending, or the though of getting another paycheck at the end of the period, one can be motivated by the thought of not failing to their tribe, their peers, their coworkers.
You gave them your word, face to face, that you would work on something, so you better do, they are your people.
In an ideal world everyone would be perfectly professional and not need any supervision at all. In the real world some times you might be in a rough period or have some other problem that makes concentrating hard. In an ideal world the thought of getting a paycheck would be enough motivation. Sometimes it isn't.
A daily standup, if done well and short, helps one to focus on what's important, sets the tone for the day, and unites the team as a tribe.
When one is not motivated enough by looking a big fat dashboard with tickets pending, or the though of getting another paycheck at the end of the period, one can be motivated by the thought of not failing to their tribe, their peers, their coworkers.
You gave them your word, face to face, that you would work on something, so you better do, they are your people.
> A daily standup, if done well and short
That's the rub, though. Despite best intentions, sometimes things just go off into the weeds. It happens more often than I'd like, and it's happened on every team I've ever been on, at every company I've ever worked at. Sure, you can say, "well you're doing it wrong", but that's not helpful. Process should support how the team works, not define how the team works.
> helps one to focus on what's important
If you need to refocus someone every day, you've made a bad hire.
> sets the tone for the day
That's my job. I know what I'm supposed to be working on, and set my own tone.
> and unites the team as a tribe
Ugh, gross. We're not a "tribe", "family", whatever.
We're a team of co-workers working on a variety of tasks, who are not children and can be trusted to communicate adequately with the rest of the team, and honor our commitments. If you have someone on the team for whom that's not the case, again: you made a bad hire. Don't punish the rest of the team because you have someone who can't do their job.
I get that some people get off track sometimes. It happens, even to the most senior of people. The solution to that is called management. Regular 1:1s, making sure your team keeps their tickets updated, and getting regular (individual, asynchronous, as-needed) status updates. If someone is having an off day, or an off week, that should be addressed individually, not by preemptively assuming the worst of everyone on the team and instituting a daily standup.
That's the rub, though. Despite best intentions, sometimes things just go off into the weeds. It happens more often than I'd like, and it's happened on every team I've ever been on, at every company I've ever worked at. Sure, you can say, "well you're doing it wrong", but that's not helpful. Process should support how the team works, not define how the team works.
> helps one to focus on what's important
If you need to refocus someone every day, you've made a bad hire.
> sets the tone for the day
That's my job. I know what I'm supposed to be working on, and set my own tone.
> and unites the team as a tribe
Ugh, gross. We're not a "tribe", "family", whatever.
We're a team of co-workers working on a variety of tasks, who are not children and can be trusted to communicate adequately with the rest of the team, and honor our commitments. If you have someone on the team for whom that's not the case, again: you made a bad hire. Don't punish the rest of the team because you have someone who can't do their job.
I get that some people get off track sometimes. It happens, even to the most senior of people. The solution to that is called management. Regular 1:1s, making sure your team keeps their tickets updated, and getting regular (individual, asynchronous, as-needed) status updates. If someone is having an off day, or an off week, that should be addressed individually, not by preemptively assuming the worst of everyone on the team and instituting a daily standup.
> Despite best intentions, sometimes things just go off into the weeds.
True. Happens in every meeting. In which case anyone present can (and in my view) should get the meeting back on track.
“This is off topic”, “can you/we discuss this later”, “this has nothing to do with why we’re here for”.
Having strict time limits, a clear intent, and of course people enforcing it does make it possible.
>> and unites the team as a tribe > Ugh, gross. We're not a "tribe", "family", whatever.
Agreed. This stuff makes me gag.
True. Happens in every meeting. In which case anyone present can (and in my view) should get the meeting back on track.
“This is off topic”, “can you/we discuss this later”, “this has nothing to do with why we’re here for”.
Having strict time limits, a clear intent, and of course people enforcing it does make it possible.
>> and unites the team as a tribe > Ugh, gross. We're not a "tribe", "family", whatever.
Agreed. This stuff makes me gag.
> In which case anyone present can (and in my view) should get the meeting back on track.
I absolutely agree that people can and should do that, but in practice, I often find that people don't. And I personally get tired of it; isn't it reasonable to take a dim view of a meeting where literally every time we have it, I (as an IC, whose job this should not be) have to prod people to stay on track?
I absolutely agree that people can and should do that, but in practice, I often find that people don't. And I personally get tired of it; isn't it reasonable to take a dim view of a meeting where literally every time we have it, I (as an IC, whose job this should not be) have to prod people to stay on track?
> > and unites the team as a tribe
> Ugh, gross. We're not a "tribe", "family", whatever.
To each his or her own
> Ugh, gross. We're not a "tribe", "family", whatever.
To each his or her own
True, I suppose. But I think you'd be hard pressed to find even a plurality of developers who'd embrace the whole "my team at work is my tribe" thing. Perhaps it's motivating for some, but I would guess that for the majority of developers it would be an active turn-off, or at the very least neutral and not helpful.
And, at it's face, it's simply false. Companies (and the teams within) are factually not families, or tribes, or anything of the sort. They are a group of people working together for economic gain. They share very little resemblance to families or tribes in real life, and I can't see making that comparison as anything but a plea for loyalty... loyalty that will never be returned by the company when it's not convenient.
If I were interviewing at a company and they tried to justify having a standup using this rationale, I would stop considering them, as would many (most?) developers I know.
And, at it's face, it's simply false. Companies (and the teams within) are factually not families, or tribes, or anything of the sort. They are a group of people working together for economic gain. They share very little resemblance to families or tribes in real life, and I can't see making that comparison as anything but a plea for loyalty... loyalty that will never be returned by the company when it's not convenient.
If I were interviewing at a company and they tried to justify having a standup using this rationale, I would stop considering them, as would many (most?) developers I know.
This is closely related to one's self-assessment and the question of being right and doing right thing.
If one is right, stand up do not matter. If one is wrong, they help greatly.
You say : why should I suffer for unprofessional and weak team member who is wrong?
But you forget to note that the same person could be right sometimes and doing great things and be utterly wrong and solving wrong problems some other times.
Edit: a also wanted to add, that input from peers and peer pressure is not to be underestimated. Management is be wrong as often as any of us.
If one is right, stand up do not matter. If one is wrong, they help greatly.
You say : why should I suffer for unprofessional and weak team member who is wrong?
But you forget to note that the same person could be right sometimes and doing great things and be utterly wrong and solving wrong problems some other times.
Edit: a also wanted to add, that input from peers and peer pressure is not to be underestimated. Management is be wrong as often as any of us.
> But you forget to note that the same person could be right sometimes and doing great things and be utterly wrong and solving wrong problems some other times.
No, I don't forget that, and in fact specifically addressed people having an off day, week, whatever.
No, I don't forget that, and in fact specifically addressed people having an off day, week, whatever.
[deleted]
> In an ideal world the thought of getting a paycheck would be enough motivation.
We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
> > In an ideal world the thought of getting a paycheck would be enough motivation.
> We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
I agree with you. It was mostly to curtail the capitalist view of "a paycheck should be motivation enough."
> We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
I agree with you. It was mostly to curtail the capitalist view of "a paycheck should be motivation enough."
I think what you're against are the sync daily standups, not the async, usually written, ones.
If I was an employee, I would prefer you to let me self-manage my work however I feel comfortable using whatever tool suits me and my team, instead of constantly interrupting on Jira, Trello, etc. And I'll keep you updated at a frequency we agreed on (daily or weekly).
It's also great to read daily updates of others on the team, and even other teams, to learn about what they're working on without having to check at multiple places or interrupt their work. It's usually a great way to discuss, give and receive feedback, asynchronously.
Also, it's strange that you're suggesting "reach out on Slack" as an alternative. Doesn't that promote the "incessant messaging that Slack allows" you're decrying at the start of the article?
Disclaimer: I'm cofounder of the team communication tool https://www.happierco.com
If I was an employee, I would prefer you to let me self-manage my work however I feel comfortable using whatever tool suits me and my team, instead of constantly interrupting on Jira, Trello, etc. And I'll keep you updated at a frequency we agreed on (daily or weekly).
It's also great to read daily updates of others on the team, and even other teams, to learn about what they're working on without having to check at multiple places or interrupt their work. It's usually a great way to discuss, give and receive feedback, asynchronously.
Also, it's strange that you're suggesting "reach out on Slack" as an alternative. Doesn't that promote the "incessant messaging that Slack allows" you're decrying at the start of the article?
Disclaimer: I'm cofounder of the team communication tool https://www.happierco.com
That’s my biggest gripe with stand ups. Management has as much if not more access to all the project management tools the developers do, so if they need a daily standup they should be able to get a sense of what’s going on simply by correctly using the tool.
I've had daily standup calls spanning multiple time zones (US, India, UK) with 30+ people in which take an hour.
I've had in-person standups which regularly turn into design meetings between two people, which everyone else has to listen to for half an hour.
I've had 5 minute 9:30am daily standups which always start between 5 and 20 minutes late, thus are significantly disruptive. Arrive at 9, get a drink, try to pick up where I left off yesterday, oh it's time for the standup. Not yet? OK, where was I? Oh now? But Dan is on the phone? Alright, in 5 mins? ...First hour of the day down the toilet.
I've had standups where people are told off for trying to communicate any sort of useful information - so people just list the people they need to talk to that day.
And of course in a small company there might only be 8 developers, often working on 4 totally separate things for different clients, but there has to be a standup with everyone just because management can't figure out how to use Jira properly.
I've had enough of standups. I've switched to working afternoons only for my current client so I can avoid the bloody things.
I've had in-person standups which regularly turn into design meetings between two people, which everyone else has to listen to for half an hour.
I've had 5 minute 9:30am daily standups which always start between 5 and 20 minutes late, thus are significantly disruptive. Arrive at 9, get a drink, try to pick up where I left off yesterday, oh it's time for the standup. Not yet? OK, where was I? Oh now? But Dan is on the phone? Alright, in 5 mins? ...First hour of the day down the toilet.
I've had standups where people are told off for trying to communicate any sort of useful information - so people just list the people they need to talk to that day.
And of course in a small company there might only be 8 developers, often working on 4 totally separate things for different clients, but there has to be a standup with everyone just because management can't figure out how to use Jira properly.
I've had enough of standups. I've switched to working afternoons only for my current client so I can avoid the bloody things.
How about we just stop generalising across each others projects, teams and environments?
This stuff is always highly context dependent and the ongoing efforts of everyone to pretend it isn't makes it extremely difficult to have adult conversations on the topic.
This stuff is always highly context dependent and the ongoing efforts of everyone to pretend it isn't makes it extremely difficult to have adult conversations on the topic.
The use of unnecessary daily standups is an industry-wide practice that few teams escape, and it's important to talk about their general unusefulness and hidden costs.
It has been proposed originally as an agile "let's do what makes sense for each case" practice, and as quickly been adopted by companies as a common micromanagement practice.
Yes its context-dependent, but at the same time, its something so pervasive that most developers can relate to it and have or will experience it one way or the other.
It has been proposed originally as an agile "let's do what makes sense for each case" practice, and as quickly been adopted by companies as a common micromanagement practice.
Yes its context-dependent, but at the same time, its something so pervasive that most developers can relate to it and have or will experience it one way or the other.
For me, "agile" has always been about constantly trying new ways of doing things, keeping the ones that work and culling the ones that don't, fast. It's a process that changes as your team changes, as your goals change, and never works the same for two different teams.
It amazes me that people can come along and unironically decry some process as outright bad or pointless
> context dependent
Exactly. If you work for a financial company where a manager has to check every analysis, then of course you need such meetings. I don't think efficient people spend all their time reading about how to be efficient.
Exactly. If you work for a financial company where a manager has to check every analysis, then of course you need such meetings. I don't think efficient people spend all their time reading about how to be efficient.
“This stuff is always highly context dependent”
Well I think standups, on average across all possible developer contexts, are useless.
To put another way, standups are likely to be useless regardless of context.
Well I think standups, on average across all possible developer contexts, are useless.
To put another way, standups are likely to be useless regardless of context.
Completely agree with this. It just seems like ritual for ritual's sake. I tend to learn nothing from standup that I couldn't learn by checking Jira or just directly asking someone. And waiting a full day to raise blockers is foolish.
Sometimes things go a bit too far, with people delving too deeply into whatever topic, with a sort of side-conversation starting. Yes, these people should "take it offline", and often after a minute or so of back and forth, they will, but it still happens often enough that it turns into a waste of most of the team's time. "Be more disciplined!", you say? Sure, ok, wave your magic wand and make that happen, please.
The counter-argument I usually hear to anyone who wants to get rid of standup goes something along the lines of: "but it's great to get everyone together once a day, and sometimes people will spontaneously learn of something that they have useful input for, and save someone some time". Ok, so you want to waste 10-20 minutes of my time on the off chance that someone might randomly have a useful contribution that wouldn't otherwise come up? No, pass.
And regardless, this sort of attitude is actively hostile toward remote members of the team, who may be in different time zones and can't reasonably participate.
If your team really needs daily status updates, create a "standup" channel for your team on Slack (or whatever you use), and have people do a once-a-day post in there. No deadline, just when they get to it. But even that just feels like micro-management.
Sometimes things go a bit too far, with people delving too deeply into whatever topic, with a sort of side-conversation starting. Yes, these people should "take it offline", and often after a minute or so of back and forth, they will, but it still happens often enough that it turns into a waste of most of the team's time. "Be more disciplined!", you say? Sure, ok, wave your magic wand and make that happen, please.
The counter-argument I usually hear to anyone who wants to get rid of standup goes something along the lines of: "but it's great to get everyone together once a day, and sometimes people will spontaneously learn of something that they have useful input for, and save someone some time". Ok, so you want to waste 10-20 minutes of my time on the off chance that someone might randomly have a useful contribution that wouldn't otherwise come up? No, pass.
And regardless, this sort of attitude is actively hostile toward remote members of the team, who may be in different time zones and can't reasonably participate.
If your team really needs daily status updates, create a "standup" channel for your team on Slack (or whatever you use), and have people do a once-a-day post in there. No deadline, just when they get to it. But even that just feels like micro-management.
> waiting a full day to raise blockers is foolish
that does not make sense. Just because you have a short sync meeting once a day, it does mean should should delay all work until then.
that does not make sense. Just because you have a short sync meeting once a day, it does mean should should delay all work until then.
I'm having trouble parsing the last half of your sentence, but I'm going to assume (please correct me if I'm wrong here) that you meant:
"Just because you have a short sync meeting once a day, it doesn't mean you should delay all work until then."
And yes, I totally agree! If you're blocked on something, you should raise it immediately, so you're not delaying all work until your next standup! If you do have other work to do, you should still raise the issue immediately, figure out who should own the blocker (if it's non-trivial, your manager will likely find ownership for you), and then move onto another task until the blocker is resolved. You gain nothing by waiting until the next day, and possibly exacerbate the problem if you do wait.
"Just because you have a short sync meeting once a day, it doesn't mean you should delay all work until then."
And yes, I totally agree! If you're blocked on something, you should raise it immediately, so you're not delaying all work until your next standup! If you do have other work to do, you should still raise the issue immediately, figure out who should own the blocker (if it's non-trivial, your manager will likely find ownership for you), and then move onto another task until the blocker is resolved. You gain nothing by waiting until the next day, and possibly exacerbate the problem if you do wait.
I like standups. They keep me updated on what's happening in the code base, and give us the opportunity to discuss what's going to happen next. The repo is vast and we're gown adults that don't need to be micro-managed because story A or B is taking too long.
The problem doesn't come from standups, but rather from dysfunctional startup culture.
The problem doesn't come from standups, but rather from dysfunctional startup culture.
I have a similar experience. Standups keep me at least vaguely informed on what other people are doing, provide an opportunity to take the pressure off poor souls buried under a new influx of tasks, and are perhaps some light team building (such as the canned joke that a burndown chart isn't supposed to look even remotely like that, or something in the lines of "help me, those goddamn morons from $OVERSEAS_BRANCH at it again"). 10 minutes tops, and back to work.
If I were to compile a list of workspace annoyances, even the most pointless standup would be way after serious business like "people standing behind my back while talking to someone".
If I were to compile a list of workspace annoyances, even the most pointless standup would be way after serious business like "people standing behind my back while talking to someone".
What information does a standup monologue convey that couldn't be expressed more clearly and with persistent links to context than a comment on a Trello card?
My team don't do daily standups. They're pointless ceremony.
Yesterday I worked on… Yes we know. We can see the Trello card you worked on.
Today I am working on… Yes we know. We can see what you've currently assigned yourself on Trello.
I am blocked by… Why the hell are you waiting until now to bring this up?!
My team don't do daily standups. They're pointless ceremony.
Yesterday I worked on… Yes we know. We can see the Trello card you worked on.
Today I am working on… Yes we know. We can see what you've currently assigned yourself on Trello.
I am blocked by… Why the hell are you waiting until now to bring this up?!
I am blocked by… Why the hell are you waiting until now to bring this up?!
...because, as the author of the article notes, developers don't like interruptions.
You can't have it both ways - either you can have distraction-free work time so issues like blockers have to wait until the next scheduled communication time or you get distractions when important things happen. You can't reasonably state that people shouldn't interrupt you and they shouldn't wait until the next meeting to tell you stuff. Those things are opposed to each other.
...because, as the author of the article notes, developers don't like interruptions.
You can't have it both ways - either you can have distraction-free work time so issues like blockers have to wait until the next scheduled communication time or you get distractions when important things happen. You can't reasonably state that people shouldn't interrupt you and they shouldn't wait until the next meeting to tell you stuff. Those things are opposed to each other.
> You can't reasonably state that people shouldn't interrupt you and they shouldn't wait until the next meeting to tell you stuff
You absolutely can, and we do it all the time.
You didn't interrupt me by replying to my comment here. If I was busy working on something, I wouldn't have read/replied to this right now.
If I am working on something, it's highly likely that I'll be finished and take a break to check what else is happening in the team well before a morning meeting the following day.
If something is truly time-critical and deserving of interruption, then its a moot point.
You absolutely can, and we do it all the time.
You didn't interrupt me by replying to my comment here. If I was busy working on something, I wouldn't have read/replied to this right now.
If I am working on something, it's highly likely that I'll be finished and take a break to check what else is happening in the team well before a morning meeting the following day.
If something is truly time-critical and deserving of interruption, then its a moot point.
For me to interrupt you has a lower cost than for me to be stuck all day. But we need to fix something if it happens to me every day, or I can't figure out who to interrupt without affecting every member of the team.
The hubris of the software profession never ceases to amaze me. You have thousand-word screeds about the injustice of being required to attend a daily 15 minute meeting to catch up with your teammates, while being paid six figure salaries. I suggest getting a job in food service, or even construction if you want to see how the average laborer works. Tech is the softest industry ever created.
oh this one. "X isn't as bad as Y (where Y is worse) therefore X is OK, deal with it"
X and Y are completely unconnected and X is still bad and should be fixed.
Imagine if you went to the doctor with a fractured ankle and they said "well, it's not as bad as this baby I saw last week who was dying of sepsis. I suggest you count your blessings and deal with it"
And 6-figure salaries ? choose the value from the tail of the distribution to support your argument why don't you
X and Y are completely unconnected and X is still bad and should be fixed.
Imagine if you went to the doctor with a fractured ankle and they said "well, it's not as bad as this baby I saw last week who was dying of sepsis. I suggest you count your blessings and deal with it"
And 6-figure salaries ? choose the value from the tail of the distribution to support your argument why don't you
Or, you could view this as being a developer addressing an inefficiency in a process. I, for one, view that as a positive trait for someone in this profession.
I’m not nuts about standups, Slack or the multitude of distractions dressed up as productivity tools, but I understand their value as a means for helping distributed teams feel some sense of camaraderie, even if that’s not the original intent.
I’m not nuts about standups, Slack or the multitude of distractions dressed up as productivity tools, but I understand their value as a means for helping distributed teams feel some sense of camaraderie, even if that’s not the original intent.
“while being paid six figure salaries.“
And that’s still not enough! Think of the value we return to an organization, and we’re only paid six figures.
Ya know, you’re allowed to fight for the absolute best working conditions as a worker.
You’re perspective reeks of some sort of corporate shill. Like I should just be happy to even have a job however shitty the working conditions. That perspective keeps developers underpaid and stressed out.
And that’s still not enough! Think of the value we return to an organization, and we’re only paid six figures.
Ya know, you’re allowed to fight for the absolute best working conditions as a worker.
You’re perspective reeks of some sort of corporate shill. Like I should just be happy to even have a job however shitty the working conditions. That perspective keeps developers underpaid and stressed out.
As a well paid developer I'm very thankful to be in tech (I kinda just fell into it). IMO, being a developer doesn't require the intensive training of a doctor or lawyer yet pays really well (especially when you have 10-20 years experience). Personally I learned all I know on the job or on my own at home (my undergrad degree was Math and I did very little coding). Plus there are so many job options. Almost every company of a certain size needs software developers (or some type of IT staff). I've worked at companies where I had to work really hard with long hours, but I've also worked places with a very light workload (lots of screwing around time on HNs and Reddit). My son is adept at math and computers. I hope he goes the Computer Science route. He should be able to find a good job and live where he wants.
I have to wonder, did you really read the post? Your characterization of it as a "screed about the injustice" of standups seems wholly contradictory to the tone of the post. It literally opens with "your standups are killing your velocity." Correct or incorrect, it's an appeal to efficiency. I would hope that streamlining processes would be welcome in all industries including food service and construction.
I guess I fundamentally don't understand the nature of your argument; your reasoning essentially prohibits anyone daring to voice concerns about prevailing practices, because it could always be worse?
I guess I fundamentally don't understand the nature of your argument; your reasoning essentially prohibits anyone daring to voice concerns about prevailing practices, because it could always be worse?
> Tech is the softest industry ever created.
I am pretty sure that this is the tech people who created this industry and all the jobs evolving around. Softwares are generating a lot of revenue but are incredibly used too.
I am pretty sure that this is the tech people who created this industry and all the jobs evolving around. Softwares are generating a lot of revenue but are incredibly used too.
I've long been sceptical of the three questions – well intentioned no doubt but way too prone to becoming an unhealthy exercise in individual self-justification. Much prefer to review the work "right to left", starting with work just completed, then work we can get over the line, then the bulk of what's in progress, and (if there's capacity), what's in the immediate pipeline. Now it's about what _we_ can do to finish the most important of what's in front of us.
They're called standups for a reason: you're supposed to do them standing up so that people whine if they go over five minutes. That tracks out to 25 minutes or less than one-eightieth of your week.
Except if you're already deep into work because you start earlier than everyone else then they just rip you out of your flow.
They also tend to be longer than five minutes in terms of herding people to them etc.
They also tend to be longer than five minutes in terms of herding people to them etc.
The deep flow disturbance can be caused by any sort of communication. So basically, that’s an argument against communication, as opposed to being an argument against standups.
If anything, by being at a fixed time, either at the start, or the end of a team’s day, it’s far easier to prevent a standup from disrupting deep work than a Slack message would be.
If anything, by being at a fixed time, either at the start, or the end of a team’s day, it’s far easier to prevent a standup from disrupting deep work than a Slack message would be.
You know it will disrupt you so you never even start the deep work. Victory!
Except async communication doesn't disrupt deep flow if done properly since it should be simply ignored until flow breaks or pauses naturally.
A slack message won't disrupt my deep work because I'll have notifications turned off, unless it's extremely urgent in which case it would be too urgent to leave until a standup anyway.
A slack message won't disrupt my deep work because I'll have notifications turned off, unless it's extremely urgent in which case it would be too urgent to leave until a standup anyway.
If they are at the same time every day, surely you can plan your work around that?
I work at a standing desk, as do many of my colleagues, so that doesn't really apply to everyone.
I have never been on a team of any more than 3 people where the standups have been as short as 5 minutes.
I have never been on a team of any more than 3 people where the standups have been as short as 5 minutes.
This is just not realistic, a standup of 7 or eight people will take minimum 15 to 20 minutes, from the moment that you leave your desk to the moment you get back.
Some standups go off track, and if you count everything you are looking at close to a third of a morning per week or so.
Some standups go off track, and if you count everything you are looking at close to a third of a morning per week or so.
I've had teams bigger than that with a fixed 10 minute slot for standups, where the next team would have their standup after those 10 minutes. It was not a problem, but it enforced meeting discipline.
As for going off track, you will need to learn to tell people (including yourself) to take a time out and discuss matters after the standup. If anyone says more than a sentence or two, and if there is more than a single counterquestion and a short answer, then that should be taken after the meeting.
As for going off track, you will need to learn to tell people (including yourself) to take a time out and discuss matters after the standup. If anyone says more than a sentence or two, and if there is more than a single counterquestion and a short answer, then that should be taken after the meeting.
Obviously this is just my experience, but in my office of 13 (11 devs, 2 managers) our stand ups take 5-7 minutes (on exceptionally rare circumstances it’ll take 10 or 12, but that’s normally due to large production issues).
They are useful for knowledge spreading and understanding what everyone is working on - we switch projects quite regularly so it’s quite nice to have a birds eye view of where each project is.
They are useful for knowledge spreading and understanding what everyone is working on - we switch projects quite regularly so it’s quite nice to have a birds eye view of where each project is.
It's an illusion, most people don't have a good sense of time. Just getting everyone in a room and waiting for the last person to arrive and everyone to leave, grab a cofee and start working again is at least 12 to 15 minutes for that amount of people.
Next time you have a standup, look at the clock once you get up to the standup, or that you stop working normally and start looking around to see when people are leaving to the meeting. And then look at the clock when you are back at your seat working again.
People start getting ready to the standup 5 to 10 minutes before, chatting while waiting, etc. Count the time that you have stopped working normally, where you can't do any large task because you know there is a meeting in 10 minutes.
Don't just count the time literally from the moment a person starts giving their status to when the last person finishes, as the real overhead of the meeting is not that.
I guarantee you if you do that systematically and count the complete overhead and not just the literal overhead, that at best it will be typically 15 minutes and for longer sessions half an hour.
Next time you have a standup, look at the clock once you get up to the standup, or that you stop working normally and start looking around to see when people are leaving to the meeting. And then look at the clock when you are back at your seat working again.
People start getting ready to the standup 5 to 10 minutes before, chatting while waiting, etc. Count the time that you have stopped working normally, where you can't do any large task because you know there is a meeting in 10 minutes.
Don't just count the time literally from the moment a person starts giving their status to when the last person finishes, as the real overhead of the meeting is not that.
I guarantee you if you do that systematically and count the complete overhead and not just the literal overhead, that at best it will be typically 15 minutes and for longer sessions half an hour.
Daily standups while being mostly useless on the surface, have an implicit value of enforcing a daily face to face communication between team members who work remotely. In remote teams I often find that people who don't interact face to face frequently, but work on the same part of the system, are more likely to run into communication problems down the road - doing duplicate work, passive aggressive attitudes in PR reviews, poor communication in general which impacts the system in a very direct and negative way.
Here's a thing -- people rarely become friends over email or slack conversations, unfortunately. And a team of friendly people who trust each other and communicate efficiently (e.g. feel absolutely comfortable setting up a quick video conferencing call to talk about an issue) is a lot more valuable than a team of people who rarely talk to each other and mostly prefer texting over anything else.
Those are my findings when working with remote teams only. I don't think standups are necessary for colocated teams, which can sync at will anytime they want.
Here's a thing -- people rarely become friends over email or slack conversations, unfortunately. And a team of friendly people who trust each other and communicate efficiently (e.g. feel absolutely comfortable setting up a quick video conferencing call to talk about an issue) is a lot more valuable than a team of people who rarely talk to each other and mostly prefer texting over anything else.
Those are my findings when working with remote teams only. I don't think standups are necessary for colocated teams, which can sync at will anytime they want.
Exactly. I have some remote folks on my team, and folks rotate in and out of being remote on a daily basis. So we do that, but I renamed it to "daily status" since we are not standing up and no one is. We conduct it all 100% over the computer, so those remote don't feel left out. We keep it on track and for us we do it right after around lunch. So people have things they have worked on for the day and things they need to do after. Doing it in the beginning of the day forces everyone to come early defeating flexible time. Doing it at end is the same, and if you're blocked it's silly to wait till the end of the day to tell the team. It's just another tool in the box, if it works for your team great. if it doesn't, shed it. Attitude can determine how useful things are.
Well, I see the point of a senior: with enough practice you should not need rituals of this kind anymore.
Some seniors don't even need a kanban board on a fast moving project, they just know what needs to be done now to create value at lowest cost, they just feel it.
It's not like when you're junior, you've never done any standup and you don't know when you've been blocked long enough to switch task or ask for support, you've never done any poker planning if you're techie, or value estimations if you're product / sales, you've never prioritized by complexity / value score if you're manager - or equivalent.
For this reason, I think there's still value in such rituals when there are non seniors in a team.
However, I prefer text-chat based standups myself and feel like they produce the same value and cost less time.
Some seniors don't even need a kanban board on a fast moving project, they just know what needs to be done now to create value at lowest cost, they just feel it.
It's not like when you're junior, you've never done any standup and you don't know when you've been blocked long enough to switch task or ask for support, you've never done any poker planning if you're techie, or value estimations if you're product / sales, you've never prioritized by complexity / value score if you're manager - or equivalent.
For this reason, I think there's still value in such rituals when there are non seniors in a team.
However, I prefer text-chat based standups myself and feel like they produce the same value and cost less time.
Some seniors don't even need a kanban board on a fast moving project, they just know what needs to be done now to create value at lowest cost, they just feel it.
These are always the worst people to work with, because they think they know much more than they do.
Frankly the most difficult parts of effective engineering are nothing to do with software and all to do with good team communications.
These are always the worst people to work with, because they think they know much more than they do.
Frankly the most difficult parts of effective engineering are nothing to do with software and all to do with good team communications.
I'm sure sure we're talking about the same things: not communicating daily is obviously going to be a problem, such as not giving the team a chance to change your priorities.
But a senior knows basic needs for a product to live on like stable production, continuous integrations, unit/functional tests, code reviews, continuous deployment, infra & application monitoring, alerting, backups, service & dependency versions upgrades, fix regressions introduced by new features, with test ... and all sorts of quick wins for the product that come out of a casual discussion with a product / sales person etc ... The kind of usual things that becomes a daily routine and may just take the day to the point where you couldn't move any new feature card in the kanban anyway.
Is it necessary to create a kanban ticket every time they do a package update, fix an impediment or do something in 0day ? It can surely be useful, not sure if it's more useful than just reporting on a text based chat, can it be harmful by polluting the kanban with tickets that don't create any obvious value (tech debt treatment) ? as long as communication goes through it's fine with me unless someone wants to build a report at the end of the month (ie. billing), I believe the practice matters more than the tool.
But I'm more trying to understand the point of this article, searching for conditions that would validate it, rather than defend it in all case.
For me daily communication and the three questions are important (but I prefer async / text based, and even twice a day: when I check-in and check-out), for the rest it depends, I can understand why some seniors would feel like blindly applying procedures may seem un-necessary or harmful sometimes, like they say : it's the dose that makes a cure or a poison.
But a senior knows basic needs for a product to live on like stable production, continuous integrations, unit/functional tests, code reviews, continuous deployment, infra & application monitoring, alerting, backups, service & dependency versions upgrades, fix regressions introduced by new features, with test ... and all sorts of quick wins for the product that come out of a casual discussion with a product / sales person etc ... The kind of usual things that becomes a daily routine and may just take the day to the point where you couldn't move any new feature card in the kanban anyway.
Is it necessary to create a kanban ticket every time they do a package update, fix an impediment or do something in 0day ? It can surely be useful, not sure if it's more useful than just reporting on a text based chat, can it be harmful by polluting the kanban with tickets that don't create any obvious value (tech debt treatment) ? as long as communication goes through it's fine with me unless someone wants to build a report at the end of the month (ie. billing), I believe the practice matters more than the tool.
But I'm more trying to understand the point of this article, searching for conditions that would validate it, rather than defend it in all case.
For me daily communication and the three questions are important (but I prefer async / text based, and even twice a day: when I check-in and check-out), for the rest it depends, I can understand why some seniors would feel like blindly applying procedures may seem un-necessary or harmful sometimes, like they say : it's the dose that makes a cure or a poison.
Was just about to comment on this myself. As one of two new devs on a team I am very glad that the seniors of our team has chosen to start having standups again (which they didn't before). It is great for us new guys to get a quick look in at what everyone is working on and they get a natural way of seeing if we are a bit stuck with our "new guys tasks".
But I can also very much see us abandoning it once we are more up to speed with the others. Or maybe we just keep them extreamly short as I've seen some other suggest here.
But I can also very much see us abandoning it once we are more up to speed with the others. Or maybe we just keep them extreamly short as I've seen some other suggest here.
Very interesting point. When you have senior guys that know the important things work then the importance of process, beyond some key staging points, diminishes. From a business and strategic planning perspective could this be some kind of a risk? There's the old "hit by a bus" (or just quits) trope of course, which is related to the "single point of failure" systems analogy. Then there's the management ideology of control, which can be subverted when individuals are on the critical path for projects. I also wonder how this jives with change management: If you have guys mired in the details around whom changes pivot, what happens when there's significant changes e.g. in personal life of these guys, or organisationally, or migrations to new architectures etc. I also wonder how putting individuals at the centre of a business jives with external compliance requirements such as ISO and GDPR ...
EDIT also recalling personal experience: What about growth, where you want to grow the business and bring new (senior or otherwise) team members in, but everything is vested in the idiosyncracies of a few individuals?
EDIT also recalling personal experience: What about growth, where you want to grow the business and bring new (senior or otherwise) team members in, but everything is vested in the idiosyncracies of a few individuals?
I agree that processes are going to be necessary to scale. My comment focused more on the conditions that seemed to make the article relevant: a small team making a new project that's not really in production (fast moving) and apparently with only seniors who don't need even a voice-based standup ritual.
sorry, this is one of those instances where I should have read the fine article before posting
The questions as presented strike me as something that is more suited in a 1-on-1:
> What did I work on yesterday? > What am I working on today? > What issues are blocking me?
At my job we have tickets on a physical board and we discuss them from right-to-left. There are magnets on the tickets with people's names on it and when you get to 'your' tickets you talk about what is happening with that ticket. This is a lot more concrete and relevant to the rest of the team.
At a previous company we went from person to person and they'd discuss what they were working on. This always struck me as a strictly personal accounting of their previous work day and I had a feeling that people felt like they had to boast or exaggerate what they were working on. It never felt relevant or interesting.
> What did I work on yesterday? > What am I working on today? > What issues are blocking me?
At my job we have tickets on a physical board and we discuss them from right-to-left. There are magnets on the tickets with people's names on it and when you get to 'your' tickets you talk about what is happening with that ticket. This is a lot more concrete and relevant to the rest of the team.
At a previous company we went from person to person and they'd discuss what they were working on. This always struck me as a strictly personal accounting of their previous work day and I had a feeling that people felt like they had to boast or exaggerate what they were working on. It never felt relevant or interesting.
In my limited experience, one key to successful standups is making them as small as possible. The worst standups are the ones which contain over a dozen people working on a bunch of only vaguely related projects. The best ones are the ones that only involve the people working on things directly related to thing I happen to be working on. I you're a manager this might mean that you have to organize 3 or 4 standups instead of just one and keep track of who is working on what and being sure the right people show up to the right meeting. If it turns out that someone is being blocked by someone not at the meeting then either set up a new meeting with just the people involved in that problem or make sure that particular person is at the next meeting.
> I've had this feeling that the industry likes to treat development teams like a bunch of idiot teenagers.
The infantilisation of developers seems to be common in larger organisations. It's extremely tiring.
The infantilisation of developers seems to be common in larger organisations. It's extremely tiring.
The infantilisation of all workers seems to be common.
The stupidity of terms like "tribes" and "squads", the endless gamification, the "open office to encourage communication", the discussion of "learnings" and other verbed nouns.
The only people that it suits are HR types that love that everyone can be seen to be working together and the management that save lots of money on real estate and infrastructure costs.
Sure, breaking down company silos is a Good Thing. Orienting people to work across disciplines and be focused on the customer is a Good Thing.
Inventing crap like standups (the Queen does them for Privy Council meetings, works for her), and titles like "scrum master" is just as bad as the "black belt 6 sigma" of the early 2000s and the other management fads.
The stupidity of terms like "tribes" and "squads", the endless gamification, the "open office to encourage communication", the discussion of "learnings" and other verbed nouns.
The only people that it suits are HR types that love that everyone can be seen to be working together and the management that save lots of money on real estate and infrastructure costs.
Sure, breaking down company silos is a Good Thing. Orienting people to work across disciplines and be focused on the customer is a Good Thing.
Inventing crap like standups (the Queen does them for Privy Council meetings, works for her), and titles like "scrum master" is just as bad as the "black belt 6 sigma" of the early 2000s and the other management fads.
I work in a fully remote team and our daily standups are one of the highlights of the day as we get some actual "face to face" time rather than just the usual Slack chat. I think it's probably a bit reductionist to use a headline like "Standups are pointless" rather than just "I've personally not found them helpful".
For me daily scrum meetings were valuable when the team remains small and work on related stuff in a fast pace.
But for the last few years, it has not been the case for me. Standups have been organized for managers and scrum masters so that they attend only 1 meeting and participants were not working on directly related topics. Most did not care about what others were doing and issues they faced. We reduced them to bi-weekly or 3 times a week and re-focused them on synchronization topics...
Also my general feeling (maybe because I am an old developer) is that it is infantilizing, and a way to maintain peer pressure.
But for the last few years, it has not been the case for me. Standups have been organized for managers and scrum masters so that they attend only 1 meeting and participants were not working on directly related topics. Most did not care about what others were doing and issues they faced. We reduced them to bi-weekly or 3 times a week and re-focused them on synchronization topics...
Also my general feeling (maybe because I am an old developer) is that it is infantilizing, and a way to maintain peer pressure.
>> Okay so, basically, the only unique point to standups is that they "keep everyone excited"?
Skipping right past the part about "flag team blockers" in what they just quoted. I don't much care for the other nonsense, but sometimes I'm stuck on a problem, and I'll keep working on it if no one else knows, but it's nice to just broadcast where I'm at and see who thinks they have helpful insight. That happens a lot in my stand ups.
Skipping right past the part about "flag team blockers" in what they just quoted. I don't much care for the other nonsense, but sometimes I'm stuck on a problem, and I'll keep working on it if no one else knows, but it's nice to just broadcast where I'm at and see who thinks they have helpful insight. That happens a lot in my stand ups.
Do you not have async channels for this? I've never thought to myself, "Well, shit, guess I'll keep banging my head against this problem until I can get some help in tomorrow's standup." I have a hard time taking that seriously.
That too, but do you find that everyone in the team eventually reads everything on the async channel?
I tend to, as a team lead, yes. There's also @ mentions in things like Slack or regular old email to get people's attention.
"As a team lead, yes";
1 goal of scrum is to allow the team to function, to avoid having a single point of quarterbacking, and messages going up and down a chain of command.
Moreover, from a psychology perspective, the act of reaching out for help require significant humility and is often delayed.
As a lead, I've found it useful to be able to ask questions about updates, and, demonstrate "quarterbacking" by delegating myself or other to pair or split work off. Sometimes it's to ensure that there is better shared knowledge gained, sometimes it's to better parallelize work.
1 goal of scrum is to allow the team to function, to avoid having a single point of quarterbacking, and messages going up and down a chain of command.
Moreover, from a psychology perspective, the act of reaching out for help require significant humility and is often delayed.
As a lead, I've found it useful to be able to ask questions about updates, and, demonstrate "quarterbacking" by delegating myself or other to pair or split work off. Sometimes it's to ensure that there is better shared knowledge gained, sometimes it's to better parallelize work.
Working remotely, the daily standups are the only times in the day where we meet up face to face in a video call.
Not only that but it's a time where we feel safe to say that we are struggling on something and ask for help to everyone at once: this often leads to someone in the team (not necessarily the manager) suggesting a pair-programming session to move forward more quickly.
Another thing is that we have several products developed independently but with shared libraries. The standup is the moment where we suggest appropriate usages of the shared libraries depending on what our teammates are working on. This increases code re-use and makes us faster.
In addition, we have what we call "Sharing time" at the end of our standups, which is a time dedicated to sharing anything we care about, mostly non work related. It's actually cool to see what our colleagues are up to outside work (one colleague is into model planes and 3D printing, another is currently traveling across Portugal, etc, etc). Very interesting stuff !
Our daily standup is kind of like the coffee break in a traditional office.
Not only that but it's a time where we feel safe to say that we are struggling on something and ask for help to everyone at once: this often leads to someone in the team (not necessarily the manager) suggesting a pair-programming session to move forward more quickly.
Another thing is that we have several products developed independently but with shared libraries. The standup is the moment where we suggest appropriate usages of the shared libraries depending on what our teammates are working on. This increases code re-use and makes us faster.
In addition, we have what we call "Sharing time" at the end of our standups, which is a time dedicated to sharing anything we care about, mostly non work related. It's actually cool to see what our colleagues are up to outside work (one colleague is into model planes and 3D printing, another is currently traveling across Portugal, etc, etc). Very interesting stuff !
Our daily standup is kind of like the coffee break in a traditional office.
This type of article has far too broad a brush. It's like saying don't play 4-4-2 in football (soccer) because we just won a trophy using 3-5-1-1 so 4-4-2 killed your team's chances of success. It's so small minded it's incredible.
As a manager or as a team, you need to determine what will work best for your team and you will need to adapt.
As a manager or as a team, you need to determine what will work best for your team and you will need to adapt.
This is absurd to me. Standups are quick and it is helpful to know what everyone is working on. And they can serve as a time when you are up front about being stuck on something and get some help from a teammate when maybe otherwise you might have just kept tinkering or hammering away in your own world. It’s just a little nudge to share your status and keep everyone on the same page. It prevents wondering what your colleague is typing up a storm about which is a natural human curiosity.
And the author says make it async, I agree! That’s not against the spirit of standups, I’ve worked on remote teams with an asynchronous standup slack channel.
The most common problem I’ve seen with standups is they can become more than status updates and end up a time during the day to brag about your accomplishments or justify your status within a team/project. Usually to keep management happy or angle for an agenda other than keeping the team together.
And the author says make it async, I agree! That’s not against the spirit of standups, I’ve worked on remote teams with an asynchronous standup slack channel.
The most common problem I’ve seen with standups is they can become more than status updates and end up a time during the day to brag about your accomplishments or justify your status within a team/project. Usually to keep management happy or angle for an agenda other than keeping the team together.
Yes, distractions are not great - but communicating with your team is important. Even if the manager is not there the team does it and they do it usually < 5 minutes. Some days I literally don't talk to my team except for that 5 minutes.
But as a leader you want to make sure the team is rowing the same direction - it doesn't matter if it takes you longer on a ticket but it also helps in a team to know what others are working on in case you end up working on it later yourself. (We discussed at standup to implement it X way because of Y factors).
Many engineers (myself included) don't like asking others for help. But guess what when someone says they are stuck - it is easy to point them to a person or direction and not waste time debugging a problem already solved in the past.
If they were so horrible and unproductive, managers (who mostly were engineers in the past would get rid of them).
But as a leader you want to make sure the team is rowing the same direction - it doesn't matter if it takes you longer on a ticket but it also helps in a team to know what others are working on in case you end up working on it later yourself. (We discussed at standup to implement it X way because of Y factors).
Many engineers (myself included) don't like asking others for help. But guess what when someone says they are stuck - it is easy to point them to a person or direction and not waste time debugging a problem already solved in the past.
If they were so horrible and unproductive, managers (who mostly were engineers in the past would get rid of them).
Yes, daily detailed standups are not useful. BUT, since development teams tend to be slightly to very introverted, it helps ease 'department wide' communication and 'solutioning' that wouldn't happen otherwise. The underlying goal is to help personality types that often don't like to communicate outside of a small group, and often don't like to ask for help, and in some cases helps the few developers who 'cannot see the forest for the trees' that focus on trivialties when they need to look past them. Edit: It also helps product or leadership types who may not be well versed in technology.
This is where I've seen value. Building comraderie/comfort within the team, where otherwise devs might not talk to each other. Provides a sandbox for brainstorming/reviewing strategies ("Oh did you try this framework/class" or "oh I wrote the same code in X service 4 months ago, go take a look) and making sure everyone is on the same page about what is going in the next cloud release.
I will say that only 2/3 times a week is the best bang for your buck, and often switching to "Slack-up" instead of "stand-up", when people are busy with other things or can't be bothered.
I will say that only 2/3 times a week is the best bang for your buck, and often switching to "Slack-up" instead of "stand-up", when people are busy with other things or can't be bothered.
Move the daily to just before noon: it does not stop you during work and people tend to keep it short because they're hungry. And you can have people coming in late in the morning and not be a problem.
They're a good way to handle people who don't communicate well: if it looks like a junior is blocked on something and does not like to ask for help another dev can easily propose a pair-coding session.
But you need to only have devs or former devs so you don't get the feeling you get judged because your "what have I done last day" is "mainly nothing, this ticket is not exciting so I'm going slow".
They're a good way to handle people who don't communicate well: if it looks like a junior is blocked on something and does not like to ask for help another dev can easily propose a pair-coding session.
But you need to only have devs or former devs so you don't get the feeling you get judged because your "what have I done last day" is "mainly nothing, this ticket is not exciting so I'm going slow".
I can't agree more.
I've never done standups in the teams I managed.
But I chuckled a lot when seeing other teams/companies destroying the morale of their employees with this childish and borderline cult-like parade.
But I chuckled a lot when seeing other teams/companies destroying the morale of their employees with this childish and borderline cult-like parade.
I've taken over management of a few scrum teams now, and in every case, I've also had to take over standups. One team had somebody who used a time tracker and showed me that the average length of standups before I arrived was something like 37 minutes. Another team, standup was run by the PM and they reviewed EVERY story in the sprint, triaged all new bugs, talked about new features and, worse, pressured developers who were falling behind at EVERY standup.
Given how badly many standups are run, I completely understand why most developers hate them.
Given how badly many standups are run, I completely understand why most developers hate them.
I am a consultant working in a distributed team, often remote from our client. I find the standup format to be very useful, often delivered via a daily email.
While we use a formal issue tracker like Jira which handles approvals and estimates, from a project management perspective it's useful to have a summary email that is short enough for people to read and focused on business level issues.
"Today I worked on this" / "Next I plan to work on that." This helps clients to see exactly what we are working on. It avoids miscommunication where we think they told us to prioritize something different, or they thought they told us to stop work on something, or they think we are finished with something and we are not. Having an email every day lets them tell us to stop work immediately if we are doing the wrong thing, avoiding surprise invoices the next month. It avoids them claiming that they didn't know that we were working on something.
"Here are the problems I am having / things I need from you". This is very useful to keep track of delays caused by the client. This might be them needing to review and accept work, review specs, or pay their invoices. Issues stay on the report until they are resolved. It documents that we didn't get what we needed, so we can't be blamed for things being late.
While we use a formal issue tracker like Jira which handles approvals and estimates, from a project management perspective it's useful to have a summary email that is short enough for people to read and focused on business level issues.
"Today I worked on this" / "Next I plan to work on that." This helps clients to see exactly what we are working on. It avoids miscommunication where we think they told us to prioritize something different, or they thought they told us to stop work on something, or they think we are finished with something and we are not. Having an email every day lets them tell us to stop work immediately if we are doing the wrong thing, avoiding surprise invoices the next month. It avoids them claiming that they didn't know that we were working on something.
"Here are the problems I am having / things I need from you". This is very useful to keep track of delays caused by the client. This might be them needing to review and accept work, review specs, or pay their invoices. Issues stay on the report until they are resolved. It documents that we didn't get what we needed, so we can't be blamed for things being late.
> Jira, Trello, Asana, the stickies on your wall, or reach out on Slack
In a nutshell, the article claims that these electronic tools render a daily standup pointless and/or disruptive.
First, note how many different tools are mentioned. If your project uses one or more of them, you'll need to monitor them all to understand what's happening around you.
Second, the constant interruptions of Slack can be extremely disruptive to workflow, as has been noted in a few articles posted here.
Third, the article makes an assumption I've seen elsewhere and cannot relate to at all: that project members don't need a high-level snapshot of the project on a day-to-day basis. That it doesn't improve what they do and only sucks time away from the more important job of getting stuff done. As the author puts it:
> I'd argue the loss of your focus more probable than the benefit of knowing what someone else is working on.
This is a recipe for the entire team heading off a waterfall, each in their own hermetically-sealed, technologically sublime barrels. This is not to say that a daily standup can save you if the team is determined to do it. But getting that daily overview can help build consensus for changes in direction that simply can't come about by monitoring Jira.
I always wonder how effective team members showing the tendency to minimize the bigger picture while maximizing the importance of their own contribution will be on a team. The answer usually turns out to be "not very."
In a nutshell, the article claims that these electronic tools render a daily standup pointless and/or disruptive.
First, note how many different tools are mentioned. If your project uses one or more of them, you'll need to monitor them all to understand what's happening around you.
Second, the constant interruptions of Slack can be extremely disruptive to workflow, as has been noted in a few articles posted here.
Third, the article makes an assumption I've seen elsewhere and cannot relate to at all: that project members don't need a high-level snapshot of the project on a day-to-day basis. That it doesn't improve what they do and only sucks time away from the more important job of getting stuff done. As the author puts it:
> I'd argue the loss of your focus more probable than the benefit of knowing what someone else is working on.
This is a recipe for the entire team heading off a waterfall, each in their own hermetically-sealed, technologically sublime barrels. This is not to say that a daily standup can save you if the team is determined to do it. But getting that daily overview can help build consensus for changes in direction that simply can't come about by monitoring Jira.
I always wonder how effective team members showing the tendency to minimize the bigger picture while maximizing the importance of their own contribution will be on a team. The answer usually turns out to be "not very."
I strongly disagree and would like to apologise on the behalf of devs + managers that gave you this impression.
I was fortunate to work with people that ran proper stand-ups (5-15 minutes at the beginning of the day, actually standing up). Senior, junior, management, devs, it felt like we all benefited from a quick huddle before starting dev. Even if we Slack troughout the day and raise issues, having a quick sync session seemed to have a bigger impact.
I was fortunate to work with people that ran proper stand-ups (5-15 minutes at the beginning of the day, actually standing up). Senior, junior, management, devs, it felt like we all benefited from a quick huddle before starting dev. Even if we Slack troughout the day and raise issues, having a quick sync session seemed to have a bigger impact.
Agree with the notion that turning standup into a static status meeting is a poor use of time. If you're blocked you should speak up. If the team wants to know the state of your work, they should defer to project management tool. That said, "standup" is less to do with what you did or immediate blockers. It's about planning for the day. "Here's what's going to get done today, and here's the relevant information for my team." It's a tool for synchronizing, getting on the same page, setting you and your team up for success on a daily basis.
If you don't feel like that's the case, you're probably right in that going async would be a better use of your time. I suspect this is a process dysfunction that has less to do with standup and more to do with a misunderstanding of the value proposition associated with a properly executed standup.
Edit: not everything is an immediate "oh sh*t" type of blocker. If you're working in a collaborative organization, you most like have "low tier" blockers or knowledge that can and should be shared with the team. Face to face makes this easy.
If you don't feel like that's the case, you're probably right in that going async would be a better use of your time. I suspect this is a process dysfunction that has less to do with standup and more to do with a misunderstanding of the value proposition associated with a properly executed standup.
Edit: not everything is an immediate "oh sh*t" type of blocker. If you're working in a collaborative organization, you most like have "low tier" blockers or knowledge that can and should be shared with the team. Face to face makes this easy.
I get the frustration, I really do.
But I think part of the issue here is the idea that time is fungible like money. That saving time by looking at Trello cards instead of meeting face to face is somehow more effective.
It might be. It might not be. But simply saving a few minutes of time doesn’t necessarily equate to “more productive.”
This kind of optimization of behavior assumes everyone will consume information uniformly.
Ever sent up a smoke signal for help on a blocker in slack, only for the comment to be lost in a bunch of messages and you stay blocked?
Again, in a perfect world, we could just record everything and do it all asynchronously. Wonderful ideal.
But the stand up, in my experience, accomplished more than just cold task management.
It gives a point for each person to consider what they’ve done, compose it, and to raise in a higher resolution environment the blockers they have.
It’s silly to think that we can replace every interaction with an async version of the same interaction, at least on my team.
At the same time, I don’t recommend dogma in either direction. Don’t find value in the standup? Do something different.
But I think part of the issue here is the idea that time is fungible like money. That saving time by looking at Trello cards instead of meeting face to face is somehow more effective.
It might be. It might not be. But simply saving a few minutes of time doesn’t necessarily equate to “more productive.”
This kind of optimization of behavior assumes everyone will consume information uniformly.
Ever sent up a smoke signal for help on a blocker in slack, only for the comment to be lost in a bunch of messages and you stay blocked?
Again, in a perfect world, we could just record everything and do it all asynchronously. Wonderful ideal.
But the stand up, in my experience, accomplished more than just cold task management.
It gives a point for each person to consider what they’ve done, compose it, and to raise in a higher resolution environment the blockers they have.
It’s silly to think that we can replace every interaction with an async version of the same interaction, at least on my team.
At the same time, I don’t recommend dogma in either direction. Don’t find value in the standup? Do something different.
I've had no issues with standups. Even in a small team I find them useful as a way to step back and see the bigger picture, plus they rarely take more than 5-10 minutes of my morning.
On the other hand, I've had friends who have endured 30 minute standups every day for the past few months. I think they started sitting after the first few sessions.
On the other hand, I've had friends who have endured 30 minute standups every day for the past few months. I think they started sitting after the first few sessions.
As a fairly new out of university and with my first startup job, I found the newly introduced daily standup a motivation saver & reduced stress in the group.
Our dev sub-group had no sync-meeting except weekly-meetings where we met the entire department that presented their progress that didn't give us any insight in what was going on at all. Didn't help that our sub-group responsible where the CTO, that was mostly absent for investor/customer/management meetings. Tasks where distributed really unevenly, some devs got isolated in their module/tasks for week/months and lost sight of where the development was at the moment.
standups seems to work pretty well when the person in charge have insight in to how each members work fit in to the overall picture, and would rather not manage the group much more than making sure people are not trailing off. It helps the group more than the managers, if done right.
Our dev sub-group had no sync-meeting except weekly-meetings where we met the entire department that presented their progress that didn't give us any insight in what was going on at all. Didn't help that our sub-group responsible where the CTO, that was mostly absent for investor/customer/management meetings. Tasks where distributed really unevenly, some devs got isolated in their module/tasks for week/months and lost sight of where the development was at the moment.
standups seems to work pretty well when the person in charge have insight in to how each members work fit in to the overall picture, and would rather not manage the group much more than making sure people are not trailing off. It helps the group more than the managers, if done right.
Daily standups are not useful to me, but having just a periodic conversation with who you work with is more useful that both just standups and/or just checking issue lists.
A lot of times, there are plenty who simply don't talk about the projects they are working on unless prompted. This extends even to JIRA tickets, which can feel like bookkeeping than actual work. For me, this tends to be a constant problem, but adding more layers of protocol tends to scare people more than anything. This can be like a fear around saying you couldn't get anything done yesterday.
With simple conversations where I can just talk with team members for an hour or so is more revealing that trying to answer specific questions. The important thing is not to cover each detail. Instead, for me, is just conversing about problems where we all gain more insight in what we are doing that helps a lot.
A lot of times, there are plenty who simply don't talk about the projects they are working on unless prompted. This extends even to JIRA tickets, which can feel like bookkeeping than actual work. For me, this tends to be a constant problem, but adding more layers of protocol tends to scare people more than anything. This can be like a fear around saying you couldn't get anything done yesterday.
With simple conversations where I can just talk with team members for an hour or so is more revealing that trying to answer specific questions. The important thing is not to cover each detail. Instead, for me, is just conversing about problems where we all gain more insight in what we are doing that helps a lot.
As a grunt, hate them but as a team leader they really help make my life easier. In short, depending on team size, you are sacrificing the producers to make the manager's job easier and unfortunately this is a decision that the manager gets to make, so guess what decision is made all the time.
The problem is that as a manager I don't want to look bad in front of my manager and he he/her manager's and so on and so forth, so I have to do things that are suboptimal from a delivery point of view to avoid this, e.g. run a stand up to keep a close eye on what everybody is working on rather than say not and ensure that they guys (and gals) know that I'm here to help should they get stuck.
To be fair, they do help with managing people that are, for whatever reason, reluctant to look for help, but there are other ways of managing this
The problem is that as a manager I don't want to look bad in front of my manager and he he/her manager's and so on and so forth, so I have to do things that are suboptimal from a delivery point of view to avoid this, e.g. run a stand up to keep a close eye on what everybody is working on rather than say not and ensure that they guys (and gals) know that I'm here to help should they get stuck.
To be fair, they do help with managing people that are, for whatever reason, reluctant to look for help, but there are other ways of managing this
> As a grunt, hate them but as a team leader they really help make my life easier.
Have your grunts obeyed their leader?
Have your grunts obeyed their leader?
Don't just do something, stand there!
In the very spirit of agile, if standups are not providing your team value, then by all means stop doing them. But, if you are not able to perform a quick functional standup that informs your team about the important work each person is doing, their blockers, etc, might I suggest this is a sign of a deeper team disfuction, rather than some inherent issue with standups generically.
I'd go further to say that if your standups consist merely of parroting words verbatim from JIRA, you're letting your team down by not providing additional detail and context that could be provided more easily in person than on such a tool.
Lastly, reading between the lines of your text, you seem very much "over it". Not standups, but team engineering. Possibly time to find a new environment better suited to what you enjoy.
I'd go further to say that if your standups consist merely of parroting words verbatim from JIRA, you're letting your team down by not providing additional detail and context that could be provided more easily in person than on such a tool.
Lastly, reading between the lines of your text, you seem very much "over it". Not standups, but team engineering. Possibly time to find a new environment better suited to what you enjoy.
Reducing actual face-to-face interaction and communicating only over Jira is a way to de-humanize work.
Do work as a team of humans. Talk directly to your fellow team members. Using daily standups is a face-to-face way of syncing.
Don't work by sitting 10 hours in front of your screen and communicate only via chat channels.
Do work as a team of humans. Talk directly to your fellow team members. Using daily standups is a face-to-face way of syncing.
Don't work by sitting 10 hours in front of your screen and communicate only via chat channels.
Jira is the passive aggressive student fridge note system of communication
Standups are only good if they're used for a very specific, time-critical task that requires coordination among several people. Ex: a major feature is being launched that requires a lot of coordination, but is going to be done in 10 days.
Standups should not be used as tack-on "agile" or as a way for management to keep up with what devs are doing or to pressure devs to do more. Ex: daily standup at 11 am.
The original purpose of standups in "agile" was to help devs get unblocked. But the expectation should be that others should help devs get unblocked whenever they hit a block, instead of waiting til the next standup! What are they wasting time being blocked when they can simply send an email or IM to a colleague?
Standups should not be used as tack-on "agile" or as a way for management to keep up with what devs are doing or to pressure devs to do more. Ex: daily standup at 11 am.
The original purpose of standups in "agile" was to help devs get unblocked. But the expectation should be that others should help devs get unblocked whenever they hit a block, instead of waiting til the next standup! What are they wasting time being blocked when they can simply send an email or IM to a colleague?
Indeed, to make a standup more straightforward we usually just fix 3 questions to everyone:
1. What are you working on?
2. Are you having any blockers?
3. What are you going to work on next?
In reality it's just about blockers and seeing the next direction.
No need to embellish or 'stuff' any of these responses. It was kind of natural when we used to have a real storyboard, the one with post-it stickies. So the standup would be a good time to move the stories to done or todo side.
Well, the whole idea kind of sputters when there're significant status disbalances on the team. For one, the dev members get into status-report mode, while the managers get into i'm-busy-with-important-meetings mode. For the other, it's harder for mangement members of a team to align their ways of staying busy with 'ant-like' activity of devs. Also in such context a 'blocker' suddenly signals a kind of a failure, lack of efficiency that has to be owned, instead of a usual work issue. Who wants to own a failure?Ironically, the management can be instrumental in resolving intra-dept blockers.
Any team is about mutual trust, so if the standup does not serve the needs of the whole team, I'd just reserve that time to those members that see a benefit from it. Find another way to interface with other members (mgmt?), maybe a questions queue or some briefs pipeline.
1. What are you working on?
2. Are you having any blockers?
3. What are you going to work on next?
In reality it's just about blockers and seeing the next direction.
No need to embellish or 'stuff' any of these responses. It was kind of natural when we used to have a real storyboard, the one with post-it stickies. So the standup would be a good time to move the stories to done or todo side.
Well, the whole idea kind of sputters when there're significant status disbalances on the team. For one, the dev members get into status-report mode, while the managers get into i'm-busy-with-important-meetings mode. For the other, it's harder for mangement members of a team to align their ways of staying busy with 'ant-like' activity of devs. Also in such context a 'blocker' suddenly signals a kind of a failure, lack of efficiency that has to be owned, instead of a usual work issue. Who wants to own a failure?Ironically, the management can be instrumental in resolving intra-dept blockers.
Any team is about mutual trust, so if the standup does not serve the needs of the whole team, I'd just reserve that time to those members that see a benefit from it. Find another way to interface with other members (mgmt?), maybe a questions queue or some briefs pipeline.
In a recent client engagement I witnessed scrum-gone-badly-wrong.
It happened underneath the department manager in the line organization of a large corporate (not project manager, line manager). He managed about a dozen people doing about a dozen projects at any one time. A project was usually staffed by one person working it fulltime, and drawing support from the rest of the group here and there.
The manager held a daily standup involving the whole dozen people. With everybody doing a five-minute status report on their project, that meant five minutes of speaking time for everybody and 55 minutes of sitting through status reports on projects that you had zero involvement with, where you couldn't possibly have anything useful to say. I suggested numerous times that it would be better to have devs have a 1-hour blocker in their calendar without an actual meeting. They would do an e-mail update, and if the manager saw the need for any clarification he could use the 1-hour timeslot to turn up at their desk and talk 1-on-1. It would have been so much more efficient, but the manager didn't go for the suggestion.
Paying lip service to the scrum quasi religion, the manager repeatedly emphasized that the point of the standup was not to check on people's productivity or make them face repercussions for not meeting daily commitments. But he never missed an opportunity to make a passive-aggressive joke when a dev's productivity was called into question. Like a dev might say "I thought I would be able to do X yesterday, but didn't manage, because problem Y turned up. I solved Y, but X is still not done". The manager might jokingly say something like "Well, I hope you enjoyed your beachtime and will be able to finish X today." So not funny. I'm thoroughly convinced that shaming people was the method he was using to pressure people into doing overtime or otherwise doing whatever was necessary to meet daily goals every day, and that that was the real reason he wanted the whole department in the room. Because shaming is so much more effective when you shame somebody in front of a lot of people than just making a bad joke in a 1-on-1 situation.
It happened underneath the department manager in the line organization of a large corporate (not project manager, line manager). He managed about a dozen people doing about a dozen projects at any one time. A project was usually staffed by one person working it fulltime, and drawing support from the rest of the group here and there.
The manager held a daily standup involving the whole dozen people. With everybody doing a five-minute status report on their project, that meant five minutes of speaking time for everybody and 55 minutes of sitting through status reports on projects that you had zero involvement with, where you couldn't possibly have anything useful to say. I suggested numerous times that it would be better to have devs have a 1-hour blocker in their calendar without an actual meeting. They would do an e-mail update, and if the manager saw the need for any clarification he could use the 1-hour timeslot to turn up at their desk and talk 1-on-1. It would have been so much more efficient, but the manager didn't go for the suggestion.
Paying lip service to the scrum quasi religion, the manager repeatedly emphasized that the point of the standup was not to check on people's productivity or make them face repercussions for not meeting daily commitments. But he never missed an opportunity to make a passive-aggressive joke when a dev's productivity was called into question. Like a dev might say "I thought I would be able to do X yesterday, but didn't manage, because problem Y turned up. I solved Y, but X is still not done". The manager might jokingly say something like "Well, I hope you enjoyed your beachtime and will be able to finish X today." So not funny. I'm thoroughly convinced that shaming people was the method he was using to pressure people into doing overtime or otherwise doing whatever was necessary to meet daily goals every day, and that that was the real reason he wanted the whole department in the room. Because shaming is so much more effective when you shame somebody in front of a lot of people than just making a bad joke in a 1-on-1 situation.
I don't know if they daily standup is necessary, but there is some value in frequent synchronous meetings. Some people just feel more comfortable bringing things up during a meeting, despite the myriad ways they could otherwise communicate.
Standups can be great. And they can be useless. It depends on how they are designed and used. For example, the frequency should be matched to the needs of the team. It only makes sense to meet when there is relevant new information. For example, at the Broad institute at MIT, lab teams meet daily to discuss the output from the last day to identify bottlenecks. It’s important to identify problems quickly so meeting every day makes sense. In other systems, meeting every two or three days would make more sense. It’s not that standups are useless, but that poorly designed stand ups are useless.
I had the exact same feeling when we started having daily standups about 4 years ago for a green field project. Now that most of the original developers are no longer in the company I feel glad that I actually paid attention. It turns out that I have a very good knowledge about how and what every micro-service in our stack does. What's discussed in those standups might not be relevant for day-to-day work, but on a higher level it can help developers understand the architecture of a complex system better.
"Your standups are killing your velocity."
"Velocity"?
It'll be hard to start a revolution while still using the enemy's terminology.
--
Gods, I'm miss PMI, critical path, the trilemma (time, cost, scope), quality, rationality.
And before any ankle biters whinge about "water fall", just stop. We were so much more iterative, nimble back when we acted like professionals.
The Agile Methodology is to argue about the Agile Methodology. Pop-biz psychology. Tech's own post-modernist rejection of anything older than a week. And just as useful.
"Velocity"?
It'll be hard to start a revolution while still using the enemy's terminology.
--
Gods, I'm miss PMI, critical path, the trilemma (time, cost, scope), quality, rationality.
And before any ankle biters whinge about "water fall", just stop. We were so much more iterative, nimble back when we acted like professionals.
The Agile Methodology is to argue about the Agile Methodology. Pop-biz psychology. Tech's own post-modernist rejection of anything older than a week. And just as useful.
I strongly disagree. People sometimes won't mention important things (e.g., blockers, possible misunderstandings) unless prompted and encouraged (you sometimes actually need to look at the person's face and hear the intonation). Async interrupts are bad (I don't have time to get into that one right now). I would have replace "Excitement" with "expectation management", "mental atmosphere monitoring".
I do agree that badly managed stand-ups are a waste of time.
I do agree that badly managed stand-ups are a waste of time.
> People sometimes won't mention important things (e.g., blockers, possible misunderstandings) unless prompted and encouraged (you sometimes actually need to look at the person's face and hear the intonation).
But that's a management fail. Every time I've managed a person that did this, I took them aside and had a short but firm word with them. You can't tolerate that type of behavior in a team if you plan to operate effectively. I seldom need more than one warning; I never needed more than two.
But that's a management fail. Every time I've managed a person that did this, I took them aside and had a short but firm word with them. You can't tolerate that type of behavior in a team if you plan to operate effectively. I seldom need more than one warning; I never needed more than two.
The point I was trying to make is that when a person is [inexperienced/shy/too aggressive/doesn't get along with somebody/lazy/does not like the current task/does not understand the motivation/etc] I need, as a manager, opportunity to notice it.
some of those are not necessarily "bad" or require intervention, just awareness.
some of those can change over time (and on daily basis).
(and in the case of bad behavior, in order to prevent "management fail", I want to take them aside for that short talk before things get spiraling)
(that being said, it's not the only reason for standups)
(if in my team everybody is in the same place, actually interacting in-person does give some added value)
some of those are not necessarily "bad" or require intervention, just awareness.
some of those can change over time (and on daily basis).
(and in the case of bad behavior, in order to prevent "management fail", I want to take them aside for that short talk before things get spiraling)
(that being said, it's not the only reason for standups)
(if in my team everybody is in the same place, actually interacting in-person does give some added value)
I completely agree with this. Standups are pointless, you have just communicate anything that you need to communicate via chat. Standups in general are simply a pressuring mechanism.
I would not mind a stand-up once a week. In fact on a team that never had meetings, I suggested to my manager to have a half-hour meeting every week or two. And I hate meetings!
I usually take note of what I did at the end of the day to give me an idea of how productive / unproductive I was. On a previous time I got everyone to just post their standup updates on Slack. It was quick and asynchronous. If you wanted to follow up with someone you could just talk to them afterwards.
It also gives you a history of the past week, month, etc if interested.
Data is useful and daily meetings are often pointless. Let’s all evolve our standup routine.
The only time I have ever seen value in a daily standup meeting is when I worked in a blue-collar industrial job.
Everybody had to clock in by 6:30 AM, so there was none of this shit where it is time for the standup, and two or three people haven't dragged in yet, so you delay and waste time.
The foreman told each person what they were doing that day. And that was what they needed to get done.
If there was a blocker or a safety issue, you threw the shutoff switch and jumped on the radio right away.
Everybody had to clock in by 6:30 AM, so there was none of this shit where it is time for the standup, and two or three people haven't dragged in yet, so you delay and waste time.
The foreman told each person what they were doing that day. And that was what they needed to get done.
If there was a blocker or a safety issue, you threw the shutoff switch and jumped on the radio right away.
I work remotely, have the last 5 years. I love daily standups. Here's why:
1. We do all of our work business async. (e.g. what did you do? what are you working on? All that stays in slack)
2. We use our standups for ice-breaker questions and company-wide announcements. (e.g. Everyone talks about what their favorite vacation was, which usually creates quite the conversation. And then afterwards, the team heads will give any critical updates they have, which usually are none)
1. We do all of our work business async. (e.g. what did you do? what are you working on? All that stays in slack)
2. We use our standups for ice-breaker questions and company-wide announcements. (e.g. Everyone talks about what their favorite vacation was, which usually creates quite the conversation. And then afterwards, the team heads will give any critical updates they have, which usually are none)
Everyone talks about what their favorite vacation was
Getting to the office "on time" (9 AM) takes an extra 30 minutes compared to arriving "late" (10 AM) due to rush hour mass transit congestion. I would be very pissed off if I had to show up on time just to hear about my coworkers' vacations.
Getting to the office "on time" (9 AM) takes an extra 30 minutes compared to arriving "late" (10 AM) due to rush hour mass transit congestion. I would be very pissed off if I had to show up on time just to hear about my coworkers' vacations.
> I work remotely
I have no commute. Hearing another human being is a welcome change from sitting in my home office all day.
I have no commute. Hearing another human being is a welcome change from sitting in my home office all day.
I am pretty sure that I would commit some kind of X-icide if I had to take productive time out of my day for forced social chit-chat of this nature.
They had best have at least donuts available as recompense for inflicting this kind of atrocity. Pizza or Chinese takeout would be more appropriate.
They had best have at least donuts available as recompense for inflicting this kind of atrocity. Pizza or Chinese takeout would be more appropriate.
it depends on the tone of the standup.
For a start they should be quick, and the team needs to be fairly small (about 5-6 seems ideal). and cohesive, mostly working on related or interacting code. Also I assume remote, as that's my experience.
The status update part should be extremely quick even perfunctory, unless there's an interesting lesson or important caveat or note-bene etc to share with the team.
The reason for the standup is to make sure everything is "joining up" properly, no new obstacles are looming, and possibly to plan meetings/pairing sessions/etc, for later that day, where required. ie like a football scrum where you agree the game-play for the day.
It's also chance for a bit of "team bonding" type stuff, eg to ask the whole team "are we all feeling good about this sprint", etc - ie, the kind of stuff that may not obvious from stats
If the standup just becomes a forced "status report", that's worse than useless, I agree, and just makes everyone feel "monitored" and under pressure.
I would guess they are also less useful (and potentially more stressful) where everyone is physically present, and might be seen as a trick to get everyone to the office on time.
For a start they should be quick, and the team needs to be fairly small (about 5-6 seems ideal). and cohesive, mostly working on related or interacting code. Also I assume remote, as that's my experience.
The status update part should be extremely quick even perfunctory, unless there's an interesting lesson or important caveat or note-bene etc to share with the team.
The reason for the standup is to make sure everything is "joining up" properly, no new obstacles are looming, and possibly to plan meetings/pairing sessions/etc, for later that day, where required. ie like a football scrum where you agree the game-play for the day.
It's also chance for a bit of "team bonding" type stuff, eg to ask the whole team "are we all feeling good about this sprint", etc - ie, the kind of stuff that may not obvious from stats
If the standup just becomes a forced "status report", that's worse than useless, I agree, and just makes everyone feel "monitored" and under pressure.
I would guess they are also less useful (and potentially more stressful) where everyone is physically present, and might be seen as a trick to get everyone to the office on time.
> ie like a football scrum where you agree the game-play for the day.
Why do you need to change your strategy every single day? Do your requirements change that fast? What you're describing is the point of the sprint planning meeting IMO.
Why do you need to change your strategy every single day? Do your requirements change that fast? What you're describing is the point of the sprint planning meeting IMO.
Daily would be tactics, not strategy, and ideally the daily game-plan follows, and follows obviously from, what was planned for the sprint, in which case the scrum is just a rubber stamp.
Ideally.
Ideally.
I come to prefer standup over slack, 10:30amish everyday a 30 second message of.
-I did x yesterday and am doing y today. - I am blocked/need a (answer, code review, dependency completed, ect). -reminder of OOO or WFH.
This minor message keeps everyone in the loop and takes little time. If you feel pressure to deliver because of standup I would say that's a cultural issue... or a self performance one (aka why have you been working on x for 2 weeks).
-I did x yesterday and am doing y today. - I am blocked/need a (answer, code review, dependency completed, ect). -reminder of OOO or WFH.
This minor message keeps everyone in the loop and takes little time. If you feel pressure to deliver because of standup I would say that's a cultural issue... or a self performance one (aka why have you been working on x for 2 weeks).
It's not a cultural issue, it's human nature. You are being asked about your performance daily in front of your group of peers.
This will obviously psychologically pressure you to finish things ASAP, so that you can say that its done on the next standup.
And that is why management like standups so much, I mean why not say what it is actually for, instead of coming up with all these other side explanations.
This will obviously psychologically pressure you to finish things ASAP, so that you can say that its done on the next standup.
And that is why management like standups so much, I mean why not say what it is actually for, instead of coming up with all these other side explanations.
> "Maybe its naiveté or maybe just being on teams where, remarkably, nobody knew how to do an effective standup (myself included)"
Nailed it. Please don't "ping me on slack" to find out what I'm working on. And please don't force me to document to the nth degree in JIRA. Let's just have a quick chat in the morning and move on with the day.
Nailed it. Please don't "ping me on slack" to find out what I'm working on. And please don't force me to document to the nth degree in JIRA. Let's just have a quick chat in the morning and move on with the day.
One way of doing stand-ups that I found least annoying was we went through the Kanban board and basically asked if you had any problems with your assigned item. If there was no problem then you were done. If no one had any issues it was done in a few minutes and there was no chance for it to descend into pointlessness or irrelevant tangets.
Agree with this! Standups are so much worse when you're remote and working different timezones too. It's so disruptive knowing you've got to set up a voice call at a certain time most days. It's completely against async working and takes away your freedom to work the hours that work best for you.
I wouldn't mind stand-ups (well, not as much ) if they actually stuck to their mission statement.
My biggest problem is that almost always someone (usually the product owner/manager) starts droning on and on about stuff that has little to do with daily work, usually by repeating stuff already said the day before.
My biggest problem is that almost always someone (usually the product owner/manager) starts droning on and on about stuff that has little to do with daily work, usually by repeating stuff already said the day before.
I cannot upvote this enough. Why do these companies pay us all this money and then burn it with this nonsense?
To some extent I find standups useful for joining a team. It helps me understand how to team operates, who the experts are, the team's struggle points, etc. But yes, after a short while they do begin to feel mostly pointless.
Stand ups are the modern mashup of two great comedian quotes:
Pascal's "I have made this longer than usual because I have not had time to make it shorter"
And Carlin's "Have you noticed that their stuff is shit and your shit is stuff?"
Pascal's "I have made this longer than usual because I have not had time to make it shorter"
And Carlin's "Have you noticed that their stuff is shit and your shit is stuff?"
Just a token of systemic conformism to start the morning, as a cog in the machine..
The key to a good stand up is if you have nothing to add, or to say, just make it very quick.
They're useful for people actually working together and having a sit-rep. When it's business as usual, they just hinder morale.
They're useful for people actually working together and having a sit-rep. When it's business as usual, they just hinder morale.
It is hard for one to appreciate the value of a process that helps teams operate well in the long run, in the face of disruptions, pivots, failures, growth, etc. If you can do without standups, good for you.
Standups (as implemented) or another way management thought they can do the same work without hiring real developers.
You can come up with any process you want, if you don't have the people, you have nothing.
You can come up with any process you want, if you don't have the people, you have nothing.
Stand ups had one real value for me - maintaining my accountability to my team.
Having to say "yesterday I was too busy arguing online so didn't do anything" was something helpfully painful.
Having to say "yesterday I was too busy arguing online so didn't do anything" was something helpfully painful.
We do standups, however the questions are more like
What task moved yesterday? (handover?) What task is going to move today?
and the most important one: What is blocked? (Who can help to unblock?)
I can recommend this format for everybody.
What task moved yesterday? (handover?) What task is going to move today?
and the most important one: What is blocked? (Who can help to unblock?)
I can recommend this format for everybody.
let me start with some piece of wisdom: scrum is not a silver bullet. It may not solve your problem, and create additional ones if done improperly.
Also, scrum is not written on stone. If something from scrum does not work for your team/company culture, don't use it. Dont like standups ? dont have them. Dont like poker planning ? Don't play it.
The process should help you achieve your goals easier and quicker. If the process is hindering your work, just don't follow it.
Also, scrum is not written on stone. If something from scrum does not work for your team/company culture, don't use it. Dont like standups ? dont have them. Dont like poker planning ? Don't play it.
The process should help you achieve your goals easier and quicker. If the process is hindering your work, just don't follow it.
Refreshing take on standups: https://youtu.be/2u0sNRO-QKQ?t=105
We replaced our daily standups with a chat room. Now, everyone can come in whenever they like and the “standup” can happen totally asynchronous.
We do standups so people arrive early in the morning.
I was once told that when requesting the standup to be reschedule one hour later.
They're even worse when the team stops standing up for them. Then they turn into a daily agendaless mandatory half-hour meeting.
We started having standups are user stories instead of individuals. Reading the article through this lense made it irrelevant.
Does anybody suspect that software development is just that tad slightly a completely micro managed profession.
[deleted]
Provocative headline. Absolute BS argument.
Daily Stand up is crucial for juniors to know what is going on.
Daily Stand up is crucial for juniors to know what is going on.
> Mentoring is crucial for juniors to know what is going on.
FTFY
FTFY
iunno, listening to the whole team and knowing what people are working on was wildly helpful when I was a junior. Mentoring is important but so is knowing how the team actually tackles the problems.
Especially for juniors who are worried about seeming dumb when they have a blocker/problem. Having that space to hear Seniors say they're stuck makes em talk more.
I'm a consultant so I get to see all the wide wide varieties of standups and the short sweet ones just make things hum so much nicer than a 30 minute morning meeting.
Especially for juniors who are worried about seeming dumb when they have a blocker/problem. Having that space to hear Seniors say they're stuck makes em talk more.
I'm a consultant so I get to see all the wide wide varieties of standups and the short sweet ones just make things hum so much nicer than a 30 minute morning meeting.
I'm on your side. But some, maybe most people, prefer synchronous talking. And even with async, making a point of daily updates keeps teams focused.
Synchronous talking has a synchronization overhead. If you do the stand-up in the beginning of the day it forces everyone to arrive at the same time. If you do it in the middle of the day it is an interruption for everybody. It's usually just not worth the costs to create meetings just to satisfy the interaction needs of extroverts in your team.
As I see it, if managed properly, daily stand-ups is more about introverts. As one, I found the formal obligation to give verbal updates and a be in a place to hear updates very helpful especially when I was a junior programmer.
They’re a means of “controlling the code monkeys.” Everyone knows this. (Except the naive devs who have bought into “agile.”)
We've been doing daily free-form standups for years. Initially, it was in-person because nobody was working remote. Recently, one of our people moved to another state and we decided to shift towards remote work to accommodate that, with the eventual shift towards enabling it for everyone.
That shift has meant that all meetings now have a video component. Our weekly meeting is everyone in a room, except the remote person who is on video. Daily meetings are all-video, everyone participating from their desk via video chat.
Previously, our "meeting" was really a chat session that we talked about work a little and other stuff a lot.
Now, our meeting starts with what everyone did and will be doing, working through some issues anyone has, and then talking about whatever until we run out of stuff to talk about, which is usually shorter than I expected, given our previous in-person meeting length.
We have 4 developers, and this seems to be working very well for us.
Without the daily meetings, we'd not get some of these issues resolved as quickly and we wouldn't have as much team-building time. We initially tried an afternoon meeting for that team-building time, but it didn't work for various people for a number of reasons.
The person writing this article seems very hostile towards the rest of the organization. They just want to be in their little box and not have to deal with others. They think everything can work out easily just by using Slack. I think they're terribly mis-guided.
What I've seen instead is that people tend to try to own their problems instead of asking for help, but daily standups give them a chance to easily mention their issue and for others to help off-handedly. Things that people previously held onto for days are now taking no more than a day to resolve.
I think the problem has 2 parts: Ego, and puzzles. Nobody wants to ask for help, and they'd rather solve it themselves. And puzzles are fun. Most of the great developers I've met love working through problems and figuring out a solution, even if it's not an ideal one. The best developers also work past these problems, but nobody is perfect, and standups definitely help.
tl;dr - Standups work for us and our team is closer for it.
That shift has meant that all meetings now have a video component. Our weekly meeting is everyone in a room, except the remote person who is on video. Daily meetings are all-video, everyone participating from their desk via video chat.
Previously, our "meeting" was really a chat session that we talked about work a little and other stuff a lot.
Now, our meeting starts with what everyone did and will be doing, working through some issues anyone has, and then talking about whatever until we run out of stuff to talk about, which is usually shorter than I expected, given our previous in-person meeting length.
We have 4 developers, and this seems to be working very well for us.
Without the daily meetings, we'd not get some of these issues resolved as quickly and we wouldn't have as much team-building time. We initially tried an afternoon meeting for that team-building time, but it didn't work for various people for a number of reasons.
The person writing this article seems very hostile towards the rest of the organization. They just want to be in their little box and not have to deal with others. They think everything can work out easily just by using Slack. I think they're terribly mis-guided.
What I've seen instead is that people tend to try to own their problems instead of asking for help, but daily standups give them a chance to easily mention their issue and for others to help off-handedly. Things that people previously held onto for days are now taking no more than a day to resolve.
I think the problem has 2 parts: Ego, and puzzles. Nobody wants to ask for help, and they'd rather solve it themselves. And puzzles are fun. Most of the great developers I've met love working through problems and figuring out a solution, even if it's not an ideal one. The best developers also work past these problems, but nobody is perfect, and standups definitely help.
tl;dr - Standups work for us and our team is closer for it.
So many things to say in response to this article but lets start here: "Your standups are killing your velocity."
Agile in general is about predictability first and measuring a predictable velocity. Predictable velocity answers a very important question for product management which is "When can we release".
Additionally, Agile Methodology touts Cross Functional Teams where each developer is not a specialist in any one area of the product necessarily. The daily standup is a good place to indicate that a dev has run into an obstacle and seek guidance from someone else on the cross functional team who may in fact be the in house expert on that issue.
Guidance in this case typically comes in the form of "Oh, XYZ Thing, I built that - the code you're looking for is in /secret/stuff and if you look in there I think you will find what you're looking for".
What guidance is not: "Im having trouble with XYZ - will someone else on the team TOTALLY DROP THEIR SPRINT COMMITMENTS AND DO MY JOB FOR ME".
Agile and its daily standups are not about increasing velocity. They are about ensuring predictable velocity at the cost of absolute velocity (the max the team may be capable of performing at which itself will vary from sprint to sprint).
Now, all that aside, the real value of the daily standup is obviously accountability. That little 15 minute meeting forces a slacker to stand up in front of the rest of the team and clearly indicate that they either are or are not pulling their weight. Used properly it can be a very motivating practice.
Perhaps the author works in a place where every team member is a one person gang capable of independently completing any task whatsoever in the bounds of a sprint. In such an environment Agile itself does become a bottleneck. In the prefect world Agile is absolutely unnecessary - but most of us live in a world thats far from perfect.
In summary, Agile as a whole and certainly daily standups can and do act as a drag on the velocity of a proficient team. However the purpose of these practices is not to maximize velocity but rather to ensure a floor for velocity such that a team may never achieve its maximum potential but will instead continue to reliably deliver a velocity that is constant and predictable. Think of this as a sort of Productivity Insurance Policy and it makes a lot more sense.
*Additionally - I know of no law that restricts a developer from reaching out for assistance/additional guidance immediately on discovery of a blocking issue. The daily standup is just a convenient place where you have a crack at communicating with the whole team in one place. Typically with some manager type lurking quietly on the call like a parent keeping an ear on the kids playing in the other room.
Agile in general is about predictability first and measuring a predictable velocity. Predictable velocity answers a very important question for product management which is "When can we release".
Additionally, Agile Methodology touts Cross Functional Teams where each developer is not a specialist in any one area of the product necessarily. The daily standup is a good place to indicate that a dev has run into an obstacle and seek guidance from someone else on the cross functional team who may in fact be the in house expert on that issue.
Guidance in this case typically comes in the form of "Oh, XYZ Thing, I built that - the code you're looking for is in /secret/stuff and if you look in there I think you will find what you're looking for".
What guidance is not: "Im having trouble with XYZ - will someone else on the team TOTALLY DROP THEIR SPRINT COMMITMENTS AND DO MY JOB FOR ME".
Agile and its daily standups are not about increasing velocity. They are about ensuring predictable velocity at the cost of absolute velocity (the max the team may be capable of performing at which itself will vary from sprint to sprint).
Now, all that aside, the real value of the daily standup is obviously accountability. That little 15 minute meeting forces a slacker to stand up in front of the rest of the team and clearly indicate that they either are or are not pulling their weight. Used properly it can be a very motivating practice.
Perhaps the author works in a place where every team member is a one person gang capable of independently completing any task whatsoever in the bounds of a sprint. In such an environment Agile itself does become a bottleneck. In the prefect world Agile is absolutely unnecessary - but most of us live in a world thats far from perfect.
In summary, Agile as a whole and certainly daily standups can and do act as a drag on the velocity of a proficient team. However the purpose of these practices is not to maximize velocity but rather to ensure a floor for velocity such that a team may never achieve its maximum potential but will instead continue to reliably deliver a velocity that is constant and predictable. Think of this as a sort of Productivity Insurance Policy and it makes a lot more sense.
*Additionally - I know of no law that restricts a developer from reaching out for assistance/additional guidance immediately on discovery of a blocking issue. The daily standup is just a convenient place where you have a crack at communicating with the whole team in one place. Typically with some manager type lurking quietly on the call like a parent keeping an ear on the kids playing in the other room.
That little 15 minute meeting forces a slacker to stand up in front of the rest of the team and clearly indicate that they either are or are not pulling their weight.
Which again assumes -- using the article's language -- that your team is overladen with idiot teenagers. And that management is so out of touch that it wouldn't have any other way of sussing these people out.
Which again assumes -- using the article's language -- that your team is overladen with idiot teenagers. And that management is so out of touch that it wouldn't have any other way of sussing these people out.
What a strange rant about blockers.
Standups are supposed to take a few minutes and everyone becomes aware of what everyone is working on or blocked by. The person that controls the gate should become cognizant that its effecting someone else, and then it gets solved.
I love this.
I hate when standups are long winded. That removes the usefulness.
People dont need to interrupt the whole team and fish out who can help with the blockage, it just comes up and out. Thats the point anyway.
I use logs of standups and git commits to track dev progress.
Standups are supposed to take a few minutes and everyone becomes aware of what everyone is working on or blocked by. The person that controls the gate should become cognizant that its effecting someone else, and then it gets solved.
I love this.
I hate when standups are long winded. That removes the usefulness.
People dont need to interrupt the whole team and fish out who can help with the blockage, it just comes up and out. Thats the point anyway.
I use logs of standups and git commits to track dev progress.
I agree @ stand-ups being useless.
I've been on both sides of them: to give information to managers and to get information from people I delegated.
Stand-ups tend to turn into a defensive justification for 'being busy', and distracts from the intended purpose of asking for help.
At my current job, our manager wastes more time interrupting people during their stand-ups to tell them that they are giving the wrong amount of info "that nobody else cares about", instead of listening or helping.
At my previous job, it was used as a way to get people in the office at a certain time.
Your peers don't care about what you're working on, they care about sounding busy.
I've been on both sides of them: to give information to managers and to get information from people I delegated.
Stand-ups tend to turn into a defensive justification for 'being busy', and distracts from the intended purpose of asking for help.
At my current job, our manager wastes more time interrupting people during their stand-ups to tell them that they are giving the wrong amount of info "that nobody else cares about", instead of listening or helping.
At my previous job, it was used as a way to get people in the office at a certain time.
Your peers don't care about what you're working on, they care about sounding busy.
> I've been on both sides of them: to give information to managers and to get information from people I delegated.
This is horrific. It looks like you don't have a team which is self regulating, autonomous and where team members support each other. You've got a military style command and control structure where subordinates report to their commanding officer/manager. It is everyone for themselves.
You've got far bigger problems than stand ups. There is no trust and people are treated like children.
This is horrific. It looks like you don't have a team which is self regulating, autonomous and where team members support each other. You've got a military style command and control structure where subordinates report to their commanding officer/manager. It is everyone for themselves.
You've got far bigger problems than stand ups. There is no trust and people are treated like children.
Yeah, this has been my feeling for quite a while now, so it's 'nice' to see it being extrapolated from a situational observation.
Some individuals are trusted* while most are not trusted at all.
* Ts and Cs apply
Some individuals are trusted* while most are not trusted at all.
* Ts and Cs apply
I use standups to check in with everyone and... 1) inform everyone of why I'm making certain product decisions, so that everyone gets a "feel" for the problem space even though they're not directly talking to customers, etc. 2) Talk about a particular problem that wouldn't get discussed as a group if there wasn't time on the calendar every day, such as "where do we need to improve our telemetry" and 3) to just talk to each other for 30 minutes a day.
I don't like treating engineers as bug-closing robots and I don't think they like being treated as such. Standup gives everyone the feeling of being on a team of people working towards a common objective.
I don't like treating engineers as bug-closing robots and I don't think they like being treated as such. Standup gives everyone the feeling of being on a team of people working towards a common objective.
Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.
I even saw once a developer on his last day throwing the speaker's token (a teddy bear) to the trash can LOL!
Everyone on the teams I worked on seemed to think that standups where useless, this showed clearly through the team body language and tone in those meetings.
Its an interruption on your work just when you just got started in the morning, now you have to stop and go to a meeting.
What people are working on is usually unrelated and of no interest to each other, and if you need help you ask it anyway on the spot, there is no need to wait for the next standup for that.
It's hard to come up with different things to say on the meetings, as there aren't many things that have changed since yesterday.