[seanwilson]

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

[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

[jimbobimbo]

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.

[MCRed]

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.

[BurningFrog]

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.

[Udik]

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.

[BurningFrog]

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.

[Udik]

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.

[BurningFrog]

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.

[spinningarrow]

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?