You get a quick status update of all the bits everyone is working on.

  Oh, Bob finished the xyz bit? Great I'll get started on abc now.
  Jim's stuck with the autobuzzulator? I've used those before, I'll jump in and give him a hand after the standup.
  Katie's not been able to deliver the turnip functionality? Still can't test the beets either then...

It should take no more than a few seconds per person and I find it far more effective than any agile status tool I've used, be that a physical board or an online system.

>> I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during daily work, over lunch).

I communicate well with people I'm working with in the microcosm of what I'm doing right now, but there may be a few other people on the team doing related tasks that I'm not talking to every day.

And lunchtime is my time to get a few minutes away from screens and work, take a walk, have some food etc.

If you were waiting on Bob to finish xyz, why does he wait up to a day before telling you he's done?

After doing scrum for a few years, my impression is that stand-ups are useless because you can't depend on them. They're frequently too far away to be used for the purposes you're talking about, so you always need an alternative. If that alternative is good, you might as well always use it and cancel the meeting.

I'm not sure I was waiting for bob, I probably have other tasks too.

I don't know of a better alternative that maintains the face to face element.

The point is: are you really interested in what those people are working on? If you are, then you should communicate with them much more often than once every 24 hours, or have decent conversations with them. A few seconds aren't enough anyway. If you're not, then scrum is a frustrating waste of time.

Also, if the company has more than a few devs, scrum meetings are usually limited to your team. And you should already know what your team members are working on - if you don't, then your team has serious communication issues, scrum or not scrum.

>> The point is: are you really interested in what those people are working on? If you are, then you should communicate with them much more often than once every 24 hours

I don't believe this is true. I can be interested but not directly involved all the time.

>> And you should already know what your team members are working on

This is exactly what the standup is for.

I prefer ditching standups in favor of constant communication, people should know who they need to talk to and avoid waiting for specific checkpoints.

A not-too-long team meeting once or twice a week to talk about big themes is pretty reasonable, but usually I can't even remember what is said in a standup, because much of it isn't things I need to remember.

If it's forced short, there's usually not enough data, if it's it's too long, everything gets tuned out. It's really another kind of status meeting, and I think meetings should instead produce actionable items.

As I said to the other response like this, I dislike team meetings as without strong leadership (something I have found lacking in a lot of places) it usually degenerates into an hour or more of griping and grandstanding.

You don't really need to remember exactly what's said in a standup, IMHO, participate in it and offer your skills or resources to help other people who are stuck, and get an idea of what's going on.

Yeah, those could be bad. I've always seen it done with strong team leads or technical managers when they existed instead of standups. I have seen that devolve though, and I know what you mean.

I was very hands on when running meetings when I did it that way. Usually had an agenda, broke when we didn't have anything else to do, and kept on topic.

> It should take no more than a few seconds per person and I find it far more effective than any agile status tool I've used, be that a physical board or an online system.

Isn't that information already on your planning board? Likewise, it should only take a minute to review the planning board updates each day and you should be getting direct notifications for things you're suppose to be helping on.

I can see the value in you all getting together to have a high-level chat on how things are going maybe once a week but every single day is way too much for me.

Personally I hate weekly meetings as, unless you have strong leadership (rare) they turn into long, boring gripe-fests.

Yes thank you. I think the reality of DSM don't live up to their theoretical usefulness.

I think even in a small team where everyone keep it short it's just too much information. I can already see what everyone is doing on Jira/etc and later on git in my IDE, the rest don't stick.

I have tested people by asking them less than 30mn after a DSM questions about who is doing what and nobody could answer and yet they usually can't admit that DSM are mostly worthless.

I also hate DSM when I'm on a long task because I just say the same thing everyday and feel like a slacker. At which point do you start to game the system and only pick short easy tasks ?

I guess maybe Scrum and agile appeal more to young devs ? They seem to like the gamification aspect of it, moving post-its, feeling great by under-estimating tasks' length, the flatness of the team.

Myself I would prefer a competent project manager instead of those empowering retrospectives and those velocity charts that could be turning against you by management any day.

Over dramatization aside :) and in good spirit about the article I would prefer Kanban to Scrum but it seems way less used (at least in webdev).

> I also hate DSM when I'm on a long task because I just say the same thing everyday and feel like a slacker. At which point do you start to game the system and only pick short easy tasks ?

I've had that feeling too. You feel like dropping the long tricky important task you're doing to complete a couple of easy ones so you have something better sounding to say for the impending standup. A similar and much worse situation happens when you have to give client demos too often I find.

If you have a long important task, then surely you can break it down into sub-tasks that take less than a day to implement? Not just for the sake of having something to say in the daily status meeting, but to be able to manage your own work and evaluate your progress? In my own work, I find that anything taking longer than a day benefits from my doing some planning and task breakdown.

If it's possible, sure, but you always get these problems you never predicted where you burn hours getting nowhere. I really meant a task that turns out to be unpredictably lengthy, annoying and tricky.

Pretty often it's also a sign that Scrum and DSMs have been imposed on the team by their managers and/or PMs. Scrum is meant to be a tool for the dev team to self-organize. When it's not a bottom up effort (coming from the dev team based on their actual needs) it devolves into a micromanagement framework.

You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers.

It's important for everyone on the team to know what others are doing in order to share knowledge. If people are zoning out, you're not getting that benefit.

> You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers.

Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.

There is a unique motivating factor to standing in front of your peers and saying you didn't get anything finished yesterday. That is, in my opinion, the entire point of the stand up. Everyone knows they are going to have to say something tomorrow and that adds some impetus to finishing their task as quickly as possible.

It adds impetus to appear busy and/or find something to report. I think it was said higher in this discussion: recurring meetings are a form of "social engineering"; and I'll follow that with an assertion that they have more affect on the structure of the team (and individuals therein) than they do on the effort the team is nominally working to achieve.

If you want to build software systems, you should engage in software engineering, not social engineering. Social engineering only supports the manager hierarchy which is probably at that point misaligned with value production.

If I were a deep cynic (instead of just a natural contrarian), I could say they expose the manager as someone who cannot command respect unless they are intimidating subordinates into the social risk of showing themselves impotent to achieve on a day to day basis.

If a manager doesn't know what his team is up to before the meeting, he's not doing a good job. Perhaps because he doesn't already command the respect of the team?

Can "drum-beat" scheduling help in crunch times? Probably. If you are always in a crunch time, the scale of your efforts probably are probably going to shrink, and/or you may lack time to make longer range plans and are effectively navigating without a map.

I think motivating factor is the least helpful thing stand ups provide so your assertions are slightly correct if that was the goal of stand ups.

Stand ups actually provide:

1.) Better communication of what everyone is working on.

2.) This leads to faster cross training as people are able to ask questions.

3.) Making others on the team aware of issues you are working on so they don't make bad assumptions that you're not doing anything etc.

4.) Social engineering shouldn't work here much as far as being lazy. Good team leads and coworkers will ask to help out should they see someone dragging there feet. Your coworker should be doing code reviews or know about how long it takes to setup a server. It should be pretty obvious if you manipulating, at least I've found it is.

5.) In the past 2 months we have let two people go because standups revealed they weren't really doing anything. Stand ups gave us a chance daily to ask what have you done? It gave the chance for a coworker to step in and help out. It identified this person just didn't want to work and we replaced him with someone who did.

>>> If a manager doesn't know what his team is up to before the meeting, he's not doing a good job. Perhaps because he doesn't already command the respect of the team?

I disagree. A good manager should have a broad overview of what's going on but, he should be busy in his own job planning etc. to not have to micromanage. A 15 minute stand up each day gives him insight he needs without standing over anyone's shoulder or worse making false assumptions about what they might not be doing.

"better communication" and "cross training" are the biggest misconceptions about the stand-ups. A good/proper standup is short and there's no way to communicate and exchange enough detailed information and context to make it a meaningful communication and especially cross training tool. Standups are meant for peer-to-peer coordination on the dev team. This leads to another misconception... Standups are not status reports for managers. The manager's primary job is to support his/her team and to be aware of what's going on to facilitate the team needs and to resolve external blockers. Sitting in his/her ivory tower planning stuff is not it :-)

If the dev team isn't coordinating and communicating outside the meeting, then you have problems the meeting isn't going to solve.

I do agree with you that a manager's job is to support the team, and not the other way around.

1) Better how? For whom? What's your metric on that and does it hold true in all circumstances and contexts? I'd make a general assertion that "better" communication is written communication as it is more easily reviewed later and by parties not originally involved. An asynchronous persistent communication channel beats a synchronous one when you need to coordinate non-synchronous activity (which often involves coordinating with external teams and stakeholders).

2) People can ask questions at any time, but in a meeting only one person can really have the floor so provides a synchronous block on communication for anyone not involved in the exchange.

3) "Making others aware" so they don't think "you're not doing anything", is the social pressure "face-saving" style I believe has nothing to do with software engineering (at best). At worse, if your entire team is obsessing that you have less to do than they are doing, then they have way too much time to obsess with, probably the time they spend in those meetings; they should take it up with management, who should have knowledge on what's going on anyway due to status reports and a general involvement with the team in an ongoing basis.

...

>>> I disagree. A good manager should have a broad overview of what's going on but, he should be busy in his own job planning etc. to not have to micromanage. A 15 minute stand up each day gives him insight he needs without standing over anyone's shoulder or worse making false assumptions about what they might not be doing.

The term micro-manage is yours not mine. A 15 minute stand-up gives him the power to assert that for 15 minutes each day, he is the alpha-male. That's really all face-time meetings like that do when it is between subordinates and superiors. For everyone else, its a jockeying up position and pecking order. Welcome to the primate side of human culture; I didn't make the rules I simply observe them every time I see it happen.

If he can't get what he needs without appearing to be micro-managing, he lacks the social skills to manage with greatness. But he'll be in fine company as most of his management peers are roughly equivalent. From my own experience good managers are few and far between because to be a good technology manager you need to be a good manager and a good technologist.

However, if a manager is going to pick a team management religion, he'd do best with Zen.

I think stand-ups are valuable, but not for this reason. It is simple to exaggerate the unexpected difficulties of a task. You can watch videos on YouTube all day today and tomorrow say, "Yesterday I worked on auto frobbing widgets but ran into difficulties with the foo widget because it didn't frob correctly. Today I'll be fixing the foo widget and completing the auto frobber".

No one will bat an eye (so long as you put meaningful terms in there) until this happens for several days in a row. Nor should they, because the micromanaging alternative is worse.

Stand-ups aren't a motivating factor for typical developers. It drives some accountability for people who are just accomplishing nothing for weeks, but that could be accomplished by looking at the checkins once a week, too.

[edit: phone typos]

Interesting conversation, I appreciate it.

While it is always possible to use any activity for social engineering or shaming (feeling like a school kid) I don't really see that as a good description of the stand ups effect. It is a "deadline" that is artificially imposed, on a particular task.

In my experience good developers have a wide variety of things they could be working on at any given time, and those things have different weights and different "fun" factors. Without some sort of time limit it is possible to get lots and lots and lots of stuff done without the rest of the team being able to move forward. So once you've agreed on the tasks that need to get done, having a deadline to finish them helps prioritize and focus the activity.

My experience is that bad management is completely orthogonal to process. Any process can be abused by a poor manager in ways that are detrimental to the team, and a good manager can keep a team motivated and productive even with a bad process.

So I don't think stand ups are about "managing" teams, they are a good tool to focus you on what, of the many choices you have, you should be working on right now. Oddly enough, the more senior you get as a developer, the harder it is to get that level of clarity.

Sounds like being treated like a school kid to me

Because some things just pop up during the conversation.

Another benefit of hard allocated blocks of time for standup - they're explicitly grabbing people's attention. It's very easy to ignore stuff on the board, if you're not directly involved in it, but if you are simply in the room, listening to other people, you may contribute something useful to the otherwise unrelated conversation.

Plus the real sharing of knowledge happens in ad hoc meetings outside of the standup when people talk about details of the issues-- things you can't talk about in the standup.

One thing is you can have a conversation about things and ask questions about what you're stuck on.

It's also much faster and more fun than writing some mini-report on a planning board people may or may not read.

But the most important thing is that it is quick and encapsulated. Only about things the whole teams need to know. You need to be happy with reporting that nothing interesting for the whole team happened.

No, at the standup you shouldn't have conversations about things. You should just do a quick recap of what you've been doing and what you'll work on. It's a standup because it's meant to be very quick.

On the other hand, if you need a standup to ask questions about stuff you're stuck on, then your work environment has serious issues. It might be 24 hours until the next standup. You need to have colleagues who are available and willing to communicate during most of the office hours - confining this to the standups means that there are issues either at the organization level or, more probably, at personal level.

Personally, I've had more than enough of work environments where standups are used "because we have to communicate" - and then some of your colleagues spend the whole day with earphones on (= impossible to shout a question on the fly) and other look pissed off whenever you ask anything.

It should not turn into long discussions, but if standup is for mentioning what you're stuck on, it seems really strange that others are forbidden from mentioning how to get unstuck.

I'm used to pair programming and communicating all through the day. This is incompatible with the surly loner programmers you describe in the last paragraph.

Are you blocking a whole bored and standing team to get help from a workmate on an issue that is relevant to you only? I hope not. I think the Agile orthodoxy prescribes that any conversation that lasts more than a few tens of seconds should be saved for after the standup. And it makes sense. However, if you were stuck on something, then you've probably been for some time before the standup. So I guess you had plenty of time to ask that knowledgeable team member before.

As for the lone programmers you haven't met: lucky you. I seriously believe that in the "agile" companies I've worked in, scrum was actually intended to make people talk, if only once a day and for a few minutes. What was that line? Ah yes: "individuals and interaction over processes and tools". Good luck.

Yeah, a few tens of seconds is all I'm talking about too. We may differ mostly in terminology.

Typically when someone says "we're a little stuck on how to do X" someone else chimes in with how to do it. No big (or small) list of questions to discuss.

If the meeting is done right, the team is not bored, and what's discussed is interesting to the whole team, since we collectively own the code base.

I've definitely met those loner programmers. I might even have been a little like that a long time ago. They can do great work, but need to be kept out of my agile teams.

The way to get people to talk about the work is to pair program. I'm not interested in working solo programming.

I find that many of the colleagues who spend the day with earphones on are regularly available on chat. Isn't that a much better way to communicate rather than assume your problem is the most important and worth disrupting other people from their work?

Yes but either you don't know what they're talking about (different part of the project), or already know what they're talking about (because you are a tight team). So, zone out. Who's the Punch and Judy show for?

At least where I work (Pivotal) where we are often rotating between pairs, and changing tracks of work in the order of every day to every few days, being kept up to date on the state of the rest of the work is useful.

Additionally, we use it as a chance to bring up anything we need help with, or anything we found interesting in the last day, which wasn't important enough to interrupt the rest of the team with.

> where we are often rotating between pairs, and changing tracks of work in the order of every day to every few days

These sort of working arrangements sound horribly inefficient. How do you ever get enough real familiarity with what you're actually doing when you're getting jerked around to something different every couple days? It sounds like being constantly on the treadmill.

you are in between those 2 extremes and standups are useful?

Right - some fraction of the team isn't zoned out, sure. Maybe working on the communication skills of those remaining ones is a better idea, than derailing everybody for a standup.

No matter how tight you make the stand up, it still creates an artificial time to do a disruptive start/stop. A 5 minute meeting really leads to close to an hour of derailment. http://paulgraham.com/makersschedule.html summarizes it better than I ever can.

If your team communicates effortlessly with each other and the stakeholders anyway, you don't really needs scrum, at least not now. But most places where scrum has made a difference, individual maker productivity is not the limiting factor, so even an hour of disruption is worth the cost.

Usually it's the managers who find it helpful - for them. Getting verbal confirmation from everyone of what's on the board.

Which can be incredibly important if the manager has to report to someone as well.

... and can't find the ticket that has that info

The value is in creating a summary, to collect all the stream of conscience updates into a coherent statement about status and next steps. A daily standup of summaries removes the burden of mentally remembering yesterday's minutiae to reconstruct the current state.

I mean, if you want to know the status of a system do you go to the dashboard or do you go review every system event for the past few hours? I hope not the latter! That's what you do when something seems off, which is exactly the case too for daily standups. If something doesn't seem right, you go review discussions and updates.

Also, at the risk of triggering on standup philosophy, I do believe that zoning out during standups mean it's being done poorly: updates are too long or people are not engaging each other. That's the problem to fix, by setting an example of good habits yourself: cut off rambling, encourage active cross-questioning and ideas, etc.

>Scrummerfall

My classically trained PM after taking an Agile training class:

    First we'll have a planning sprint.
    Then we'll have a coding sprint,
    Followed by a testing sprint...

Having seen some of how the sausage of dashboards get made, you go look at the real data, not the fancy crap that is thrown on the dashboard to sell the product in demos...

My current team does not do standups (or Scrum or... any of these things, really). We have a rolling list of open features/cleanups/bugs and a polite triage convention. In my last company we were all-in on what I can only call Scrummerfall.

As far as I can tell, the effectiveness of the team has a lot more to do with people's ability to self manage their workload (under any system) than how much time and effort is dedicated to tracking it.

We are also able to provide other dependent teams with better day to day visibility on specific requests rather than sprint-level visibility.

> I find most people zone out during the standup

Out of curiosity, how long do your standups last? How big is the team?

15 (goal) minutes with a 10 person team.

Everybody didn't zone out every day, but most did, most of the time.

It's also detrimental to morale when you realize that other people are zoned out through standup. Nothing much more frustrating than when a coworker asks a question that was answered in the "meeting" we were all just in.

Frankly, it's a huge opportunity for the listeners to shine. (Yay for being a listener)

Exactly. It's a waste of time. Best to give a direct message or face-to-face telling the person what they need to know. Or not say anything if nothing is needed. At most, I'd say weekly meetings that were a mix of tracking project status and fun just for team-building purposes. Keeping people connected.

I'm a project manager/scrum master, with a team that varies from 6 to 12 (roughly half the team is semi-permanently on-loan to other related projects/teams).

My daily stand-up is usually 5-10 minutes. About 5 minutes of the standard "what I did, what I plan to do, and what's in my way". And 0-5 minutes of resolving problems (figuring out if I need to escalate, or if another team needs to be involved, etc). Anything longer than that, and we schedule follow-up meetings with a more correct set of attendees.

I've found this with big and small teams. With small teams you already know what everyone is up to and with larger ones the meetings go on for longer.

You want people to elaborate on the concept that standups "keep people aligned on the work"

Like you want a bunch of examples? How do you have some much patience for that if a standup interrupts your work?

Maybe you have them at the wrong time. We have one at 9:30 and it works. People who arrive early are pretty much cranking and the standup is a break from that. People who arrive later (me) show up and it's the first thing of the day goes with a cup of coffee or tea.

Any breakouts can happen right after, have those discussions at somebody's desk while you're already interrupted and THEN jump into the long stretch till lunch. I don't really see the interruption there.

Even if I get bored and dont' know what people are talking about some of the time, I'd say it'd be pretty selfish of me to claim that they are a waste of time. And it would also be stupid of me to think that something sent in an email or commmented on slack or lync is enough. I mean if you could send a message and everyone got it the first time, I think there wouldn't be a concept of marketing or advertising in the world. Sometimes people need to hear things twice.

I guess I'm just not big on keeping work in a black box. And I think it's comical and sad that we go to jobs and stare at screens all day. face to face interaction and having to express yourself to a group for a measly 30 seconds a day is a positive. It might even force a few of us to consider our appearance too. And frankly, I think I'm paid to answer questions and be available to people as needed, so a standup is meant to be an efficient way to do that and it's supposed to encourage brevity. If it's not, start communicating push it in that direction.

I think the standup meeting is there because it follows the first principle of the Agile Manifesto:

"Individuals and interactions over processes and tools"

I thought that the scrum meeting is a process. The whole Agile thing is a strictly defined process. That needs a lot of specific tools too.

Correct, Agile is a development process. As for needing tools, at least scrum doesn't need anything more than pen and paper to generate its artifacts: 2 lists (backlogs) and a chart (burndown).