In my opinion standups are mood killers.
If you need something, you ask for it anyway. Anything else would be ridiculous, you have a job to do and you need something from somebody so you ask. This is collaboration 101.
Yeah sure, there is some tiny possibility that person A happens to mention his approach to some task and person B happens to know a better way, but really that is such a motivation killer for several psychological reasons, but even more than that: How likely is that? It never happens anyway and if you know your colleagues, you likely already know if they probably can help you with something and you ask them for some pointers. If you don't do that, a standup isn't going to help you because you don't want help.<p>So for who's benefit are standups and "agile" in general?
It's for the benefit of managers who by their nature don't have insight into what's going on in general and they want the most superficial general overview of what everyone is doing.
For developers, I don't see any added value whatsoever. This applies to all pillars of agile, I could go on and on about this. Agile is only pseudo-beneficial for managers.
Everybody knows everything and then everybody(=nobody) is responsible when code breaks, giving the manager peace of mind but the developer couldn't care less: It's not like it was his baby.
We (the developers) took control over our standups. We went back to basics and talked about _why_ are we doing kanban boards standups, and found two reasons.<p>1) We do need better awareness of what others around us are doing, especially across the dev/ops divide.
2) Communication, kanban is there to show interested non-devs how projects are progressing.<p>We update the kanban before the meeting and let one person per day read through the entire board for today/ongoing/blocked. If there are any tasks that person doesn't understand – this is the time to ask.<p>The process takes often less than 10 mins per day.<p>Any issues raised will be discussed in loosely formed groups afterwards to not waste everyone's time.<p>I think what I learned is that you mustn't let process be shoved on you by middle management. Take control to make these things productive for you.
"When it gets cancelled because a certain person is not there, you are doing the meeting for that person"<p>This rang true with my current team. It isn't that the meeting doesn't happen but it is extremely fast. No round robin, just a simple 'has anyone got any issues'. Nope, ok carry on. We still get high value from those discussions.<p>My personal observation is that when this senior person is there, they are using the stand-up as a project management meeting. This should really be 'taken offline' and this person should be working with team leads away from the stand-up.<p>Luckily I'm working closely with one of the team leads in an isolated area and I excuse myself from the meeting and let him talk on my behalf but I shouldn't be at that point where I'm trying to avoid them.<p>The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
I'm seeing a lot of comments about how terrible different people's standup meetings are at their particular companies, and I can't help but think the problem isn't with standup itself, it's with these companies.<p>At my job, we meet for standup via video chat as early as we can. That's about 9am for some of us and 10am or 11am for others depending on timezones. We each say what we worked on yesterday and what we're working on now, which only takes about 5 to 10 minutes, then we enter what we call "parking lot." We call it "parking lot" because if this were an in-person meeting, this is bit where we would be talking in the parking lot on our way out to lunch. No one is expected to stick around unless there's something urgent related to what your working on that needs to be discussed. Anyone is free to hop off the call at this point.<p>During parking lot, we discuss impediments, anything that's going to keep someone from getting work done that day. If the problem is something complicated that's difficult to describe via text, we chat about it face to face and work out a solution together. If the problem is simple, we just agree to talk it out in either a public or private channel on Slack depending the kind of problem.<p>The purpose of the meeting isn't to build a big report of who's working on what or to guilt us into working harder. It's just to guarantee that we're all online at a given time each day to help each other out. Working across several timezones, we all have wildly different hours, and without standup, we would probably be waiting for days to hear back from each other about any issues we run into.<p>Maybe standup is a problem for other people or other companies, but for my team at least, we couldn't work without it.
The effort to say something about yesterday and about today is an obsolete overhead. Sometimes one is just stuck for couple of days with bloated and partially obsolete Java setup, sometimes one has done nothing and needs a break instead of daily confessions. Saying these might be perceived arrogant or disrespectful. I perceive standups as an immature way to discipline developers.
Team-oriented software development has become somewhat infantilized, and it's a worrying trend that keeps showing up in our society, in general.<p>We need to stop approaching team development with the <i>expectation</i> that one or more team members will need checking up on because they're goofing off too much or not working on what they're supposed to be working on. Professional software development is a <i>career</i>, and we should be able to start all employer <-> employee relationships with the expectation that a) we're all adults, and will treat each other accordingly, and b) we're all, ultimately, responsible for our own work and the work of the team. If someone repeatedly demonstrates that they can't execute in this fashion, then they're gone. There's simply too much to do, and dragging the entire team down to the level of the least-responsible member is ridiculous. You're better off just distributing the extra work among existing team members.<p>For example: want the team to bond and communicate ? Ditch the daily meetings, and every Friday take the team out for a meandering late work lunch where everyone talks about the week, what they're working on, the overall project, etc. Any other time, everyone knows where the other team members are working - if there's something that you need, you ask in the least-intrusive way possible, depending upon how busy the other team member is and the importance of your task.
I disagree with the basic premise of this: "When it gets cancelled because a certain person is not there, you are doing the meeting for that person".<p>One person being the driving force behind making something happen doesn't imply that all the benefit accrues to them at all.<p>"Just make sure everyone is actually recording what they are missing!"<p>Except they have no way of recording the opportunity cost - they don't know what they haven't been told; they could be missing something huge, but without a venue for communication they don't find out.<p>I have to say, I don't think this is great advice.
I do some contracting from time to time with a devshop that has gone "full agile" - I love these people, and have a lot of respect for the work they do, but OH. MY. GOD. save me from the fucking standups. What a totally useless waste of everybodies' time. I refuse to attend most of them in any case, which harms my standing with the project managers, but I seriously don't care - most standups as well as the majority of other project management activities they practice appear to be designed to keep the project managers happy, and contribute little to the overall quality or speed of delivery of the project at hand, and are a massive distraction to everyone involved. Daily $project_management_ritual should die.
Daily standup is a scam just like the "open office".<p>Most of the time it turns into a beating stick for incompetent managers to feel good.<p>They are both defended by people for various superficial theoretical reasons that never come to fruition.<p>Like they try to defend open office because "it's good for collaboration" but in reality it's only to cut down office costs and to let employees watch each other.<p>If giving people private offices was much cheaper you'd never in a million years see a company accept the increased cost of an open office just because "it's good for collaboration".<p>This is a pattern that you can notice easily in business. Anything undesirable that is not good for you will be applied a lip-stick of colorful language in order to "sell" it to you and it goes right into the echo chamber.<p>You can put people in boxes that stack on top of each other and then say "Our beautiful stacked-box office promotes a culture of deep thinking and solitude where you can re-gain your focus and stay away from constant distractions.".
I've been at my current job for 5 years and spent my previous 15 at 7 different jobs combined. It's not an accident that I've stayed at this one but left all of the others. This is the one where people are allowed to be responsible for their own productivity without overhead like standups, project managers, status reports, task tracking software, etc. It couldn't work for all people or all companies, but it means enough to me to manage my career around finding the environments like this one that make me enjoy coming to work so much more.
In the aspect of scrum the daily is good defined, I don't think you need to experiment about what needs to be talked about.<p>It is a one time a day meeting where everyone gives a glimpse over what he has done and how this may affect others and what he is going to achieve until the next meeting. Committing to a goal motivates me to get things done. A third aspect is to give the scrum master feedback about impediments which do prevent me from achieving my goals.<p>And yes this does not mean that nobody is talking to each other through the day. But even if you are a team it is important to get everyone up to date. Most discussion through the day happen between 2 or 3 persons, and not with everyone (4-6 people).
I agree with author... instead of doing "Scrum", how about we act like adults, and speak with people when we need to, in respect to their time, schedule accordingly, and not clown and parade around with scrum and poker cards.<p><a href="http://programming-motherfucker.com/" rel="nofollow">http://programming-motherfucker.com/</a>
Our "scrum" stand-ups were taken over by the PM stack, and they started getting longer and longer and weren't useful for the team doing the work.<p>So I started calling them status meetings.<p>"Hey, stand-up in five minutes!"<p>"You mean status?"<p>... and kept doing that. Eventually even the PM grudgingly admitted that it was just a status meeting, and referred to it that way himself.<p>It was okay; agile had died (and turned into simple micro-management) a long time ago in our division.
As a counterpoint: stand-ups can be a great way to operate a team without a managers, tech leads, or assigned work: <a href="http://deliberate-software.com/self-organizing-balance/" rel="nofollow">http://deliberate-software.com/self-organizing-balance/</a><p>I think "bad stand-ups" is a symptom you are using a self-organizing practice in a command-and-control team.
We have switched to asynchronous, slack-based standups a long time ago, moderated by a bot (we're using a modified version of <a href="https://github.com/eelzon/morgenbot" rel="nofollow">https://github.com/eelzon/morgenbot</a>). This way everyone knows what everyone else has been up to, will be up to and what blockers are, without being caught up in endless discussions, and since it's asynchronous, people can supply their standup (within limits) at their own leisure. Works well for us.
As a coach here's my question about the standard standup format (what did you do yesterday, etc...)<p>If the reason we are all here is to get the work done why is it ok that it's a mystery what is done or not? Why is it not obvious? Why do we have to ask? Why not just keep your board or whatever up to date and talk about other things? Like surprises, blockers, questions, or concerns.
I haven't done standup in 6 months and I just feel generally better. Where I work you just report to the tech lead every 2 or 3 weeks. So much nicer than daily standups. Could you imagine other professions doing what we do?
> Stop the Daily Standup Meeting<p>Please yes! <i>Especially</i> the more dogmatic ones (e.g. <i>only</i> stating what you did yesterday, what you're going to do today, what's blocking you). It's just an empty status reporting ritual that feeds some negative emotional need of a manager (either anxiousness or a need to feel directly in control).<p>Personally, I think a freeform dev team meeting that happens 2 or 3 times a week is much more valuable. For instance: if there's a big issue going on, lets actually talk about it rather than merely stating we're working on it (and taking "offline" the only information others might actually be curious about).
I've worked both in a standard office setting and remotely. When I was in-office, I found the daily stand-ups tedious, because everyone was telling me stuff I was already aware of. But now when I am remote I find the stand-ups much more useful, because they are telling me stuff I don't already know. It's like stand-ups are overkill when the team is already working together in close quarters.
Stand ups at an agency I am currently working for on a short term engagement just has people in the tech team listing what clients they're going to be working for today. You know, because that's very helpful for everyone to know....<p>I think the spirit of agile development is lost on most places and blindly sticking to process without questioning it becomes the norm.
Never do daily meeting. Never accept daily meeting. Never participate in daily mettings.<p>That's simply too frequent.<p>People will spend all their day thinking about what they will present the next day instead of doing actual work.
I found out yesterday that a new colleague who is transferring from another department is used to having mandatory hour long daily standups.<p>We were all shocked that a manager could justify wasting that much time every single day.<p>We have no standups since we all work on different projects, we don't really need to know what everyone else is doing.
I'm a junior developer in a "Scaled Agile Framework" (SAFe, apparently) team at a VERY big company, and although we never cancel our stand ups, the format seems to exclusively be for status updates / reporting, and not "for the team". Feels like everyone else is habituated to it though, and they don't seem to mind, but it definitely bothers me. Generally lucky if a morning stand up takes 30 minutes, let alone 15.
I found the best way to make a standup successful was to put a hard limit on how long people could talk. When my teams were working the best they had a limit of 15 seconds ( I would count down while they talked ). The stand up is situational awareness not status of ongoing projects. Once the 15 second round of updates were done, if there was someone I needed more information from I would grab them after the standup to talk to them.<p>I don't really understand how a team can have a 30 minute standup, to me that is a manager who is lazy or disconnected who doesn't bother to follow the teams progress on the myriad of tools they inevitably have ( Whiteboards, Jira, Github, ..... )
I'm in a small team. I am the lone coder and I report directly to the CEO. I asked to do a standup because it's imperative for me to gain focus on tasks and frame my work. We used to have weekly status meetings but that was too infrequent. Instead of a weekly half-hour we now do 2-5 minutes of me standing in his doorway running through the "Yesterday I worked on [tasklist]. I am [not] stuck. I [don't] have resources for my tasks. Today I commit to work on [tasklist]."<p>Standup for me is making me accountable.
Ugh. Provocative, radical idea that is founded upon overly-simple, faulty assumptions. To think that the author's three categories for teams are the only three, and that standup communication only takes the forms he describes is just hubris, and leads to dangerous advice.
Appreciate the OP is about whether the stand up is for the scrum master/project manager etc or for the team members. Hopefully it is both, and mostly the later.<p>Also see in the other threads (and discussion in general) that mistakes the standups as for reporting your status to managers. That may be required in some organisations or partially, but not in most.<p>But I would view a good stand up one that does NOT require each team member to in turn state the old: "what they did yesterday, what will do toady, any impediments".<p>Instead you hope project leadership trust their team members and instead focus on the tasks. In order of task priority a participant in that story can quicklyy broadcast if anything has changed with a task/story, no need for details of what happened yesterday, no need for whom did what etc. Then if any impediments for that story, escalations, anything else etc. And just quickly rattle through them to make sure focus is maintained on getting the tasks flowing through to delivered.<p>TL;DR focus on tasks not people reporting. I ranted about this some years ago... <a href="http://blog.flurdy.com/2013/04/i-dont-care-what-you-did-yesterday-i.html" rel="nofollow">http://blog.flurdy.com/2013/04/i-dont-care-what-you-did-yest...</a>
Basically:<p>- if it's a status/reporting meeting - don't do it, there are better tools.<p>- if it's knowledge transfer meeting and it benefits a whole team - do it.
In my old job we used Geekbot [0], a Slack bot for async standup meetings. It's great for geographically distributed teams.<p>I found it made it much easier to get an idea of what people were up to, as well as providing an opening for occasional tips and suggestions. Posts typically included a mix of what you achieved, what you hope to achieve, and any blockers. Any updates or big breakthroughs were usually shared as well.<p>I think it's best to be flexible about how frequently status updates are shared, leaving it up to the developer's discretion.<p>[0] <a href="https://geekbot.io" rel="nofollow">https://geekbot.io</a>
The point of a standup is to coordinate team communication in batches and not interrupt people at random times. We always finish it up in less than 15 minutes and then small groups meet afterwards about talking points.
I can see the value of the standup but I find daily to be too often.<p>The best teams I've worked with have staggered them to either M-W-F or T-R, primarily because the work we do require more than a day. And depending how one works, a daily standup every morning makes it tough to get a good night's work in.<p>I often point people to PG's relevant essay during discussions about this: <a href="http://www.paulgraham.com/makersschedule.html" rel="nofollow">http://www.paulgraham.com/makersschedule.html</a>
I used to like standup because that's the only time I have to see what my team is soingnsince most of them are remote and working in a different time-zome. It was a great way to give tips and do the "okay let's talk about this offline afterward."<p>But now I hated it. Not only rhe standup is mismanaged ao badly, I also don't have much to update on a daily basis which means I feel useless if I have nothing to say or have little progress on my tickets.
No way, my team gets a lot of value from our standup!<p>We have 5 devs. We have a scrum master, but we rotate who's facilitating from our lead down to our most junior dev. If our scrum master's out it's no problem, any one of us is able to step up. The first ~10 minutes or so are spent updating the team on the progress we made yesterday and making sure everyone knows what they're working on today. Pretty standard fair.<p>But we always take a full 1/2 hour. We use the rest of the time for backlog grooming. It works really well for us for 2 reasons:
1. We get a lot of reactive work, and it's really convenient to have time set aside every day to address it
2. By piggybacking backlog grooming onto time that we're already scheduled to be together as a team, we cut down on the number of other meetings we need to have (and context switching to/from coding). We all find it much more convenient to spend an extra ~20 minutes together every morning so that we can have the rest of the day to work.
People, I respectfully do not agree with this blog post.<p>How people can notice that work is not being done if they don't do meetings? How to assure they are communicating correctly?
How to prevent a bomb explodes a day before the deadline?<p>If you discover problems close to the deadline, you already have a big problem. My opinion is that these daily meeting are to prevent problems, like integration between systems.<p>People are comfortable on their own doings, they don't like meetings, they prefer a problem occurs and share the blame than doing daily meetings. We must do daily meetings because it's good for the project and not because we enjoy it, we do to avoid that some lazy or introvert collaborator don't share a problem that can affect everybody.<p>That's why we have a scrum master to do the dirty job and assure everyone is talking each other.
I actually like the way we do stand ups at my current job. All of us sit together, so we just stand up in place and state what we are working on and if we have any blockers that need to be taken offline with specific ppl. Whole thing will be done under 2mins.
In regular corporate settigns, I see these standup meetings are a way to simply make information flood across organisation hierarchy. A good leader can then parse and make sense of signal amongst plenty of noise. But it does rarely serves that purpose. We used to 've standup of 10 members several years ago! Since then I kind of developed disliking towards regular meetings. Currently we 've a trello-kanban updated so that we've information flowing. And a weekly mail with traffic lights, explaining current-and-next week activities - working well so far.
Worked on a team just like described, all on different projects. It was infuriating, the boss interrupted me every morning at ten, just as I was entering the "zone" for a no value (to me) standup.
Having a >short< daily meeting is important part of any dev-team.<p>Goals are:<p>1. Discussion on who's doing what ( details )<p>2. Discussion on who did what, since last meeting.<p>3. Help / suggestions based on the conversations above.
It's fair to <i>ask</i> the team how frequently they want stand-ups. It could be daily or it could be weekly.<p>Without <i>asking</i>, standups are counter-productive.
Right now my team are trying out only doing standups if there's important stuff to share. This leads to 1-2 standups per week for the past month.<p>Tidbits of info which can be shared at a glance, and probably don't affect anybody's workflow, go on a whiteboard. That way we know everybody's status, and seems like we can share important info when it matters.
Not very convincing. But standups should be tailored for team needs, rather than imposing a standard. And I don't get the role of a Scrum Master. Good article overall in terms of encouraging discussion.
My company did standup for 3 years either in person or over hangouts (once we became distributed), and recently switched to an async model over slack. Much better engagement, and much better quality updates.
For those who do daily standups via a Slack channel, I made a little tool to help me.<p><a href="https://www.npmjs.com/package/onit" rel="nofollow">https://www.npmjs.com/package/onit</a>
stand up has to be the one good thing about scrum. the rest is just boring meetings which cost too much time entirely. but 5 minutes i can spare each day. the daily accountability it brings keeps managers from firing me (i have been fired way too many times often in the first week) as they know what i'm doing and therefore dont think i lack motivation. it also motivates me to perform even better.<p>i dont think standup is bad at all and i think managers should be present for it. it may not be for some kind of idealistic 'for the team' thing or even the original intent, but... standups are a good thing. even if you're not doing agile, standups can still be useful to keep managers informed if you are a larger team (>3 people).
The standup meeting can burn in hell. It's a lovely bit of useless micromanagement. Consider:<p>If you're organized at all, there should be notifications going out when anyone on your team commits code, or comments on tickets, or whatever. If your communications are so dysfunctional that you need to have a defined point every day to apprise people of what is going on or ask questions of your teammates, focusing on that root problem would be more effective than band-aiding it with a daily standup.<p>There's never a good time to schedule it. No matter when you do so, it's going to frig someone up and waste one to two hours of productive flow time, at best. First thing in the morning doesn't work, because people run late. Later in the morning, and you might as well kiss the whole morning goodbye for productive work. At the end of the day, it will inevitably run over and piss off everybody who needs to get the hell out of the office and take care of their personal obligations at the end of the day.<p>There's always one or two people that want to ramble along and narrate every little thing they did in excruciating detail. Or that want to turn an issue that turns up relevant to two people into an interminable status/planning meeting on that issue. Mostly, I'm just not convinced that there is any way to do a standup meeting <i>right</i>, so that it is useful for it's stated purpose without being more costly than it is worth.<p>If you need this kind of fine-grained progress reporting, have everybody send an email or a group chat with the three standup kindergarten circle-time questions answered. Then if there is an actual need to meet and go over something, you can identify the relevant people and not waste everyone else's time.<p>We ditched standup meetings a while back. It's been glorious.
My team is working on an big application with 100k+ users, worldwide, generating a couple hundred mill in revenue/year. Native apps on multiple mobile platforms, heavy enterprise stuff.<p>Tried it without stand-ups - doesn't work.<p>Once you need to coordinate heavily, care about speed and quality at the same time, working in code bases others have written you try to align with others as much as possible.<p>We do 2-3 stand-ups per week, depending on team preference. M-W-F or T-T.<p>It works, far less trial and error, far less issues found late in QA.<p>Daily is too much, that we learned. No structured stand-up at all doesn't work either, humans are not disciplined enough across large teams.<p>YMMV.