Are daily standups hurting your team?
ideas.krishnan.ca
ideas.krishnan.ca
But it works great for us. We have explicitly discussed it before and that’s how we want it, at least for now.
The thing is, it’s a completely remote team of 9 people (two PMs, two engineering managers that code, 5 developers). 5 of us never met in real life and the rest were remote even before the pandemic. For us developers it is the only group meeting in the day 90% of the days. The PMs and Managers have lots of meetings, so they are often the ones leaving the standup early, and that’s ok.
We want that meeting to be loose, to allow for non-work conversations, to be flexible in what and how each person share their status. It works great for this team, of this size, with these people.
That’s the thing with advice like the OP. You have to make assumptions about how teams behave. But teams behave in an infinite combination of size, members, companies, and time (we might decide a year from now that we want to run standups differently).
Process should always be owned by the team as a whole. It should also be ever improving (even if this means complete change) and, almost more importantly, you should have as little of it as possible (it shouldn't get in the way).
My favorite version is one in which we just went through the daily Merge/Pull Requests in the system and let that be the check in. It set aside regular time for small code reviews and let everybody showcase things clearly, with room to ask people to dive in for a deeper review right then and there.
IMO it was much more effective than the normal standup ritual.
Feels like it's probably been positive for people since we all went 100% remote March 2020.
Good team rapport and trust etc are important factors, it's vital no one is "scared" to give honest updates.
We want most of our meetings to be effective, but we're intentionally about that one being a bit "sloppy". It's a good time to get to know people and uncover challenges that people might not raise asynchronously otherwise.
And that's the key: Do what works for your group.
The problem is that we have middle managers and project managers and middle project managers who go to conferences and watch lectures online and hang out in social media echo chambers talking about the latest, greatest innovation in managing projects without thinking about the people or the tasks involved.
Too often development teams are forced to work for the process, rather than the process working for them.
I've been in places where the PM would say things like, "We'll do it this way because it's what Google does." Well, Google has seventy brazillian people, and we have six on our team. What makes PMs think that one size fits all? It doesn't.
I currently have a guy who's trying to impose a project management method he learned from a video game company on us. We work in healthcare. But he refuses to deviate from what worked for the video game company, and thinks it's OK for the users to "discover" features on their own, rather than letting us spend time documenting how the system works. Again... in healthcare.
I spent a good few minutes trying to understand this sentence. Mainly because I am Brazilian and was stunned how did you know that I was. Then trying to understand how the number of Brazilian people might affect standup dynamic. Then trying to understand exactly how many Brazilians there were in Google and how many of the six of your team were Brazilian. Just then I understood it was an expression for “a lot” hahaha
Because your standup is primarily providing team bonding and meets other emotional needs.
Since we're fully remote, and we do standup over voice, we only see each other via video a couple times every three-week iteration. So a little chatter at the beginning of standup is a way to just check in and see how people are doing, including in their personal life.
Another idea to perhaps add: we've informally agreed that the time right after standup is typically reserved for small group discussions for any subset of the team.
We're fully remote (and have been for 10 years), so when standup starts, our brains have already shifted to "talking" mode (rather than planning/coding/reviewing mode), so it's easy to just keep going and help talk through any issues that would benefit from synchronous communication. Sometimes we screenshare, but frequently not - we just talk through whatever we're stuck on or could use insight from others.
This happens with us as well. Usually for technical discussions that will take longer than 5 to 10 minutes.
That seems so fantastical to me :/. That works out to 1 day with other group meetings every 2 weeks. Glad to hear there are places like that though!
This is the real key, IMHO. As a manager, I push the team to figure out what works best for them. I've seen daily standups w/status reports, no standups where we simply message the details, and bi-weekly where we talk more about status and challenges and save "what I did" for other mediums. In all cases, it's what the team wanted and worked best for them.
There are other routines that are actually helpful but don’t feel like the red guard roll call.
For a time I was managing a team that used this PO, and I quickly banned him outright from standups. Told him to keep his guidance granularity at the sprint level, make sure his stories were written well enough to not require constant elaboration, and otherwise leave the developers alone. He could show up for sprint review & planning. Standups were just to unblock anyone who needed it, and should only last a couple minutes.
He also liked to take really shitty notes, then treat them like the gospel truth. I read my stand-ups from notes I'd written beforehand—never done that anywhere else, but the amount of crap one was evidently expected to talk about was large enough there, that I did, after the first week or two—so I could tell for a fact when he'd recorded something about mine that was flat-out wrong, and it was often.
This is what makes standups shitty. I couldn't care less to know if you are still working on something. When you are done working on it, I'll know because the tooling will let me know of the changes. There is no time where vocalizing this provides value, unless you have no tools at all, which seems pretty silly if you are not working with a team of prehistoric cavemen.
If you have a fun story about what you did last night, a recap of last night's reality TV show, whatever floats your boat – that's much more valuable use of the time. I can get behind that, although don't be upset if I don't always show up.
The purpose of a functioning standup is contextualization. If you know your teammate is still working on feature X, maybe you notice that your own work is related and you can design some shared data structure that speeds up both of you.
If you want to be an IC with no responsibility, that's fine, just make it clear to your team that your assigned work is all you are going to do. If you want to be more productive individually and as a team, though, the interconnectedness of the team is just as important as what any one member is working on.
I'm still not clear on what information ”worked on feature X yesterday. Will continue to work on feature X today” gives me.
It gets better if there's some detail about the task, like "Still working on X, runtime is too slow but I found a paper linked from Wikipedia with a promising algorithm." Lots of inferred and implied knowledge transfer can happen through intetactions that seem simple on the surface. E.g. in my example here, ideas of how to approach research for a task, what kinds of obstacles are normal, etc.
If you're not building camaraderie, then maybe your standup isn't set up right or at the right time, but that doesn't mean the concept or the information is useless.
And as a last resort, if you can't change something, then put in your own effort to make the best of it instead of just wasting the time entirely.
Oh, but I can change something. If you remember having this discussion last year, it was ”worked on feature X yesterday. Will continue to work on feature X today. No blockers.” To which I pointed out that the "No blockers" part serves no purpose as if anyone had a known blocker, they would have already let the team know when it became a blocker, not wait for a fixed time of day. It is not coincidence that the last part isn't said today.
Today, I am here to share that the rest of the canned response is also useless.
Build camaraderie. Actually talk about the work you are doing with your teammates. These things can be beneficial and you'll still get the same non-verbal cues if there is something afoot. Don't waste valuable time on nothingness.
1. If I did, I would have told you a long time ago when it became a blocker.
2. If I somehow forgot to tell you a long time ago, I would have told you when I did my standup comedy^H^H^H^H^H^H routine.
3. If I still somehow forgot after all that, it doesn't matter.
I also have trouble getting back into the flow of where I was, but I think 30 minutes would be my max lost productivity.
I feel your assessment of 30 minutes to build the universe in the purest sense is fair, but I'm not sure it accounts for the additional friction involved. You might be the exception, but humans in general are known to avoid building up the universe, so to speak, if they anticipate an interruption. It takes even more time for the mind to accept that the time is right.
And so, all told, I think two hours is quite reasonable.
Of course that is in addition to all the other costs that come with standups. For example any fixed daily meeting kills the possibility of flexible working hours. That is one of the top perks for many developers and some developers are also much more productive working at non-traditional times.
The standup meeting can also feel like an inquisition, particularly for juniors or new starters. It doesn't even have to be the classic manager-holding-court effect, just whoever is leading the meeting having a bad day and speaking in the wrong tone. Again, there goes your productivity for that person for possibly the entire rest of the day.
If anyone reading this does use daily standups and everyone on their team wants to then that's great. Every team is different and doing what works for your team is what matters. But personally I have found that while sometimes useful points do arise during standups the benefits are greatly exaggerated. Valuable insights and awesome collaborations do not happen anything like often enough to justify all the downsides of the meetings, not least because IME the same information would probably have been passed on some other way and often faster in any moderately functional development team anyway.
Now every where I go some douchebag paranoid manager has established daily stand-ups because it makes them feel better. I resent telling people I'm working on a story we all groomed together and brought into the Sprint....it's right on the board: In progress, In Review, Ready for acceptance, Done. Clear as day. I'm still working on X, gonna work on X some more...everything is going great. Not adult-like behavior.
Given how common standups seem to have become, that probably tells us something. Maybe the typical daily standup as widely advocated isn't usually productive and it's actually some variations used by some individual teams that have been more worthwhile for those specific teams?
Fundamentally, that is also the idea pushed in software. A chance to talk about what needs to be done that day. But, in my experience, tech companies also schedule planning meetings. That is where it is determined what will be done for the next while (two weeks seems to be a common cadence) and after that the course is set. There is nothing else to talk about, unless someone has a problem, and when someone has a problem (assuming your team is functional) they reach out when they have a problem, not wait until a prescribed time 23.75 hours later.
That means there is no additional information to give in the standup, and thus this is likely the source of why standups end up being pointless the vast majority of the time in tech. The healthcare case, on the other hand, provides clear value.
There are likely some cases where tech teams suffer from no direction, void of an idea of what needs to be done before the moment it needs to happen. I imagine that overlaps with tech that is dysfunctional. A productive standup does not exactly seem like something to strive for, but if all you have is a bandaid...
https://www.washingtonpost.com/news/inspired-life/wp/2015/06...
I like it for two reasons, I go for lunch straight after so don't have two context switches. And it sometimes works as an effective midday target for me to try to get a ticket progressed before the standup.
Asynchronous standups avoid that problem, but I've never seen an async standup bring any engagement and ends up being nothing more than "I'm working on X again. Duh." which is completely pointless.
In fairness, as you are forcing a context switch for a standup, it is likely that you do work with unreasonable people.
Fine, catch me the moment I wake up. But good luck finding two team members who wake up at the exact same time each day. That never happens in the real world. No matter how you slice it, productivity is going to be destroyed.
What a gem. Whenever the next "silicon valley" is made I'm waiting for a character to say this. Simply hilarious.
Get off your high horse. You can afford an interruption or two per day.
Standup can be great if the responsibility across the team are spread out, but only at a lower frequency (once a week?).
It was glorious. Having record of all conversations for easy reference really did help build better software, as far as I am concerned. These days, everyone wants to do video conferencing, it seems, and half the time the job doesn't get done right because someone misheard something or forget what was said. It makes no sense to me.
I can only imagine that those who think voice communication is the best communication haven't tried anything else.
If that's all anybody ever says, then I'd agree. But, in practice, with my team, there might be one person with nothing much to report, but several others who needs assistance, want to demo something they've built, are ready to transition something to QA, or something else. If you aren't getting any of that in your stand-up then the team is "broken" and could likely use an open conversation about the meeting's purpose and value.
If it gets said at all, you should also agree. If the goal if your standup is simply to hear people talk, talk about what you did on the weekend instead. That will actually provide value to the team in building a better relationship with teammates. "I did X yesterday, I will do X today" provides no information potential or bonding potential. It is flat out worthless.
More realistically, if all you have to say is "I did X yesterday, I will do X today" it is best to not say anything at all. The goal shouldn't be to hear someone speak, but rather to achieve a business objective. Sometimes people won't have anything to contribute towards that objective and that's okay. Other times they will. They can speak then.
Team meetings can be beneficial. Having the team meet so that they can utter practically-gibberish canned messages to each other is not beneficial. On the bright side, I see (from the parent comment and many others) that we have finally dropped the equally useless "no blockers" routine. We're making progress here!
Assigning turns so that someone is forced to spit out that gibberish is nonsensical. Allowing someone the floor when they speak up when they have something to say is worthwhile, and something people do naturally. There is no need for an explicit turn where someone must say something.
> Regurgitating a, what is little more than gibberish, canned response when you have nothing to say is very different to speaking when you have something of value to say. That it only takes 10 seconds to utter that gibberish does not give it any more value.
I can't tell if there are two people on your account? Maybe you two should chat.
They technically could, but usually they are smart enough to realize that it is stupid to do so and reserve the act for when they know they have something of value to contribute.
If you are hiring stupid people, well, good luck. Someone uttering gibberish is likely the least of your worries, which no doubt explains why you haven't noticed the problem with it.
I never mentioned a canned response they were told to say. You've invented this.
That you seem confused about the subject now is... strange.
Sure, you can say that in 10 seconds. More likely even less time. That doesn't mean you should. It provides nothing of value. Setting a specific turn aside so that someone has to say something useless is even crazier.
People don't say things because they're in a book. If you want to work as a team and quickly update your team on what you're doing, then leaving your day free to do or collaborate as needed, it's an efficient way to do it.
You don't (seem to) say all this should not be communicated, nor that the team shouldn't be aware of it. You seem to only be concerned with the form of the communication; that it should be implied where possible, and where it must be explicit, should be done in point to point conversations throughout the day. That seems a) worse and b) bikeshedding.
There has been no mention of the topic of blockers in this thread at all, save my last comment. I am not sure where you dreamed up the idea it was central to the discussion, let alone a part of it in any capacity.
> People don't say things because they're in a book.
Not on their own accord. If there is social pressure, or even economic pressure, to take a turn they absolutely do. This topic is not based on a work of fiction. It was a tale about someone's actual experience. One many have had at that.
You must have hit the wrong reply button somewhere along the way.
> It's not best to skip saying ten words that explain you're fine. It takes 10 seconds.
And you replying saying it's as bad as saying I was working on X; I will work on Y.
So, pretty clear I think.
But, in practice, I'd prefer somebody gave a little more context than a simple "working on X" (assuming X isn't trivial - if it was, you would have finished it already) - what part of X... Design? Coding? Testing? Any roadblocks? Do you expect to turn it over to QA today or tomorrow? Nobody is working a vacuum and all our work intersects at some point.
If you have to put forth effort to keep the standup interesting, you are admitting that the people see no value, which means that you are meeting just for the sake of meeting. If you see value in meeting just for the sake of meeting, why not talk about what you did on the weekend instead?
Made me feel close to people I only knew remotely.
The reason it is called standup it was because the meeting was literally done standing, the idea was to force people to talk as quickly as possible whatever needed urgently and make them leave because they are tired of standing in one place.
What you are doing is some kind of daily meeting, but not a standup in any sense.
I think he's meeting 99% of the idea behind a scrum standup, except for standing up. So for some reason the lack of physically standing up reverts the 99% to 0%?
More people work remote now, it's not 1995 anymore ( history of scrum). As most things, scrum evolved. It's a guide, not a strict protocol/law
The idea is to have all the technical things in one time to eliminate interruptions later on, not to eliminate personal connections with the team. So what is a better time for the casual talk, since people don't have coffee breaks anymore? ( If everyone of the team is onboard fyi)
I kinda miss in person with the entire team. I see some people seriously slacking and those are the ones not really involved with casual talk too ( coincidence? ).
While many people are perfectly able to work remotely, it made the job of a eg. teamlead much harder to confront more difficult things. They can't notice the body signals anymore when a person's cam is just off ( and even then).
We used to have huddles at work, but it didn't mean that we were actually nestled closely together for warmth.
What made the meeting not-standup is the fact the meeting is not short. The fact people take time to talk about their daily lives, and other random stuff, means it is not a standup meeting.
I mentioned the original standup meeting was standing, because the point of it was force people to want to leave the meeting.
Paraphrasing, you said the reason it’s called a standup is because people are literally standing, to force people to talk quickly.
Then you said because of this OPs meeting wasn’t a standup.
But appreciate that isn’t what you intended.
This whole concept seems silly, to be honest. It seems like it's designed to pull out status updates from people who wouldn't otherwise participate and wouldn't ask for help on their own, but at a set schedule.
If I'm blocked, then i might as well drop a message in the group channel or eventually tag specific people who i think could help me. Or some people just choose to PM me directly.
The only worth that I'd get from a meeting with everyone together is actually talking about details that might be interesting: "Last week i ran into a race condition in the code, here's what it was, here's how i solved it and here's how to avoid them in the future," in lieu of discussions like that in the chat channel.
As a developer, i don't care if person A is working on X, Y and Z or is blocked, if i cannot help when with any of those. If management needs status updates, we might as well automate them with "Standup & Prosper" (https://standup.teaminator.io/) or a similar chat bot that gives you fields to fill out. Even freeform daily messages seem more reasonable than forcing everyone to do some silly ceremony.
Now, here's my question to you: what am I missing?
Slightly off topic, but I realize this is a subject I'd be interested in reading more about. Would be interested in suggestions in the same vein as Creativity, Inc. by Edwin Catmull?
I get it, not all are morning people. Please mute your mic, I really don't want to hear you yawn half a dozen times. It's obnoxious. If you're talking and you need to yawn, just mute for a second.
I know you're still working on this ticket (what's the point of JIRA otherwise?), just tell me if you need help on it or are blocked. That's more important to the team.
Standups over zoom or as a dedicated meeting are honestly a waste of time when people show up late or yawn just to go over mostly the same status every day. Just post your update in slack, let others know if you have any blockers.
I'm pretty much checked out these days, so I don't really care. What should be a 5 min exercise (90% of the time) turns into 20 minutes of pain. Others enjoy it as it is though, so I don't really care. Also every other meeting is similar nowadays too, way too lax and people seem to be okay being slow/lazy.
This is why I prefer standups to be right before lunch (back when you'd have lunch with your coworkers). People are awake and have a reason to not want things to drag on.
Of course, when one of your coworkers is on the west coast (and the rest are on the east coast), it's not lunch time for everyone, but it still tends to go quicker than if the meeting was an hour earlier.
We do it similarly to how you describe here -- we have a short intro (5 mins) before diving into each of us presenting. Each of us presenting may take 2 mins or take 30 mins. If one of us is struggling or blocked, we use this time to collaborate + pair program/debug.
Eventually, we get through everything and then go about our day. Sometimes (because I am the "lead"), I'll use the opportunity to ask questions about roadmap or other items that I need their input on. They're already distracted and not "in the zone", so chaining on the additional "meeting" works quite well.
Because of this, these are our only meetings every week. We get a bit of "water cooler" chatting in, we are able to unblock each other, and we are able to have a short iteration loop for re-prioritizing our work. (New tasks can be delegated by quickly going through the backlog)
The pandemic has really changed work, and I really feel like we're still iterating on what the best dynamics are for teams to be productive. Thanks for the insight into your team dynamic!
Before agile and standups were the hip thing, the norm in all places I worked was to have a weekly team status meeting. Those were great. Weekly is about the right cadence for this type of meeting. It gives you four days to deep dive into technical work without worrying about status reports all the time. With a week, you end up having something meaningful to talk about and listen from others.
Those chit-chat conversations are important and since they weren't happening by accident we made it part of the structure. I also encourage people to turn their cameras on during standup, just so we see each other once a day.
The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them. Beyond about 8 people (and maybe as low as 5) this means a bunch of people are standing around while other people give updates on things they don't really care about. I've seen standups with 20 people that last 45 minutes as the manager goes around the room, basically. That's not a standup.
It's even worse if PMs and other non-eng are there. Just, stop.
This brings me to my second point: size. Standups need to be small. No more than 4-5 people ideally. In an office environment these people should be in a pod of 4 desks (possibly minus the EM and/or TL who might have broader responsibilities) and they should be able to turn around and talk to each other, at which point you don't really need a standup anyway.
But I can't tell you how many times some EM has triggered crisis mode due to impending deadlines and we end up spending an hour a day with 20 people in a "standup" until the situation improves.
Edit: this is some bullshit inspired by rugby where you have regroup and change strategy as you learn about your opponents, what does that have to do with developing software I don't know.
[Citation needed]. I find standups and their context switching cost me at least an hour of productivity each day.
> Team communication has no value
If you want to communicate with your teammates, just use Slack and communicate instantly, why wait for the next morning's standup? If anything, standup slows down communication.
> Team leader having a chance to quickly gauge progress
You mean like the [insert ticketing system] board? Why do we have to waste time talking about stuff that's already being tracked?
This doesn't fully excuse it, but the more closely management is watching team-work-coordination tools like ticketing systems, and the higher the level of management that's looking at them, the more prone they are to drift from reflecting reality. That a standup is, by default, not transparent and recorded for anyone else to look at, is, in some organizations, and if they're run properly, most of their value. Granted, yes, that's a work around for a broader cultural problem and shouldn't be necessary, but the real world's a mess.
In practice, it turns out that you don't normally learn things about your competitors on a fixed regular schedule. As a result, I have yet to meet a daily (weekly, etc.) standup that hasn't devolved into "I worked on this, I will work on that." to escape the awkward silence.
No one wanted to tell them that it isn't cool, we are all burned the fuck out, the work load and pace are rediculous and most of us can't wait to fucking leave (I'm on the way out). They worshipped us, kissed our ass, were genuinely sincere, but they just don't get it. Oh well, the managers will get promoted, again.
Alternatively, it may be the case that your leadership team is relying on the Process to insulate them from their responsibility to promote the well being of their employees, and from the loss that naturally follows when an important member of a vital team leaves the company. Rather than viewing their team as a resource to be nurtured and developed, they view you as a liability. Such companies instead develop their Process to such an extent that any member's agency and responsibility is effectively zero. Team members act like hamsters in a wheel, spinning endlessly, consuming an infinite treadmill of tickets and producing result units in 3x to 10x the amount of time it would take an empowered, impassioned developer. These inefficiencies are viewed as acceptable, even inevitable-- so deeply do they fear their employees taking meaningful ownership of their work.
Many such cases.
That can easily happen. On the other hand, where would you expect an EM to ask individual questions that matter to them ?
My experience as an EM is that this really depends on the team, including domain and maturity. For example, if you have a team of mostly junior members, well, the "micro managing" version of standup is often useful. It gives a way to see how people can communicate their issues to other team members, especially when you're new as an EM.
For more mature teams who don't have issues, I generally don't do standups, unless there is something critical and the project priorities at risk.
What seems pretty universal is the amount of information i share nobody cares about and the amount of information other people share that i don’t care about are both quite high.
It serves as an opportunity to be bored and frustrated for a half hour each day and does a rather good job of interrupting my daily flow.
I think a key to a needed standup is a small group of people actually working collaboratively on something whereby the shared information is actually good to know.
I am though a fan of short meetings of any topic where you literally are standing for the meeting, it seems to change the quality.
Yesterday, I asked a team member if they had QA'd my project. They said, "oh I wasn't expecting to QA your project."
Yet I told them in the standup that I needed them to QA the project and I tagged them in a story. Clearly paying attention...
During standup, I've also had people say "colmvp, you can go next" despite having already spoken.
And near the end, we often don't even remember who hadn't spoken.
I feel like standups work well for small teams, but in larger teams it just feels like it becomes impersonal and more of a thing to do to make yourself appear obedient to your manager.
I'm not a 'process guy' though so I have no idea what to replace these things with, if anything.
After all that there are still more architectural discussions, meetings to clarify stuff. And then we break interfaces every other day. Reason given is "way of the agile". I can't speak in general, but it seems that we couldn't design a solid software for the long run if our lives depended on it anymore.
I wonder what kind of processes industries like aviation, defense, and other high stake industries have?
Lots of up front planning in great detail with timelines and details dependencies. Lots of understanding how schedules slip. Some space systems go to the levels of planning for a number of bugs and if the result is off high or low, it is a matter for investigation.
Also, no daily meetings (unless culture has changed since I was inside a while back).
The most important things are an advanced method of requirements generation and change management.
It seems like almost everyone in the software industry is just making shit up as they go along which is... themed to the right way to do things but not actually doing it. Cargo cult processes.
I can confirm that the big management consulting firms are selling modified "agile" processes to the MIC and the US military itself. I suspect that means they're selling them to most large orgs with that sort of culture.
I don't know whether they're complete bullshit and don't actually mean much as far as how things actually operate—hopefully that's the case. If it's actually changing anything and not just shuffling around some names for processes, I assume it's making things worse.
> "The most important things are an advanced method of requirements generation and change management."
Makes perfect sense seeing how those wrecking havoc in far simpler software I'm working on. Thanks very much for sharing.
It is absolutely useful when you're doing a 10 billion dollar project with dozens of contractors when your customer is say, the Army.
The way I've seen all of these things done in commercial software is like middle managers heard about requirements in an elevator while drunk and went home and decided to implement them. i.e. nobody know at all what they're doing, and they're trying to accomplish something they've heard of but never come close to experiencing done well.
I feel the same way about Agile. It came from the way a group of smart effective people worked together and decided to share... it's being implemented almost everywhere by people who are looking for a set of guidelines to follow and don't at all grok the point of any of it.
That's just this season's excuse. How often have we seen some change that is obviously going to make things worse for a lot of individuals being justified because it's supposed to foster better team communication and so make the overall unit more productive? Open plan offices, frequent meetings, ever shorter cycles for everything, ever less up-front thought before diving in, real-time messaging on all the time, etc.
I wonder how many of today's developers, including the relatively senior ones, can even remember how productive you can be if you work out a clear brief with whoever else needs to be involved and then you are left alone to concentrate on doing the work for a while, where "a while" means at least a half-day and possibly several days.
https://www.pivotaltracker.com/help/articles/terminology/
> The Icebox panel contains stories that have not yet been prioritized. If you want to add a story and keep it “on ice” until you’re ready to prioritize it, click the + Add Story at the top of the Icebox panel. When you’re ready to prioritize the story, drag it into the Current or Backlog panel. Icebox stories are in the unscheduled state.
In the one place I was in that did Scrum, the org had rules:
1. The "Scrum Master" is external to the team.
2. If the manager behaved this way, the Scrum Master would kick him/her out of the room - permanently if need be.
Worked well, and realistically, managers don't really want to be there.
It's even worse if PMs and other non-eng are there. Just, stop."
A lot of managers or PMs really can't be allowed into a standup. Especially if they show only from time to time and take over the meeting.
1) If the team was like, "our team on this project is tiny and we all sit next to each other, so we don't need them", or "we'd rather do Slack messages for standups, on this particular project", he'd let that happen without a fuss, aside from ensuring that any communication he needed from it was still, somehow, happening. So it was still team-driven and very flexible.
2) He was very disciplined about not turning them into project status meetings, or making standup messages take the form of status updates.
[EDIT] I should add that the benefit to him was that he got to hear a lot of unvarnished truth about what was going on, which micromanagers don't get, because he was at all times, in the face he presented to the team, on "our side". That put him in a much better position for polishing up the information he had for consumption outside the team(s), which benefited us, too. He might have questions or something, and it's not that he never pushed back on anything, but he let standups be standups, and kept that stuff separate and as non-confrontational as possible.
I do not understand the mindset that goes into thinking that somehow a person is 1. Not required for a meeting and so can only attend on occasion and 2. If present must drive the entire thing.
I guess in theory they might think they are improving things if they assume it is an unguided, unfocused disaster with out them, but in my experience it is the exact opposite: a focused, relevant, quick stand up without vs a meandering, drawn out, ritualized boilerplate, "explain to the PM stuff everyone else knows" meeting with.
PMs can be genuinely useful too. They just need to use the most important words in their toolkit: "you 2 (3,4) discuss offline/afterwards, next person". Not to be used if people are casually chatting, but to fix that problem of 2 people having a conversation while 6 others listen for no reason.
This can be badly managed, as is the case in your examples. You're right that there shouldn't be more than 8 people and it definitely shouldn't take 45 min. 15 min max and if there's more to quickly discuss the people involved should stop and continue after the meeting. The situation you're talking about with crisis mode sounds like planning rather than standup and if you're Engineering Manager is declaring crisis mode and hijacking standup each day to spend an hour planning then you've got major cultural/organisation problems. In that case standups are just a symptom not the root cause.
There's also the social aspect, which other comments have mentioned. I've always found that underrated, though I was recently reading about how some national cultures rate it a lot more than others. For me as a Brit I always feel far more comfortable communicating my colleagues when we get on socially and we understand each others sense of humor and communication styles. Taking that time to banter for a few min each morning is massively important for improving team communication. And during lockdown and WFH it's been even more essential.
Addressing standups as the sole issue completely ignores the holistic factors that influence the outcome. If a team is bored, undercompensated, overworked, undersupervised, then they're going to deliver shitty standups, and those standups will be a waste of time. When the participants are eager to provide a handoff of knowledge and prompt eachother for interchange, then you get the good standups that leave people racing back to their desks to build off of that synergy.
What are you supposed to say then?
Daily is way too ofent to have anything interesting to say. It is a low effort way for the manager to keep track on things and make people feel stupid for not doing progress in the maner the agile scoreboard dictates.
On the other end, having to report things based on a timeframe that tight relative to the work done will quickly devolve towards finding things to report on, no matter how unnoteworthy. Teach people to speak up and show noteworthy things instead and have a bit of faith in your other metrics and report pipelines.
Nobody does this, they do it immediately, at least all the places I've worked. I need help, first I try to figure it out myself, then when I'm stuck or want to make sure I'm doing it right, I ask the owner of the code I'm working with. This makes standups not only redundant (information has already been shared) but distracting.
>But, I do see the point of a daily sync up for team building, especially for remote teams.
I've found it to be a morale killer more so than a morale booster. Fuck I gotta stop what I'm doing for this stupid standup, or I'm not gonna do anything because the standup is in 45 minutes; I'll just get distracted.
I was once at a place where you actually stood up and the standups were 45 friggin minutes long. Total waste of time and I was so demoralized after it took me 30 minutes just to decompress and get stuff done.
They would be slightly better if done on M-F-W or even more so on T-TH. Once a week meetings for about 30 minutes with biz then 30 minutes with dev works great for our team.
(d) creates a daily source of anxiety for developers who doesn't handle public speaking well. Which is a lot of them, but it is a shameful thing to admit.
Instead I see someone who questions the utility of this particular daily ritual. If others on the team feel the same way then it's more like they're calling the emperor naked.
Also see you working on one large project or a bunch of small projects ?
Which work orders? Which PRs? How much progress? Are they harder than expected? Easier? Any blockers? Anything that could help?
Standup isn’t just for managers. It’s for ICs to also communicate their needs, obstacles, concerns, or even just give everyone a heads up that a certain task is more difficult than expected. If you’re just searching for the bare minimum to say to get your manager to move on to the next person, it’s a waste. It’s only a few minutes, so take advantage of it for some quick bidirectional communication.
A plain old developer, who does not manage other developers.
In other words, if you have plenty to talk about in your stand-ups then you are doing something wrong. Which is the point of Scrum, this fixes communication issues, but your team really shouldn't need this.
Yes. The other difference is that football has absolutely nothing to do with software development whatsoever, so why organise as a football team, that just seems like a bad joke to me.
If only this we're always true. In reality your teammates can be busy which means queries to them will often go unanswered. Standup is the only time to guarantee responses from busy people on the team.
Tackle: I'm going to block. No blockers (err).
Tackle: I'm going to block. No blockers (err).
Guard: I'm going to block. No blockers (err).
Guard: I'm going to block. No blockers (err).
Center: I'm going to snap the ball then block. No blockers (err).
Running back: I'm going to run. No blockers.
Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
Quarterback: I'm got to receive the snap, then do something with the ball. No blockers.
Tight End: I'm going to block. My blocker is that my shoe is untied.
Guard: You should tie your shoe.
Guard: You should tie your shoe.
Running back: You should tie your shoe.
Quarterback: Would you guys STFU, we've got stuff to do.
Tackle: Daily standups are important for morale and communication.
Referee: Delay of game, 5 yard penalty, repeat the down.So it's basically impossible.
Whenever someone says "This [meeting | standup] could have been an E-mail!" I respond "So do you read and respond to your E-mail?" I love asynchronous, but the entire team has to put in the effort to make it work.
If the only time ICs communicate any of that stuff is at a set time each morning, then something is already seriously wrong.
Agreed, It's much more productive to simply approach some of your coworkers, or write in a team chat after the daily. Mentioning problems in the daily just adds pressure and stress with no benefit.
We are talking about daily standups. In all likelyhood, you don't encounter blocker that often. If you have frequent blockers, then you have larger issue. In most days, I don't need help at daily standup time. If I needed help, I asked before and did not waited for standup.
> Are they harder than expected? Easier?
What would that be useful for? Like, I do quick venting sometimes, everybody does, but I am not under illusion it is useful for others.
Sometimes things progress without any surprises or blockers. A meeting just for the sake of having a meeting seems like a waste of time and effort.
The ones we already discussed were in progress. Did you expect it to magically change overnight?
> How much progress?
Paterio already went over this with you. I am 80% done. Tomorrow I will be 80% though the remaining 20%. The next day I will be 80% done with the outstanding 20%.
> Are they harder than expected?
Yes. It would be far easier if you didn't interrupt me.
> Any blockers?
If there were, and I haven't already told you, why would I tell you now?
> Anything that could help?
Not bothering me until I am at a stopping point.
--
What's the purpose of the standup again?
Daily stand-ups are for coordinating with the other devs. E.g. "It will take a couple extra days to do this backend API that you are waiting for", "I'm a bit stuck, anybody will have free time today to pair program?", "Who is able to drop their low priority task so that the high priority one gets done on time?"
If you're on track and don't neet anything, just "no updates today".
The first 25 years of my career as a programmer we never had daily stand-ups, had never heard of them. We shipped.
Something about all the "process" that has crept into the job over the last decade or so has really turned me off.
There's a huge difference between a "daily progress meeting" and "sensible development". I too have seen a lot of process creeping into things and I'm glad I'm getting close to retirement.
Seriously, it was only "main" when I started at Apple 26 years ago. Our version control was such that when someone wanted to edit a file it was "checked out", locked to others on the team, until it was checked back in.
It worked surprisingly well (obviously no merge conflicts for one thing). I doubt anyone would suggest going back to something as simplistic (but I have to admit Git feels way too complicated than it should at times).
"
Why do you need standups for this? They should talk to each other directly.
I have been to a team where X would need help on something that Y has solved in the past, Y does not care to listen in the standup and volunteer to help, and i had to ping him “Hey Y you have resolved this in the past, care to help X after the standup?”
Shitty standups go bidirectional ways. Managers can make them terrible, but devs can do that as well.
There are no bad teams; only bad leaders. -Jocko
Took me a long time to buy in to this but it's 100% true. Sucky standups are the direct result of an ineffective leader - whoever that may be.
And it makes sense- even if the team is "objectively bad", a good leader will help transform them.
I agree with your sentiment that it's a problem of skill and motivation - but that said, the usual problem to solve with any process is: how do you make your day to day operations as efficient as possible given the level of skill, codebase quality and motivation you do have, not the one you want. Developers (on average) are only average. Code bases aren't great. Motivation will vary.
So it's a chicken and egg problem. If the reality is that the developers are tired underpaid undersupervised and undermotivated. All that could change, but it would take time. The process happens now.
They will only do them if they're dictated by the company, or the the team members are unable to work and communicate independently and requiring constant micromanagement. The latter is usually a case when the team members are provided by the outsourcing company, or they're some kind of "team extension".
In that environment, the individually rational strategy is not to reveal much, look busy, don't stick out much etc.
So, people end up listening to the newly minted scrum "master" pontificate on value or the grooming habits of their pet.
In a healthy environment, standups are developer-to-developer conversations. Dev A says "I am having a problem solving X" or Dev B says "I found out that 3rd party service API we are relying on was suddenly phased out, we need to rethink the entire approach", and people can figure out a quick response. Sometimes the solution is pairing, sometimes it's a change in other plans.
Public information (who is working on which ticket, which PRs are open etc) do not need to be repeated. Standup is not a place to list accomplishments: Of course, if a particularly thorny problem has been solved, that calls for celebration, but 30 seconds is more than enough if nothing unexpected happened since the last time.
I do prefer in person synchronous standups so that an impromptu discussion of how to handle anything unexpected can happen with everyone's input.
Your blocker can be used by another opportunist to talk garbage solution. It makes the opportunist appear as if they are doing something that the blocked engineer isn't doing.
The blocked engineer could counter - but it will quickly devolve unless one side concedes.
Standups are only a tool for micromanagement - nothing more.
Yes, that's the reason. If you know the work you do doesn't matter, you're going to get subpar results.
I won't speak for everyone, but the work I do doesn't matter. I do the work to get paid. The alternative is not get paid. I don't really have a choice. Something that I would consider matters more: building something with my hands like construction, electrician, trades, grocery workers, social services, train workers, factory workers, agricultural workers, bus drivers, etc. That stuff matters in my mind more than whatever widget I'm being paid to make. Those jobs are what keep society moving.
I suspect that for most people in tech, most of the work people do isn't benefiting society and the masses in a good way, it's just a way to make more money for other people. So, it's natural to not believe that their work matters. You have to convince yourself that it matters.
With that said, the solution is a restructure of society that encourages and reinforces work that people find meaningful. No little scrum standups will change any of that. If you truly believe that what you do is meaningful, then you'll get better results. Along those lines, you often hear the question, "What would you do if you didn't need a paycheck?"
Upvoted, but, I've seen non-shitty standups where the effort people put into to make stuff work was valued both by team mates and management and that did not involve venturing into Marxian territory.
Agreed, but those people must truly believe that their work matters.
The alternative is to switch to paid work that does matter (to you). If you lack the skills to do work you find meaningful, then learning those skills is the next step.
Your comment seems pretty thoughtful overall so I'm wondering if I'm misinterpreting the world view you tried articulating at the beginning.
I'd extend this to the very existence of rigid roles such as 'project manager', 'qa', etc.
We've traded the existence of healthy teams and healthy individuals in exchange for predictable insert/delete commands of any team member by the management caste.
That this destroys morale and human's natural desire to connect and form lasting bonds doesn't seem to bother the management caste. I guess why would it, it's modelled after master/slave or aristocrat/pleb relationship of the past.
I don't go that far. Project management, qa, ops, and programming are largely disjoint skillsets.
One of the biggest reasons to time-cap it is that overall...it really isn't a good use of time.
On the other hand people are far too over the top acting as if it's the most awful thing they've ever had to deal with (it's 15 minutes and in most cases the only meeting you're going to have that day). People who can't tolerate a 15 minute chat with their team tend to have a lot of issue working well with others in my experience. The "I can't spare 15 minutes" mindset tends to live with people firmly in the "all about me" world.
It can be hard to get out of the bubble of the work that you are doing.
EDIT: I totally get bad scheduling that interrupts flow time. IMO either beginning of the day, end of the day or just before lunch is the ideal time to do it for that reason. Time zones also complicate it.
People need to emphasize that the problem is the bad scheduling of the time slot rather than the 15 minutes itself. Also, it's a good idea to make skipping it periodically totally acceptable.
In other words - micromanagement.
It's supposed to be like a restaurant where all the waiters share tips. It is in everyone's interest that one, all customers are being served well and two, that all waiters are pulling their weight.
No. There may be occasional cases where that's true, but it's almost always better to get another pair of eyes (and accompanying different experience) on a problem. There is some great software that comes from solo devs, but most commercial projects are simply too big for one person to accomplish in the time necessary. Business software is very much a team sport.
Why would I wait for some meeting the next morning?
You wouldn't. Why are you under the impression that scrum prohibits communication outside standup?
Daily scrum is a floor on communication, not a ceiling. It guarantees that focused communication happens at least once a day. Sometimes people miss slack posts and emails. Scrum makes sure the entire team is aware of progress and blockers. It's a tiny slice of the day when it's done properly.
Except the requirements for transparency is only for the developers, which makes it feel very degrading, all of the other people in this meeting, the leads, scrum master, product owner, ux etc, don't say anything about what they're doing, and they have no board with their tasks either so no transparency whatsoever.
How long do you think your manager should go without knowing what you're doing?
A weekly status update is good enough for regular status. I must mention that if you are looking at status reports from the time dimension, you have already failed.
The manager should cultivate an environment where engineers and managers talk in small groups at any time. There is no need for a standup for this. Everyone can decide for themselves if they need to spend time with someone else. The manager can decide for themselves if they need to chat with a report instead of taking away time from all reports everyday.
Of course, this would require the manager to do the work to chat with reports and figure out what's going on.
That is not the team composition most people are working with. The median developer in the industry only has a few years of experience.
I once suggested that instead of standups developers write an end-of-day comment into whatever ticket they're working on. This would enable managers, others, by filling the blanks that status change/VCS timestamps might not tell you. People just looked at me like I was crazy when this would be even more efficient.
Don't like the Burndown Chart over the course of a year? You can literally look at the Sprint Reports to see what issues/assignees are spilling over a course of time. Managers have all the tools they need but that's not the point of this stuff. The point of this stuff is to reinforce that they are the boss. They could even make the SCRUM Master's job actually useful and be responsible for this kind of research but I've yet to see a SCRUM Master be anything but a proxy for this antiquated posturing.
Just as much as there's a general fear that labor is hiding behind process, so is management.
Most of my teams problems with Agile/SCRUM come down to skipping steps or not following best practices. Once we fix those, it gets better.
If you read the agile manifesto, there are no specifically prescribed steps or rituals, and in my experience, most teams implementation of scrum is entirely counterproductive to actually being agile. The core tenet of being agile is essentially people over process, and things like daily stand-ups, extremely formulaic retrospectives and backlog grooming meetings do nothing to empower the people and allow them to be truly agile.
A previous team I was on had standups at 10 am. This meant even if you wanted to start working earlier and get heads down on something, there wasn’t much point. Add in the typical context loading time and that meant you weren’t really able to get going until 10:30. And guess what? At that point, lunch is an hour and a half away.
And now with no commute for most of is, it's still somehow difficult.
10AM already is before my definition of "first thing in the morning".
Maybe we should just kill the synchronous status update meeting altogether and avoid conflicts like these?
I am not denying genetic traits, but like with most things, it's not the only factor.
Most of the time there's no managers and it goes like that:
- What you work on yesterday?
-- I've worked on automated tests X, Y and Z, had a few meeting with an analyst to validate the tests.
- Did you had any issues.
-- No / I had a few issues about the X process, is there anyone that could me, I have a few questions ?
- What are you doing today.
-- Today I'm going to work on X Y Z with XX and I have a few personnal meetings about X Y Z with Team X for Project Z.
It's awful when it's interrupting valuable flow time.
> in most cases the only meeting you're going to have that day
If only that were true!
We've stripped out standup completely bare. We're fully remote and use JamBoard. There's no going taking turns to give long-winded updates that causes people to tune-out. If you have an update, you must put it on a sticky, otherwise there's no need to talk. At the end of standup, the devs will discuss what we're going to work on for the day. We only talk about what we're working on with the full team if things aren't on track and we need help from product or design.
As someone with narcolepsy, your daily ritual is everything that makes my life horrible.
I got lucky not to be a part of companies with this mindset now. Every other company was like this, and it was truly a miserable thing. I remember the secretary at my first job calling me every day whenever I was running slightly late, and one of my coworkers joked that someday he'd sabotage that phone.
The whole idea of it being "respect" is just bogus. My inability to put my ass in a chair at 9am every day has nothing to do with how much I respect you, the team, or the company. People are just different, and work in different ways.
And that starts with a conversation (like the thread OP implied in their answer). Hopefully the conversation would then avoid any pressure on you in saying that the meeting doesn't work for you.
If a company isn’t set up for that, it’s hopeless. You’re asking to be more special than everyone else, and everyone else is going to notice.
Presumably you are there because they wanted you there. Making a change to accommodate one person shouldn't be a big deal. I've said it a few times in these threads already, but processes should never be set in stone. You should always assume your processes will change. It doesn't have to be a huge change, just finding something that works for everyone. Of course, there is always going to have to be compromise, but the conversation should be allowed to be had.
I don't see why you couldn't make that ask.
That's exactly the point I was trying to get across.
I was expressing what standup is to my team and why we bother doing it at all, not what I think it should or must be. The point I was trying to make was around being intentional around the team's behaviour. If everyone wants show up whenever they want to, that's fine, let's just call it what is so that no one is wondering what the rules are. My team decided that we all want to start the day at the same time, so that's what we do, but processes aren't set in stone and this can change at any point. For example, if you were on my team, then we would change our process to accommodate you.
It sounds like you worked at incredibly toxic companies.
For a while, I had a 9:30 meeting. It existed as a direct result of people hating the previous 9am meeting - no big deal, a few team members complained, I moved it, and everybody was happy.
As the parent mentioned, there should be respect, and seem they didn't have any for you
I'm sorry you're in a shitty situation, but it's unfair to blame GP's perfectly reasonable ritual for it. It's your narcolepsy that makes your life horrible, not their ritual, and it's quite unfortunate.
If you read the article, it advocates asynchronous conversation, and 'micro' updates.
In other words rather than forcing people to update at a specific time, that whilst convenient for you, is not convenient for all we should consider allowing people to do what they need to do and empower them to respond appropriately.
This is why OP mentioned that _your_ daily ritual is hurting them, because you are _forcing_ them to adhere to what works for you at _their_ expense.
It also goes both ways, but we cannot ask one to always considers us, and allow their needs to go unattended because it doesn't fit our narrative.
Technically true, but it's not like the "ritual" is some weird obscure requirement. Showing up on time is pretty much a default requirement of society. At least they're in a field where being slightly late results in embarrassment instead of firing.
The usual advice is to find a different job with actually flexible scheduling or night shifts, for good reason.
Our fixation on “normal” makes people resist getting help that would make their lives easier and possibly make it easier for them to be “out”.
You have no idea what your coworkers are struggling with. I found out one had stage 4 cancer by asking why it was taking him so long to fix a problem. I’ve had exactly one coworker in >20 years who was open about being on the autism spectrum, and people were weird about it.
Nobody wants to be defined by these things so they don’t bring them up.
You don’t need “in general the reactions” to be positive, you need 100% of your bosses and peers to have a positive reaction, and you need to be able to predict it ahead of time because you can’t but that cork back in the bottle. Developer communities can be small. That information could affect future employment opportunities as well.
It’s worse than that. The insistence that 8 am or 9 am indicates a “respect” for the team is in fact disrespect for the team.
It says we don’t give a shit about why it’s hard for you to be here at 7:45 or 8:45 (because doing a standup cold is bad too), do it anyway.
It’s a show of power. And a petty one at that.
Now, I only work in teams and projects that are pointedly non-Agile, non-SCRUM, without anyone holding a title of "SCRUM Master". My love of software development is coming back, and it really feels great.
Every time I interview for a job, the only time I permit myself one foul-language word, is when I make the point that "I'm not going to work in an Agile team, I'm too old for that shit". When what follows is an awkward, silent few moments, I know it isn't going to work out. When what follows is enthusiasm and agreement (happening more and more these days) I know we're on the right track to do great work together.
What we've seen is the birth of a new profession, "Project Manager" (Agile/Scrum); and its filled by a ton of people who read a travel brochure size sheet of paper detailing how to be one and that's how they all operate, all while demanding outsized pay for the "skill" (really if they were paid minimum wage that's still too much)
They take zero consideration for team structure, working dynamic, the business that the org is operating in and tries to shove every uniquely shaped team into a square peg.
What's more annoying is that I've seen some hardcore PM run shop promoting project managers into people managers, often overseeing highly technical teams while they themselves not being technical which leads to all sort of pain and cost to the the ICs they oversee.
Agile has managed to 'codify' middle management, very poorly.
We lost one on our team and immediately we were worse off. Having someone who can unblock engineers by making and updating trackers, knowing who to talk to to get projects unblocked, and having a larger view of things sped us up so much. (Which I'm sure is why he got ferreted away to a very important project for the company ;)
I always wondered why small teams need anyone dedicated exclusively to be a "scrum master". Outside regular meetings and checking the project board once or twice a day, what is their purpose?
I would much rather have another dev in the team.
In asynchronous mode, I would have taken the five minutes before replying to perform that confirmation step and all would have been right with the world. I would have been far more happy that my time wasn't wasted and far more productive in the end. Not to mention that there would be written record of the answer, which is always useful later when the same question arises. So much valuable information is lost in the traditional standup. It is heartbreaking.
I know, it is ultimately my failing that I don't have the full knowledge of the universe stored in memory at all times and often say the wrong things when put on the spot, but then again, a well structured team is designed around the failings of people rather than trying to shoehorn failing people into a fixed structure.
I used to be there myself but changed my mind after years of seeing programmers who complained about having to do too-frequent status updates go off into the bushes and take their code off the rails for weeks at a time to build the wrong thing.
While standups are indeed a context switch and feel like they sap productivity, there’s nothing less productive than people who run off quietly and build something you dont need or want, or people who over-engineer things because they’re worried about requirements they don’t have, or sometimes just to flex. The scale of productivity loss that I’ve personally witnessed of programmers not talking things out properly is so much larger than the 30 minutes it takes to sit through standup, they’re just incomparable.
Standup doesn’t automatically fix this issue, but it seems to have helped, from what I’ve seen.
In my first job in CG films, there were 1-hour dailies twice a day that I was expected to show partial progress. And it might take 30 minutes to render & prepare for it every time too. It could use up half my day sometimes, and I fought with the producer about it. I was writing code to control crowds that wouldn’t be ready for weeks, so what was the point of showing every day, or of being present only to watch other people’s updates? There’s a balance for sure, but years later I feel like I was in the wrong, and I see the value in showing partial work often. It’s because people often don’t agree even when they say they do, language is way too ambiguous. So a planning meeting once is never finished, you have to keep agreeing on the goals over and over with tangible results until it’s finished before you actually know if everyone’s in sync.
Coming from a perspective of managing distributed teams: Asynchronous communication is a decent way to replace synchronous standups if (and only if) everyone involved can respond in a timely manner and is willing to schedule a synchronous discussion when necessary.
The pitfall of asynchronous communication is when team members start trying to force everything to be asynchronous. In many cases, getting on a call with someone or even just taking 10-20 minutes to have a synchronous chat is all it takes, but the team needs to be willing and ready to go synchronous when necessary.
Purely asynchronous environments sound great when you just want to go heads-down and work on something, but the downsides become obvious when people start getting blocked on responses from other people for sometimes days at a time while async emails ping-pong back and forth instead of a 10 minute conversation that could clear everything up.
Of course, the other extreme is also bad: If everything is forced into synchronous conversations over chat or calls then you’ve given license to the team for everyone to disrupt each other all day. There needs to be some guidance about what’s appropriate for communications and interruptions as well as some authority for individuals to push back and delay meetings that interfere too much with their work.
I have only found that to be beneficial if you work with horrible communicators who struggle to get their thoughts out without repeating themselves in a multitude of ways.
In the age of testing candidates to death, ready to throw the baby out with the bathwater if they cannot calculate how many golf balls fit on a bus in O(n) time using a reversed linked list, why are you hiring horrible communicators in the first place?
Having had the luxury of once working with a team of effective communicators, the idea of needing a 10-20 minute call would have been laughable.
That's true, that's just around 99% of the people, while it's useless for the 1% that can't communicate even with synchronous audiovisual aid.
True, although it is a learned skill so the only reason that is the case is because they haven't taken the time to learn. Which is fine. But, given the tech industry's obsession with hiring only those who have learned rare skills, it is an odd exclusion given that this quality it is arguably the most important facet of effective team software development.
This is the true measure of what makes someone a good team member.
> the team needs to be willing and ready to go synchronous when necessary.
Who gets to decide what counts as "necessary"? This philosophy sets the value of my time and concentration to 0 relative to the person calling a team meeting.
(posted from a throw-away account)
"How is this task going"
Putting devs on the spot and demanding updates like you'd expect from a child doing their homework or completing their chores doesn't feel like team building...it feels like babysitting.
You have to open with "Today I commit to..." and then the following day you had to start with "Yesterday I committed to ... and I achieved or did not achieve my commitment because ...".
This was followed up with a new commitment for the following day which was again followed up the next day, five days a week.
It's horrible. I hope one day I can be part of the kind of agile which hasn't been weaponized against developers.
In my experience agile works when it’s led by developers and not management.
Lack of stand ups makes it safe to hide for multiple days.
Short of reading the Shape Up book (which I will probably do), the article is weak in action and reason.
We have two daily standups, one in the morning and one in the evening, each about 30 minutes or more. Moving from a company with no standups to one that treasures meetings so much has been a killer on my soul...
Thankfully, this BlogPost has concluded that, not only is three the correct number of waves (and yes, the number of waves shall be three), but it has also backed up this conclusion with strong evidence from the paragons of innovation and efficiency, Ford and GM. One cannot disagree with how great market segmentation works for GM, selling the same truck under both Chevrolet and GMC nameplates, or the same SUV as a Chevrolet, and a Buick, and a GMC. This cannot be wasteful or driven by internal fiefdoms. Because, look at Ford, they sell Ford trucks under both the names Ford and... well, uh, okay, that's it.
It's indisputable that Ford building the Explorer in the 90s, and then begrudgingly allowing Mazda to sell the same SUV under the Mazda name as the Navajo, but only with 2 doors, is a killer innovation in market segmentation leading to larger overall sales, rather than a I-scratch-your-back-you-scratch-mine agreement that gave Mazda a way to quickly get popular SUVs in the showroom in order to drive foot traffic and (hopefully) sales.
But seriously, I get that cars are segmented by lifestyle these days, and the "same car under different badges" was just a crappy example. But why does everything have to be a groundbreaking innovation, and allocated to a wave? Why not just say "there used to be only a couple of different cars because they were expensive and hardly anyone bought cars, and variety was an obvious and inherent outgrowth from increasing sales volume and customer demand"?
Best approach I've seen is an asynchronous yesterday/today standup via slack. If you keep it in a separate room there is also no obligation to make the update at a specific point in time.
With asynchronous updates you can carefully examine if someone is stuck and has made the same updates N days in a row, or if someone is making rapid progress.
Did you have luck not falling into the "Yesterday I worked on X, today I will also work on X" trap in desperate attempt to find something to write? Synchronous standups regularly suffer the same problem, in fairness.
Best approach I have seen is to simply not have meetings until there is something worth meeting over. They can actually productive when they have intent behind them, not because the calendar said it is time for one.
Usually the "yesterday I worked on X, today I will also work on X" for me are a sign that I need to grab a second team member to get a second set of eyes on something.
That is if X is specific enough, of course - but if working on something larger, I think it should always be if the standup message is to have any usefulness at all.
So I'll try to always write something more in way of "Yesterday I was working on X, so I made X_1 and started on X_2, but had problems so I've skipped over to X_3. Today I'll be continuing working on X_2", with the numbered ones being subtasks or subsets of X.
I'd probably do the same on actual spoken standups, but this is a kind of a meeting that could easily be a slack message, so I prefer slack :)
While I admittedly do not entirely understand why it requires writing that down to come to the realization that you need help, if that is what works for you, more power to you. But is external communication necessary? Writing that down in notepad.exe seems like it would trigger the same in you? Why bother your team with noise?
Once you have realized, letting the problem be known to your team makes sense, sure, but that does not seem like something that happens on any kind of regular schedule. Pre-scheduling your chance to let your team know that you have a problem seems unnecessary at best. I've certainly never met a teammate who is unwilling to help with a problem without being given advanced scheduled notice, and I'm not sure a person with that kind of attitude should be on the team in the first place.
I do like knowing what others work on, as we're all remote. Our project owner likes knowing what we're working on as well.
If it was a daily zoom meeting I'd probably be against it every single day. As a slack message in a separate channel it's not really a bother.
> why it requires writing that down to come to the realization that you need help
It helps avoid tunnel visioning on the problem too much, I guess. The standup provides a chance to do so every morning, why not use it?
It's not like it's the only way of me communicating with the rest of the team and asking for help, not sure what ever gave you that idea...
Instead try this:
Standups are time for a team to plan their day and coordinate on how they will tackle the issues on the board. So, go from right to left on the board and discuss each issue and what needs to be done to finish it. Maybe some people can team up today. Maybe someone else has expertise regarding some problem. Maybe the team decides to drop an issue and give prio to another. etc etc.
That's all.
None of this "what I did yesterday, what I'm doing today" bullshit. No one cares. Stop it. Also, you don't need any managers to be present. The standup is for the benefit of the team. No managers need to be involved.
Try it. It is much much better.
In what universe did this happen? Certainly not ours.
If I were to lead a team and help develop the processes and methodologies we were going to use, I'd still have a form of standup but it wouldn't be the kind of standup typical to SCUM methodology or anything like that.
My idea of a valuable standup would be for the team to get together for a short while in the morning to shoot the shit for 10 minutes at most. Nobody has to talk about their work, although it would be a good time for team leads to introduce intel about new or changing priorities. If team members want to talk about their work or challenges they are facing, then all the better. There would be no pressure to attend them all the time, or to be there on time. If people aren't showing up to them enough then that's a sign that they aren't valuable in the first place.
Why treat standups like something out of public school? It just ends up turning standups into an exercise where students are coerced to attend even if no value is being provided. Such standups quickly turn into status updates and an exercise in subordination for many of the team members.
What are you working on today?
What are your blockers?
Any conversation which needs to happen is managed in threads. It's a win for everyone: No more mid-day interruptions, a good well-documented log of work, and the timing is flexible (submit by 12pm EST).
In the end i would take a boring 15 min daily catchup anytime compared to that.
I would suggest that if you truly believe standups are some deeply destructive tool of mismanagement you probably have much bigger problems with your company or role that you're projecting on to this rather innocuous meeting.
What is surprising about a bunch of introverted people not wanting to be forced to stand up and loudly declare what their day was like to the entire team every day?
If you say more than what you're doing, what you've done, and whether you're blocked or not you're saying too much during your standup. It shouldn't take you more than 3 minutes to give your status. The entire stand-up shouldn't take more than ~10 minutes.
Remember, you're supposed to stand up to make it kinda uncomfortable and informal. Everybody video-chatting their standup has made it too easy to be relaxed and waste time.
In the one team I was in that had standups, most of the developers would definitely leave after 15 minutes whether someone was talking or not. This put pressure on the others to keep it short.
My company has a hard 15 min limit for ~8 engineers.
It's a good opportunity for people to speak up if they can help, and give a simple "let's talk after about this".
Tech details get shut down by the PM after a minute or two unless it's actually useful to most of the people there.
It's very rare we go over the 15 min mark.
That said, I still have some long and pointless meetings, but I'm thankful I can throw them to a third monitor and keep working in the background.
Doing a boring meeting in person would be hell without that ability imo!
Where I work it's 10-15 minutes for 10-15 people. We're with a bunch of disciplines (hardware, embedded, mobile and cloud) so it gives me a birds eye view of the bigger picture and some insights into where my activities will touch others, and where I can help or provide ideas.
In addition, especially now we're remote, it's a way to sync up the devs time-wise. Some days a small ad-hoc group (2-4) will stay in the meeting to discuss an issue at hand. Plus often bilaterals are planned 'after the standup', since we're all in, and in meeting mode at that point anyway.
Ban this horrible practice and start trusting your employees more.
I ask because I tried to set up daily checkins with my junior dev if only to make myself available to them.
What do I do when they just go radio silent for a week?
Doesn't really hurt the team overall I guess, just an unpleasant interruption to my nap time.
Once you start speeding past the "what did you do yesterday" topic, you realize how poorly organized communication is on serious topics. A lot of places spin up Google docs or the like to basically make agendas and take meeting notes. So now, unless you have the magic link handy you have no idea where it is. And 9/10 times it turns into a giant mind map of fragmented sentences.
What I'm basically seeing, is that agile, and scrum, grew up in a world of synchronous meetings. To really embrace asynchronous communication needs new ways of organization. And there just aren't strong patterns for this yet.
The other problem with standup meetings, although this is more of an issue back in the before-times when we actually went to the office, is that they turn into a de facto clock-in time. If the standup is at 10 AM, then over time, nobody bothers showing up until 9:55, because there's not sufficient time to do anything worth doing before being interrupted the standup, and if you had plans for the day, they'll get tipped ass-over-beanbox by some new urgent request from somewhere at the standup.
I'm deeply envious of those fabled software developers of the past, before the Agile Manifesto, who were allowed to go work by themselves in a room for a whole day at a time, sometimes even two or three days. What luxury! Just imagine what you could do without people poking you with a stick every hour or so?
You get requirements that don't change and you get time to implement them without bullshit status meetings interrupting?
When did we decide that was a bad thing? And how did we get brainwashed into thinking agile was better for ICs?
;)
To be honest, I'm usually in a purely reactive mode most of the time. Planning what work I'm going to even do tomorrow is not really possible, until I see what crap has been landed on my calendar overnight...
But my current format for over a year is:
- One day a week about 20 of us get on Zoom, the 6 "group leads" give 1-2 minutes of updates. The director gives big picture updates, chases down any critical issues. Anyone has a chance to raise anything. About 45 minutes long.
- Every day, a "stand-up" channel in Slack, everyone adds 1-4 bullet points of what they're up to, things they're fighting with, etc. Takes about 30 seconds to write, another 30 seconds to skim. About once a week I see an item I need to be more aware of and I follow-up on it directly.
It's... fine? I wouldn't call it great, or "the solution to stand-ups" but for once I'm actually feeling an appropriate balance between spending time and getting value.
What so bad about having to tell what you've been doing yesterday? one up to few sentences per person, 10-15min max?
Therefore any mandatory social interaction will be met with resistance, even if it's useful for knowledge sharing or for letting your boss know how things are progressing or if they have to change resource allocation.
We can afford 5-10 minutes to chat.
Most of us spend an order of magnitude more time dicking around per day (as we should, for it's intellectual work)
* In order to mostly stand there and listen to irrelevant or redundant information
* So that when it’s your turn you can say something that the listeners don’t care about, that could have been a Slack message
The first point can be slightly mitigated by placing the standup directly before or after lunch or another meeting, or at the beginning of the workday, so at least you were already going to have to put down your task.
"can we expect that done by stand up tomorrow?"
"will that be a problem?"
"let's have a quick meeting to discuss in 45 minutes"
Instead of 15-60 minutes of synchronous time, it could be replaced by an email that takes two minutes to write and 30 seconds to read.
What value does that provide anybody? Our tools can tell you what I've been working on. You can see the item I have in progress. If I'm blocked, I'm not waiting until tomorrow's standup. If I need to collaborate, I'll schedule a meeting or start a chat.
If you need to know what I did yesterday, either you don't trust me, or you don't know how to use the tools we have to track these things.
1)what the meeting is for (ie the goal of the meeting)
2)whether a meeting is actually the best way to achieve that goal and if so, who actually needs to be there to achieve that goal
3)whether the meeting on an ongoing basis is achieving the goal and if not, why not
In my experience a lot of daily standups degenerate into being a very inefficient "serial hub-and-spoke" information-sharing where one dominant boss person asks each person in turn a series of questions and everyone else shuts off their brain until it's their turn. It's a tremendous waste of everyone's time and just there to stoke the overinflated ego of the person running the meeting.
He talks about daily stand up being a communication pattern that is broken because it enforces people to be transparent and it forces, if applied correctly, that people can't hide.
Agile is about delivering value to the business. That means that the team has to come together (as a team does) and deliver upon request.
I see teams all the times where the process is detailed. Mostly it's because of weak scrummasters and/POs.
And I have learned during my +20 years and 20 some teams that if someone tries to tell you something is better without objective proof they usually want to sell you something.
Good luck
Dragging them into a meeting for an hour (8 hour day) is thus $100. 10 people perhaps, that's a grand a day you're spending on meetings.
How much of that hour does each participant actually need to be there? YMMV of course.
You can't have no meetings at all, but declining returns to scale will hit you on both time and people-count axes. I recall working for a firm with tens of thousands of staff that would do a global all-hands each quarter. Costs a bomb.
Just keep is small and quick, preferable async so that the least productive times are used.
The worth, what we get out of them, is very very little. "Oh hey, people are working on different, unrelated things. Alright. Bye."
The point, the purpose of having the standup, is at least theoretically valuable. It gives us all a reason to reflect what we've been doing, and what still needs to be done. It also gives us the opportunity to ask "What's next?", although this is rarely needed, as upcoming events are usually conveyed effectively through email or larger meetings once every few months.
Do I want more meetings? Absolutely not! I hate talking to people about work. I just want to do the work and not blather on about it.
Do I want less meetings? Absolutely! I hate talking to people in a way that makes me feel like I'm somehow justifying my job. I justify my job by the work that I do, not by telling someone about the work that I do.
Do I think we should actually have less meetings? Absolutely not! They have a point. There is a purpose to them. There is a need. If everything were strictly through email, everyone would ignore everyone else entirely.
There is a purpose to have meetings, even if it has very little value.
And you can always use a safe word like SUMO.
What is really hurting a team are the renegades. People who think they are so great that they can bypass any process or agreement. People that are always talking and never listens. People with own agendas. People never showing up when key decisions are about to be made. People that take huge risks for no good reason. People that always try to solve problems themself and then blame others when they fail or have to much work. People that do not care about adding business value. People always making vague comments implying incompetence among others in the team by using basic mastering techniques. People that never works on anything that is in the backlog.
Also when you are in a small team and communication is fast and efficient, they are superfluous. Team members already can ask for help and you know what everybody is doing.
If you have a leader. Standups were popularized alongside Agile, which is a framework for having all members of the team take on an equal leadership role. The idea of having standups under Agile was to provide a point for the "leaders" to coordinate themselves. If you have a designated leader, they are indeed dubious (and may also be dubious under Agile, but you cannot lean on a leader in that case, at least).
I mean, I'm not sure anyone seriously claims that Agile is actually a good idea. It may look like a nice idea on paper, not having a leader to get in the way of the people who know what they are doing, but not even the Agile Manifesto signatories were able to make it work in the real world when they worked together.
Agile is about focusing on constantly improving processes.
Ask yourself, "Are the standups paying for themselves? Are they improving my process? If they are not, can I do something to fix them? Is there something else I can do that would be less disruptive and more worthwhile?"
If there is no benefit, continuing to run inefficient process is anti-agile and, frankly, stupid.
Over the years I have participated in a lot of standups that are basically progress reports to the manager. Those teams usually already had a Jira, so this was just a stupid waste of time for something that did not provide any value.
The value of standups is in interactions between team members that would not normally happen without them. Like finding out somebody has a problem that I know an answer to. Or figuring out your task is no longer needed because of somebody else is doing something that makes it obsolete. Or noticing somebody is overworked and that I can spare some time to help them so that the team collectively delivers more on its promise.
I have learned that low trust between team members precludes exchange of useful information on a standup and basically negates any value you could get from it.
When people treat standup as progress report to the manager and have low trust towards their manager and peers, they tend to guard any information to not pass anything that could by accident backfire on them.
Another reason I have seen standups be a waste of time is when people don't really work as a team but rather as a collection of single person projects. When other people work on things that are completely unrelated to what I am doing and in fact understanding requires knowledge that I don't have, there is very little value coming from telling the progress of what I am working on.
This has nothing to do with standups. Decisions aren't even particularly made in standups, other than "how do we solve today's problems".
I keep reading apparently revolutionary next gen agile articles that are full of non sequiturs such as this.
Standups don't work when the team isn't getting anything out of them. Perhaps we all know what's going on because its a small team and we all talk to each other. Perhaps. its because we don't talk to each other in or outside the standup. Reeling off a load of ticket numbers without challenge is not communicating.
From the article: standups aim to: "seek out and destroy misalignment". How can we do that without putting the mis-aligned on the spot and making them uncomfortable? I think standups start to fail when we're all being too nice and don't ask the awkward question. After a while we just stop listening.
Isn’t everyone using something like a slack standup bot? We get the advantage of the daily “did this, will do that, no blockers” in a highly distributed team.
During audio standup, I just wait for my name. Tell some stuff preferably as short as possible, as everybody has to listen and is likely as bored as I am.
While reading standup update in text during morning coffee allows me to peek on the internet (maybe i will google using better terms etc.) spend a little bit more time on it. All while drinking coffee and doing regular internet scrolling - so pretty low effort.
I'm actually OK with this, and this is how my team operates. We treat each other as adults, instead of witch hunting who did the least amount of work yesterday. Works fine for the team, things get done, minimal toil, zero churn.
In my experience, my business went from no standup to standup and it was a huge boon. "Decentralization" for us was a euphemism for disorganization and chaos. Obviously you can do standup way wrong, but that's a matter of fixing it not ditching it.
No! Talking to people face to face is infinitely better than using shitty messaging apps like Slack.
But we do spend a lot of time in a daily meeting on Teams. Often there’s lots of dead air. Free to come and go. If you are in a zone, don’t be there in that meeting. But also free to bring up questions, including work related or not.
I started them years ago as one of my admins has been remote for 6+ years. When I started he griped he felt distant and out of touch to what was going on.
I don’t think he feels that now. And now that we are often remote or roaming. We stayed pretty well In sync.
Definitely not for everyone or every team, including some I’ve worked on. But it works for us.
All I see here are arguments around a one size fits all solutions. Be fluid. Observe, listen to your team, and adapt.
No one knows what anyone else is doing, 99% of the time no one cares, Moreover people are all dealing with context switch and ineffective at relating how their thing might have a knock-on effect for others.
Sure makes team leaders feel like they are in the loop and valuable to an organisation though, especially ones that don't know how to ask effectively.
Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically.
To compensate for some of the social aspects, we now do a 30m “coffee chat” Monday morning, and a “engineering roundtable” on Fridays, which is a time to sync up around coding conventions and practices we would like to adopt or get rid of.
I agree with the author that often the standup is the "ceiling" of communication in a group, and oftentimes most of the information presented isn't super valuable to anyone besides a project manager.
Yes, if they are more than a day long. Wasting time, and fragmenting work flow.
(edit: added extra caveats to no)
Standups aren’t enough to meaningfully contribute but pair programming is frequently wasteful and dominated by one person.
I have been thinking about a daily meeting of 5-8 people with a rotation for the presenter to give a tour through their code. I would keep it 15-30 mins.
Then other devs can catch any glaring issues without getting caught in the details.
1. strictly time-boxed (1 min per person)
2. we stick to stating 3 things and then move on:
- I accomplished X yesterday
- I am working on Y today
- I am blocking Z or blocked by Z
(edit: I suck at editing markdown on HN)
I don't think this information which needs to shared in person, simultaneously, at a set time every day, while standing up.
Finally, if something comes up, its as easy as saying "lets do :standup-emoji over slack". No questions asked
that said... I like the potential of them. and I think it might be possible to do them right. but theyre certainly optimized to be best for the manager, maybe a net win for him, and a net lose for each of his reports.
caveat: I might have experienced them "done wrong" more than done right. so will keep an open mind that the latter is possible
Shitty MANAGEMENT might be, but a true standup / checkin that follows actual agile/scrum methodology is FINE.
Key here is that it's SHORT. What are you working on, what's next, are you blocked, do you need help from a team member? Ok, next.
Remember it's called STANDUP because the whole thing should be short enough that nobody needs to sit down.
People need to know the difference between "weary" and "wary".
* weary: tired
* wary: watchful, cautious
A few developers have taken advantage of the stand-ups to avoid updating tickets with information as it comes up and just wait until the stand-up.
What was naturally communicated throughout the day became bottled up for standup. "Taken advantage" suggests nefarious intent, but I expect in a lot of cases it was simply because people have no idea what purpose standups serve if they otherwise communicate normally.
And since standup advocates suggest that people should be called upon to say their piece, there is even more incentive to save up something in order to have something to say. "I'm afraid I have no new information to share" every day gets old very quickly. I know first hand, because that's exactly what we were left with when we tried to also communicate outside of standups.
We currently have a problem with outdated information in tickets. Keeping such tickets up to date requires a bit of discipline that involves adding in information as soon as it becomes available.
These updates are almost always provided during the stand-up; when not provided, they're forgotten.
If people don't show I assume they are doing fine. But if they complain about a blocking issue weeks later I make it very clear that they had an obligation to bring this up earlier.
After the standup often a group will stay on and discuss what's going on in more detail. Some people are interested and some aren't interested so they don't have to join.
Works reasonably well for me.
Or better yet, just treat your people like adults, give them sizable chunks of work, and give them a bonus if they do it with high quality and quickly, which is otherwise known as "management". That's how Google worked back in the day, and it works fine, as long as you hire well, and pay well.
Most of the benefits we supposedly get out of agile could be accomplished by a non-dumbass technical lead looking at git histories for 10 minutes a day. I suspect this is how real world software teams get things done behind their so called managers' backs.