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