Unquestionably. Just yesterday I was asked a quick question about something we are working on. I made the mistake of saying that it could be a problem, but I would have to confirm since I did not have the needed information in my head at the time. Once I was able confirm, there was no problem, but that lead to wasting an hour later in the day to explain why it might have been a problem and why it isn't actually a problem.
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.
Shitty standups are first the fault of the leader, and second the participants. If everyone limps into the meeting and 'phones it in' by repeating common responses "uhh, work orders, reviewing PR's", then of course you'll get a weak result.
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.
> "uhh, work orders, reviewing PR's", then of course you'll get a weak result.
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.
This doesn't address the issue of some participants perceiving the frequency of standups outpacing the amount of information worth sharing. Which is one of the largest recurring criticisms of standups.
Then make them shorter! and make it OK to say "No Update". If you have nothing to summarize of value to your team in a 24 hr block, what are you doing all day?
Sometimes there just isn't much more to mention than "things are going well" or "things are done". Both of which I would expect a competent team to take as the default if nothing is being said, with the difference between the two shown through your list of issues / graphs / whatever people are using to track progress. At which point, if all you have to say is the default, it isn't that difficult to criticize the usefulness of doing things daily.
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.
So if the point is to gather and declare "no update" maybe there is no point, really?
And if you have something else than "no update", why not to share it with relevant persons only, at any convenient time?
The fact that its daily makes it like that. We do weekly meetings with biz then break off into our weekly dev meeting where we strategize. Valuable information gets communicated and we have no daily standups. If people need to talk, they use the group chat app or email or the phone. IMO, daily standup is a cultish ritual that rarely has value. Incoming downvotes!
Yes I can see your point. Why wait for a single point of day to bring up any issues or share information? Just do it immediately. We have tools to enable this (slack, teams, email, etc.). But, I do see the point of a daily sync up for team building, especially for remote teams.
>Why wait for a single point of day to bring up any issues or share information?
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.
Teams are built out of people, and I think if you ask you'll find that people overwhelmingly hate standups. So what exactly is this teambuilding building?
I hope teams aren't waiting for a daily stand-up to try and get unblocked, but there is definitely value in both sharing the summary of the blocker and publicly thanking anyone who helped unblock with the entire team. It (a) increases bus width, (b) builds the team and (c) takes 20 seconds.
> It (a) increases bus width, (b) builds the team and (c) takes 20 seconds.
(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.
I know a few teams that do "daily" two times a week, but longer than the usual 10 minutes, so that there is some time for team-wide discussion and people are not feeling like the meeting is there to pressure them. I'd say it works good.
If the team in general benefits from the daily stand-ups then you may be correct.
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.
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.
I'm always flabbergasted when someone asks what's the point. It would be a very different game if the captain on the field initiates the huddle and expects everyone to get jazzed about "ALRIGHT LETS THROW THE BALL SOME AND THEN WE WILL CATCH IT SOME AND THERE MAY BE RUNNING INVOLVED! LETS GO, ON THREE! ONE TWO THREE GO TEAM"
The huddle is play selection, not design. It's also often dictated by the coach. TBH, I wonder what point a huddle serves in modern football anyway. Just how much control to the players on the field have, anyway?
I lack sufficient football knowledge to carry the analogy much further. My understanding is that there's no real discussion...the play is called by the coach, the QB (I expect) relays the play to the team in the huddle, and they execute it per the playbook that they all study. To be comparable, the standup would be where you get your work assigned for the day.
The huddle is about the QB disseminating the play they are about to run - he's the only one allowed to (in pro football) have a radio link to the coach. Not to vote on the play that is about to be run. My guess is feedback about people's physical condition and needing to be pulled from the game is the only feedback allowed (other than a question if they forgot something about the play, I guess?)
Modern football plays are far more dynamic than ever, if the defense shows man to man then do x, if they show zone do y, if they show blitz Z is the quick target, or if star receiver is mismatched then go deep.
The difference is that in a football game you don't have time to talk to each other during the game. In a software team you do have plenty of time and opportunities to talk as soon as a blocker or issue appears, and everyone can see who is assigned to what tasks, who submitted what changes and read updates about blockers in the project management tooling the instant those events happens.
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.
> The difference is that in a football game you don't have time to talk to each other during the game. In a software team you do have plenty of time and opportunities to talk as soon as a blocker or issue appears
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.
> In a software team you do have plenty of time and opportunities to talk as soon as a blocker or issue appears
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.
Ok, let's do our football daily standup, every play in the huddle:
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.
Isn't this what all these funky agile ticket management systems are for? So that both the managers and ICs can look at the board and know, asynchronously, what's going on?
This would require people spend like... an hour... figuring out how the ticketing system works, and then checking it, or at least paying attention to the emails that it kicks out when somebody changes something on a ticket.
It would also require developers to close things when they're done, make regular comments on the tickets as milestones are met, filling in the correct keywords or components so that the ticket is included in the right board, etc. Just saying it's a two way street.
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.
> 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 the only time ICs communicate any of that stuff is at a set time each morning, then something is already seriously wrong.
> 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.
> How much progress? Are they harder than expected? Easier? Any blockers? Anything that could help?
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.
If "no update" is a common report, then maybe that should be accepted as a reasonable update. If that is a frequent update then an experiment should be done. Get rid of the standup for a quarter and see what changes - positive or negative - come about.
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?
In my team it is okay to just say "no update". We don't do dailies to justify that we aren't slacking off. Everybody trusts everybody else that they put in the work.
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".
I feel what you said about the 'process' creeping in, however, if you don't mind, allow me to counter: My first N years had no version control, but that is not sufficient in my opinion to say it hasn't improved things.
This is the truth of course. Developers develop in spite of the current process management buzz word not because of it. With that said a daily 15 min standup seems to strike a reasonable balance for me/us personally between creating awareness within the team that might not have come up otherwise whilst not stealing too much time.
I too was coding 30 years or so ago. Back then we may not have had git, but we certainly had RCS and I recall switching to CVS.
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).
"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?"
"
Why do you need standups for this? They should talk to each other directly.
Because sometimes devs might not be listening/talking to others, and just need someone to organize an offline discussion to unblock them.
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.
A process that works well for motivated, skilled developers working on a clean codebase is... any process.
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.
Good leaders will never do standups by their own choice.
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".
Don't know about the rest of the team, but for me the daily "meaningless micromanagement meetings" provided the last drop of stress and burnout, leading to a depression. Quit my job just before Covid, and have not been able to return to work since that.
Had a job where that's exactly what happened- the manager took 30-40 min and went through the board, stopping at each devs name and their task.
"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.
I think it depends a lot on the what stage of the project we are in. In the beginning designing phase daily standups might be useful but once the work is well defined a more asynchronous communication style works better.
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.
Stand-ups tend to devolve into either show boating or phone it in updates. The former saps productivity and the latter saps morale.
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.
> Best approach I've seen is an asynchronous yesterday/today standup via slack.
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.
Not the above poster, but I also do and like the yesterday/today slack standups (with a proper zoom meeting once every two weeks to review/strategize/etc).
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 :)
> 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.
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.
It's only noise when all everyone ever writes in them is noise. In that case, yes, I fully agree - it'd be a pointless waste of time and you should stop.
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...
If it is reserved for when you have something interesting to tell, I can see the benefit. An expectation of fixed interval contribution is excessive. Then you just get the ridiculous "I worked on X yesterday. I will work on X today." out of lack of anything else to say.
Shitty standups happen because 1) team members do not believe in their core that their work is valued; 2) in such an environment, meaningless, destructive competition on dimensions other than the teams ability to deliver and maintain code that does the stuff the business wants takes hold; 3) in such an environment, team members become hesitant to actually share that they are blocked by something (in case that counts as point against them come promotion/comp time) etc
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.
> in such an environment, team members become hesitant to actually share that they are blocked by something (in case that counts as point against them come promotion/comp time) etc
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.
> team members do not believe in their core that their work is valued
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?"
> the solution is a restructure of society that encourages and reinforces work that people find meaningful.
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.
> 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.
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.
"Shitty standups" happen because in anything like a healthy team, they're a complete waste of time. Things like "I am having a problem solving X" should not be deferred until the next standup, they should be communicated in real time, at the very least to the team lead.
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.
A standup, or daily scrum as it's called in scrum, is a simple daily coordination for the team. Nothing more nothing less. It's there for the team to gauge the progress towards the sprint goal and in some cases give a status update on team relevant stuff. You can use it to evaluate prioritization, perhaps a team member is sick, perhaps some task took longer than anticipated. How do we need to adjust to still meet the goal, or are we unable to and should notify the relevant people.
It depends on the team. 99% of the time stand ups are there to help your manager/scrum master/team lead get a read on whether there is a problem that somebody on the team is trying to avoid mentioning.
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.
> It depends on the team. 99% of the time stand ups are there to help your manager get a read on whether there is a problem that somebody on the team is trying to avoid mentioning.
Well, the manager is not supposed to be there. A scrum master is supposed to keep it organized and time boxed, but the team is supposed to self police/organize themselves.
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.
Yeah which never happens in reality, as it's completely incompatible with a normal (risk averse) corporate environment. And the main premise is that there's recurring daily obstacles that the scrum master somehow can resolve, which never ever happens in reality. The daily is just an idea that never work out that way in reality.
Almost always the best way to solve an issue or a blocker, is for the person to simply continue to work on the task, alone. Very rarely is it productive to involve other people, and when it is, the person who is closest to this part of the work should be involved. To have a generic "issue solver" that solves everybody's issue is just not a good idea on a software team.
Almost always the best way to solve an issue or a blocker, is for the person to simply continue to work on the task, alone.
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.
Stand ups are not as much for developers as much as they are for transparency. But this overhead is deadly in a small, under-resourced team. Kanban is a better choice. Just let people blow through cards with as little communication as possible. The wonderful dynamic of a tiny team is that everyone still sort of knows what everyone else is working on.
> Stand ups are not as much for developers as much as they are for transparency.
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.
It's not micromanagement when the manager is trying to understand what is happening on the team. That's part of their job. If they were asking for updates from you every 5 minutes, that would be micromanagement.
How long do you think your manager should go without knowing what you're doing?
> 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.
Weekly status updates are probably enough if the team is 100% senior devs who know how to work independently and who know how to proactively reach out if they need someone else to get involved with something.
That is not the team composition most people are working with. The median developer in the industry only has a few years of experience.
If you want to know immediately, ask me. If not, I guess a good indication would be the slack channel for the team (I'm working remotely), or the JIRA board update.
Thank you. There are multiple tools and channels for reading and querying all of this information. Between JIRA, and, if necessary, your VCS remote, you can figure out almost everything about what a team is doing. Any grey areas? Ask directly, with whatever channel suits the urgency.
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.
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.
It's supposed to be "people over process", yet most "scrum" is all about process: too many meetings and other assorted bullshit like filling out your sprint planning and retrospective report every 2 weeks.
Scrum is about getting people to talk to each other and that's what all the process is about. If you already have good communication between developers and those making the business decisions, then sure scrum is probably a waste. Places that actually have that communication without having scrum force those people into a room aren't common. It's also common that places that don't really do scrum don't have empowered PO's or devs, so the meetings are wasted time.
Yeah, but devs can be finicky about waking up early. Half my team was fine with 9am and the other half preferred working more of a 11am-7pm shift. We experimented with asynch Slack standup but it fizzled out after a few weeks.
It’s not that the 15 minutes isn’t tolerable. It’s that it’s going to be scheduled poorly for someone, perhaps the entire team, in such a way as to break focus and drop context.
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.
Oh, God, I hate that. I would rather get the stand-ups out of the way first thing in the morning so I can have interrupted time before lunch, but most software engineers are massive divas, who think it's a horrible affront to be in the office before 10AM. And even then some people are regularly late.
And now with no commute for most of is, it's still somehow difficult.
Just block out the rest of your day and auto decline meetings. I do that and it works great. Forces everyone to schedule everything before noon. Also make sure to schedule lunch in as well. It make sure you auto decline that’s the trick. If you’re manually approving/declining each one you’ll end up allowing some which signals the blocked out time isn’t that blocked out to the rest of the team.
Not everyone's circadian clock works the way yours does. I hate having to schlep myself out of bed to join a pointless status update meeting half asleep.
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?
A lot of developers are of the late chronotype. That has nothing to do with being a diva, immature or lazy, it's just how we're built. There are plenty of reasons developers can be divas, but being a night owl isn't one. Chronic sleep deprivation will drastically shorten one's life span.
Yes, I did my share of that. Then I started going to be bed early, got myself an accu-pressure mat and all. Does wonders. How many of these people who are late nighters simply postpone going to bed, squeezing in that one movie before 1AM? And then they are wet sponges in the morning.
I am not denying genetic traits, but like with most things, it's not the only factor.
My team have "Daily Scrum" at 9AM every morning all year long so it's booked into everyone calendar. Sure once it a while someone have a meeting with an external team and it's perfectly fine that they don't come to the daily.
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.
Our Teams meetups are 25 minutes (for a team 10 individuals). We finish the round-table in usually less than 10 minutes and keep the extra time for the people that wants to talk in depth about the issues they talked about in the "Stand-up". Others can leave the meeting and go on about their daily operations.
> To be clear, I am encouraging more communication, not less communication. For internally aligned teams, you get more, and better, communication through a system that replaces daily standups with asynchronous collaboration.
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.
> 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
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.
> 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.
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.
> 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.
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.
This is the blog equivalent of a business book: long text to pad out a simple insight.
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.
I think each team should work the way they feel comfortable and avoid those "unified ceremonies". If someone needs an input they can ask for it when needed. Or organize a meeting if it really required. Otherwise just let workers work and do not waste their time with useless talk. Leader can always monitor overall progress.
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).
Dubious leader is not the leader. And having a team without a leader is not very good idea. If team is 2 people and both are equally qualify let them sort it between themselves.
> And having a team without a leader is not very good idea.
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.
I liked the idea (I think it was from Semler's book, but may also be from 37signals), that meetings are always optional. If you have organised a meeting and nobody came, it just means that no one saw any value in it.
I am not even sure it aims. It aims to make the team look "professional" or something.
Given that at most organisations the biggest problem always turns out to be communication, stand-ups are probably thought to be a remedy, but in reality they are more of a symptom than a cure.
Where communication works, there is no need to waste anybody's time with stand-ups. Where it does not work, stand-ups fix nothing. Just another cargo-cult practice.
I've always hated standups. Very rarely do they provide value for the ICs (IMHO) and that should be the key measure.
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.
Having a daily casual meeting where everyone brings up all of their problems and issues, and anyone in the company is welcome to listen, but not talk, is just a dumb idea. And there are never any recurring (easy) obstacles that the scrum master can resolve, and that can always wait until the next daily, the work of developing software simply doesn't work that way.
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.
If they where going to use a rugby term, I've always thought "ruck" would have been better. A ruck is quickly and dynamically formed every time progress is slowed, a scrum is a big formal process that is only necessary to restart the game after someone has screwed up.
Team rituals that trigger a productivity phase have no usefulness. Team communication has no value. Team leader having a chance to quickly gauge progress is not helpful at all.
[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?
> 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.
Taking time to regroup and change strategy as you learn more about your opponents (competitors in business speak) has a lot to do with developing software.
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.
Lol...there is no escaping the awkward silence on my team. We just had a meeting where every manager over our team wanted to meet with us and thank us and pat us on the back and look at us etc because we have absolutely kicked ass...not one team member said a single word the entire half hour.
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.
You may have a leadership team that doesn't understand the problem domain, that is, the "opponents" in the rugby analogy. They fumble around blindly, placing their faith in the Process and the herculean effort of the dev team to eventually attain expertise through trial and error which it is leadership's responsibility to provide in the first place, or to hire appropriate experts to provide.
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.
> 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.
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.
The weekly 1:1s or project syncs that are also happening on top of standup, schedule a new meeting with the relevant participants if that’s too late from now, Slack or email if it’s a simple Q&A, JIRA ticket if it requires some work to investigate and answer.
Matches my experience with standups: let’s all go around the room and think of something to say and then one or two people have a long drawn out conversation with the manager.
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.
> 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.
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 am getting the feeling that there is a whole set of these cargo-cult "best practices" like standups, "1-1's", retrospectives and so on. They're not stupid ideas, but they often seem implemented in a way where... "that's the done thing", rather than something evolved organically.
I'm not a 'process guy' though so I have no idea what to replace these things with, if anything.
In my case it doesn't stop there. There's sprint planning, sprint retrospective, then a backlog grooming.
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?
Processes in aviation and defense are long, drawn out affairs but they're also the result of successfully managing projects orders of magnitude bigger than any software company could dream of. (say, a decade between drawing board and first prototype, another decade until full production)
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.
> Also, no daily meetings (unless culture has changed since I was inside a while back).
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.
I have also never seen requirements or change control being done anywhere outside defense in any way near "correctly" or in a way which was useful.
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.
Oh yeah? Well I have Sprint planning, Sprint planning, Sprint review, retro (maybe), emergency epic planning cause management something something, and drumroll....vulnerability management. These are the regular meetings and I'm a contractor so my schedule is really clean compared to the FTEs.
Where I work now everyone (devs, PMs, managers) have internalized that if you are not talking about something the whole team needs to know about you just briefly mention it as an "icebox" topic (we use Pivotal Tracker) which the PM tracks during the meeting. At the end of the meeting the PM lists out any icebox topics mentioned and we all briefly sort them based on the number of people that care to listen and then we go through them in that order. It is a little bit of ceremony but it works for us.
That's an interesting concept, never heard of "icebox" before. I've always used the "is this relevant to everyone" questions though. There are often short chats about topics that are extremely useful for those involved but not the whole team. If those go on longer than a minute I ask the folk involved to stop and "pick them up offline" afterwards. Saves everyone time without destroying the value.
> 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.
We used to call it "Executive Storytime". We'd even project the status doc onto the screen AND have everyone read their part aloud to everyone in the room. Although in reality, the message was entirely for the VP and other big shots in the room, who would occasionally have questions. I imagine these are the kinds of things you think about on your deathbed, while you wonder if you spent enough time with your family throughout your life.
> 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.
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.
Most companies say the word "Scrum", but break half of the Scrum rules every day. This is exactly how it should be: only developers at daily, plus the Scrum Master as an impartial moderator (mostly there to keep the daily short). But in most companies, "Scrum Master" is just a label they put on a manager, and he is doing management as usual, only with an extra excuse for daily meetings.
My BI, Data Engineering, and Project Management team all have a shared standup. They all work on a bunch of different projects at any given time so we can't really do project specific standups. I am amazed at the dedication that the PM who runs the standup has on keeping things short, direct, and moving. About 15 folks are in on that meeting, and he's always done within 15 minutes. 17 minutes on a bad day. Any side conversations try and start up? "Let's table that".
"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."
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.
I've been at a place with PM-driven standups. It was fine because:
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.
> Especially if they show only from time to time and take over the meeting.
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.
I'm not as cynical. The "pulling rank" types definitely exist but I've worked with a lot of PMs who overshare either because they're aware the engineering team doesn't see all their work and want to "prove their value" and/or they're are genuinely excited about their work and keen to share with the engineering team. Those types always react well to gentle reminders to keep it brief.
I disagree that the key measure should be value for ICs, or atleast engineering ICs. There are a lot of management and non-engineering IC issues that can be sorted by a quick chat. The alternative to a quick chat at standup tends to be constant Slack/Teams messages and lots of 30min meetings. ICs might not get much direct value from a daily standup but we get a lot of indirect value from moving a big chunk of those interruptions to a set time each day.
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.
We have to post our daily standup into a Slack channel, so it’s just a matter of posting my (planned) task list for the day. There’s no discussion, just something my manager reviews. I don’t really see the point but I play along anyways.
When I was on a team that caught the agile flu and wanted to experience the standup fever, it soon became very confusing to the team to know when communication should occur.
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.
Programmers tend to be introverted and have some serious ego issues.
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)
* Having something on your calendar that pulls you out of what you’re doing
* 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.
in a few years someone will write "I don't know why you have a problem with our group calisthenics. Jumping jacks are good for you and I like that our managers care about our physical well-being. It's just like when they changed lights out to 9pm in the company dormitory. It does help me get a good night's sleep!"
> What so bad about having to tell what you've been doing yesterday?
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.
We stopped doing daily standups completely. It just felt like a waste of time. If we had to bring them back, I'd use something like Standuply on Slack to do it asynchronously.
I feel we need a middle ground between standup and pair programming.
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.
My main problem with standups is people really like to turn them into soapboxes. They're supposed to be short but if it's scheduled for 30 minutes, people WILL make sure it lasts exactly 30 minutes. Even if theres awkward silence at some point, they'll come up with something to bitch about. I think this is to show they're "engaged" or something. IDK.
Doesn't really hurt the team overall I guess, just an unpleasant interruption to my nap time.
Where I work we have something that other software developers might consider ”shitty standups” or a waste of time. We show up one or two minutes late, we often chat about life, topics outside of work for anything between 2 and 15 minutes. Only then we actually start the standup routine. Each person chooses if they want to just say ”worked on feature X yesterday. Will continue to work on feature X today” or to share a complex coding problem or business doubt they want help with. Then it is over and a bit more chatting until someone decides to leave.
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).
It's good that your team is empowered to tailor its rituals to its needs. It seems that a lot of people forget that the Agile manifesto[1] is loose enough to allow for team-specific customization: "Individuals and interactions over processes and tools".
True, but not at all in line with how Scrum was sold back in the days. I even believe there was a rule saying if you do not follow all the rules of Scrum it is not Scrum.
Companies should not dictate a team's process. If they do, you should leave (if you can) or change it (if you can).
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).
Yes, that's critical. We've used entire stand-ups to discuss how to make stand-ups more effective. Finding a way that makes it quality time for the team is ideal. The goal is for everybody to be able to work and communicate better together.
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.
Such a great setup! I wish my team would follow something like this. Everyone seems to be in their own silo or they interact with people only for doing a specific task.
Same here. It's a little bloated maybe but the balance of chit-chat vs real work seems to be one that works for us. It's productive and also good social session to start the day.
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.
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.
> ” Google has seventy brazillian people, and we have six on our team.”
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
Great to hear we're not the only team who does this. We are fully remote, and most articles on this seem to revolve around cutting standup to 15 minutes or less. Ours still stays pretty short, and is even 15 minutes sometimes, but frequently edges out towards a half hour.
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.
We follow similar structure, but it is not a daily thing. We do this 3 days a week. So far useful. Besides, we extensively use Slack to notify team for any blockers.
> But it works great for us. We have explicitly discussed it before and that’s how we want it, at least for now.
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.
Something that I've noticed as a remote employee (before and after the pandemic) is that the usual interpersonal interactions that happen organically in the office have to be done intentionally. You've decided to have some fluff in stand-ups. My team has a social meeting every week for about 30 minutes. It's not running into people in the breakroom, but it meets the need to be social.
The worst standup I ever had were where it wasn't a standup at all. It was a role call by the managing director to check up on what you did the day before and to generally berate you for any minor transgression in his idea of what you should have been working on.
Yes, for bad (poor) managers it's a tool for micromanagement. Unfortunately, it's not uncommon for the manager to use this tool in order to micromanage antagonistically rather than lubricate the team.
That would certainly suck. The worst in my experience (at least recently) are standups where the PO shows up, then proceeds to get in long-winded discussions about features and implementation, and invariably tries to guide priorities for the day. 90 minutes later...
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.
Worst ones I've ever had, the dev manager was also still doing some dev work, mostly not on the company's main product, but other crap, but was in on the stand-ups and set the tone for it being a "moan about how hard your work is, to justify why we pay you" fest, by going into way too much detail about every little difficulty he had yesterday. This on top of the fact that there were like 6-7 people on these meetings, no more than two of whom were working on the same thing, so standups weren't even theoretically a good idea to begin with. The meetings existed only for him, and he was ensuring the form they took was terrible, stressful, and took up way too much time.
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.
Hah, we dedicate the first 5 minutes (used to be 7 minutes, but the company grew) of our daily standup to non-work related subjects. After which someone makes an airhorn-like noise (think "pew pew pew") to mark the beginning of "actual" standup. It started as a way to accommodate people who were running a minute or two late but it's become a ritual at this point. Rituals are nice!
Sounds pretty sweet. The last "leader" I operated under used to lock us into 1.5-2 hour daily stand ups every morning and would use the time to either bitch, delegate or brag about his work. It's was a fucking nightmare.
Fully remote team here. We decided that the chit chat starts at 10, the standup at 10:15. That.... often doesn't happen. So our running joke is no matter what time it is getting (sometimes 10:30, sometimes 10:40) we always say "Alright guys, it's almost 10:15" to signal that we should probably get started.
> ”worked on feature X yesterday. Will continue to work on feature X today”
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.
Five seconds to say and two hours of lost productivity from the context switch required to hear it[0]. And I still don't care. What am I going to do with the information?
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.
If I know when the teammate starts working on X and stops working on X, why am I not able to infer that he is working on X during the period in between? In reality, I already know that he is working on X and anything that is relevant to that already applies.
I'm still not clear on what information ”worked on feature X yesterday. Will continue to work on feature X today” gives me.
Tone of voice, body language, hesitation, etc. Non-verbal clues that maybe you can help your teammember, or that they can help you.
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.
I consider "no blockers" to simply be a nicer way of saying "I'm done talking now". Developers aren't always the most socially gracefully, but hopefully we can continue to avoid saying "I'm done talking now".
One hour to build up the universe, only to have it shattered. One more hour to get you back to where you were.
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.
There has been research in this area. It's shocking (in both the literal and figurative sense) how much time is wasted by interruptions for people who do "thought work" like software development. If you have a daily standup around 10am, like the last place I had them, it's possible that you have instantly reduced the effective productivity of your entire team by 20% or even more.
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.
Most people have no idea what a productive standup looks like. I was on a team once where we had a standup on Monday mornings. Fucking beautiful meeting. Of course, a new dev manager killed it for some god forsaken reason. That meeting prevented so much bullshit. That manager ended up getting the boot because...chaos and lack of productivity.
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.
Most people have no idea what a productive standup looks like.
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?
My wife works in healthcare and has a daily standup. They use that time to go over what work will be done that day, which largely cannot be predicted far in advance as it is dependent on patient bookings. This brings novel information.
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...
Standup has a known time that you can plan around, and makes a spot to put all those short bits of info in one time, so you can avoid being interrupted and context switching when it's not standup
Usually standup meetings are scheduled at a given time in the day (usually, it's the very first thing in the morning). You know when it's coming; it's not like people randomly poking at you and making you do a context switch.
I moved my team's standup to just before most people take there lunch. Initially it was an accomodation for someone who was temporarily working in a different time zone but after they returned home no one on the team wanted to change it.
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.
In practice, lunch does not bring a context switch as you just don't go to lunch until you reach a natural stopping point. Standups cause a context switch because they are scheduled by the clock, not by the work.
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.
Maybe for you, lots of us go for lunch with colleagues, play sports or boardgames and so that tends to happen on a schedule. At least we did until we all started working from home.
Like another commenter said, you can always say "Hey guys, give me 15 minutes while I wrap this up" and you don't enter context switch mode. Unless you work with completely unreasonable people, they'll wait.
In fairness, as you are forcing a context switch for a standup, it is likely that you do work with unreasonable people.
The productivity is still lost. I can try to get something done before being interrupted by the scheduled time, or I can accept that nothing will get done beforehand and wait idly until he clock finally smiles upon me. The end result is the same either way. Try to fight back against reality as hard as you might, but there are only so many hours in the day and that is beyond your control. As engineers, we should recognize that we have to work in the confines of what we can control.
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.
I don’t think it’s the interruption. I work from home and I got interrupted all day, from family asking me something to teammate asking for my help and sometime joining a call. It’s the context switch that is bad. You can hold off most interruption to try to complete your current train of thought (like give me 15 minutes to complete this and I’ll get back to you). But when you have something that is mandatory, you avoid going into any deep work like a debugging session or architecting a new feature. And most of the time the standup does not really help, because productive teammates will reach out to each other during the day anyway if something impact them. And manager should reach out to developer anytime something pop up that impacts their work, not just wait for next day to let people know.
Standup can be great if the responsibility across the team are spread out, but only at a lower frequency (once a week?).
Meanwhile, I'm constantly realizing that something I remembered didn't happen in Slack or Email or the issue tracker, but on a call, so now I have to hope I thought to take notes, in the moment, and then go find them, when calls are basically the only thing I ever have to take those sorts of notes for, and they're infrequent enough that I'm not so great at consistently remembering to do that (I'm working on it, but still, for god's sake, say it in Slack unless it's impossible to, which is almost never).
When I started working from home, AOL Instant Messenger was still the hot new thing and long distance charges would kill you. Residential bandwidth simply wasn't there for calls. For all intents and purposes, it was textual communication or nothing.
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.
I mean we'll still be talking after Slack is gone. Sometimes you want to establish a ritual that will outlast everything, including that switch from Slack to Teams because corporate reasons.
You are not on my team, so your perceptions what is shitty for you do not matter. That’s more the point of my comment: each team should discuss and reach their own ideal dynamic. If you were on my team, from your strong opinions here, the dynamic would certainly be different.
This is what makes standups shitty. I couldn't care less to know if you are still working on something.
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 that's all anybody ever says, then I'd agree.
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!
That works if you are saying it to yourself in front of a mirror, perhaps. If there are other people listening in, it will take another five minutes just to wake them all up.
Then I think you need to explain yourself better. Saying a 10s phrase that says I don't have anything to report would send everyone to sleep seems to imply that you don't think people should say that.
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.
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.
> Same way humans have always figured it out? They say it.
> 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.
What you seem to not understand is that normal people don't speak up when they only have a canned response they were told to say, to say.
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.
You didn't need to mention it. It was already baked into the discussion long before you ever replied. It is not like the subject would have magically changed beneath us.
That you seem confused about the subject now is... strange.
It wasn't baked into anything. I never said that. If you're inventing things, then I don't know what to tell you. Presumably you'll interpret anything I say in an arbitrary way, adding or subtracting to make what I say fit a stereotype.
Since the first comment, the thread has been about how "Yesterday I worked on X, today I will work on X" is pointless. That is the canned response. It is not something a thinking person would logically say on their own accord. It gets said because it is the answer to two of the three questions that the book on Scrum indicates should be asked in a standup. The third being the equally useless "Do you have any blockers?"
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.
Actually, most of the thread has been about whether or not you're saying people are allowed to indicate that they have no blockers.
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.
> Actually, most of the thread has been about whether or not you're saying people are allowed to indicate that they have no blockers.
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.
The problem I have with saying nothing is that the act of saying "still working on X" can be a trigger for more conversation. Is X taking longer than expected by the rest of the team? Let's dig into that. Did somebody else's work unexpectedly intersect with X yesterday? Now they have a mental trigger to mention that. Etc.
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 a team member says they worked on Jira #X and will continue working on it other members should be asking for the technical details. Everyone should be giving 1-2 sentences of the technical details of what you worked on yesterday and the same for today. It is up to the team to question what is happening not just for accountability and ensuring people aren't going off on already explored paths, but also to ensure the standup is actually interesting. A blocker isn't the only reason other team members might need/want to get involved in what someone is working on.
> also to ensure the standup is actually interesting.
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?
Ours used to be similar, then we were assigned a scrum master to act as a mentor (despite most of us working together for more than a decade, we are fairly new to agile). He made stand ups much more regimented. All the chit chat is completely gone. I’m now realizing that standup was the only time of the day that my coworkers and I connected about anything not strictly work related. It does feel like we have lost out on something.
you should try virtual happy hours with the team. once every couple weeks, generally just an hour or just long enough to finish a beer. If the group is kept small it can be a pretty good team builder as long as an effort is made to include everyone in the conversation. Felt forced in the beginning but generally most teams have at least one person that can get and keep the chat going. Still keep it going now with people I used to work with even though we all went our separate ways.
I agree that especially in pandemic times this is hugely beneficial, although I'd recommend doing it in the opposite order: quick 1 minute updates followed by casual off-topic chatter for the rest of the meeting. I've found that folks are much more relaxed after giving standup updates :)
Thing is, what you are doing is NOT a standup meeting.
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%?
A standup meeting was also in 1 room and in person.
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).
Of course it's a standup, its a metaphor these days you don't have to literally stand (otherwise how would a remote standup work? Do you have to insist everyone gets out of their office chairs?).
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.
In that case you didn’t say what you think you said - I think if you read your original post you will probably see how it looks like you are insisting they are done standing.
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.
> 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.
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?
>But teams behave in an infinite combination of size, members, companies, and time
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?
For a remote team, you have to make space for people to get the face-to-face hallway/watercooler chat time if you want to build a solid culture. Time for people to get to know oneanother that is easy if you're co-located. Easiest place to make space for this is to have padding on your meetings. Especially standups.
We have shit standups on my team. People show up 5 minutes late to standup so we don't actually start for like 5-10 min past start time.
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.
I really can't emphasize this enough. I work with a small team (2 other devs) and our morning standup happens 3x per week. We're remote and we're building Open Source tech[0].
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!
We had the same experience and just renamed the calendar booking from "standup" to "morning meeting" and made it 30 minutes. Great for morale and team building! Small supporting team though in a highly moving complex domain with lots of consultants coming in and out so ymmv.
Daily status reports are really a special form of hell. There is no value in something so fine-grained except to the micromanager. It forces a daily interrupt that reduces productivity. Most painfully, it effectively prevents (heavily discourages, anyway) a deep dive into anything because you better have a snappy status report for tomorrow. No time for deep research, so all work becomes superficial.
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.
In my experience talking about life is what is missing from most anaemic standups. Forcing people to immediately talk work is harsh. Sure, some (especially managers) prefer not to waste time (or have no real life), but as a globally distributed team I feel we miss out of experiencing each others culture a lot.
I used to run more strict 15 minute SCRUM standups, but when the pandemic hit and we all left the office I changed to this kind of standup on purpose.
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 project manager interpreted what they thought a stand up was and enforce we follow a template, they see themselves as part of the "scrum team" so they also attend these meetings.
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.
Maybe I’ve led a charmed life but I’ve never seen any problems with stand ups. It’s just a few minutes of “I’m working on this today” and “okay we’ll pair on that after lunch.” But I guess people can mess up anything.
420 comments
[ 4.5 ms ] story [ 210 ms ] threadIn 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.
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.
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".
(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.
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.
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...
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.
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:
Our Teams meetups are 25 minutes (for a team 10 individuals). We finish the round-table in usually less than 10 minutes and keep the extra time for the people that wants to talk in depth about the issues they talked about in the "Stand-up". Others can leave the meeting and go on about their daily operations.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!
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.
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.
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.
Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically.
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.
In what universe did this happen? Certainly not ours.
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.
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.
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.
Doesn't really hurt the team overall I guess, just an unpleasant interruption to my nap time.
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).
1: https://agilemanifesto.org
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.
[0] https://i.imgur.com/3uyRWGJ.jpg
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!
0: https://github.com/lunasec-io/lunasec
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.
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.