[ChuckMcM]

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.

[sageikosa]

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.

[dsmithatx]

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.

[kylequest]

"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 :-)

[sageikosa]

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.

[sageikosa]

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.

[dpark]

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]

[ChuckMcM]

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.

[theinternetman]

Sounds like being treated like a school kid to me