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.
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".
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 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.
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).
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.
"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.
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"
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.
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.
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?
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 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?)
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.
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.
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?
> 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.
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.
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".
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.
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.