The first couple of times I was in a group that implemented daily standups, I was encouraged.. Seemed like it might increase operational awareness in a lightweight way. I was wrong. I think they're stupid.<p>The day-boundary is arbitrary. It encourages someone who gets stuck on something at 2pm to spend the rest of the day banging on it and bring it up tomorrow. Or, in better functioning teams, we deal with it at 2pm and the standups become irrelevant. That was what I found.. is that as a team lead I knew what everyone was doing before we met in the morning. Another popular tendency is to pull in PM, or maybe my boss.. but then I get to waste 6 people's time trying to communicate what's happening to them on a still-arbitrary schedule.
Why interrupt what people are doing to organise a "meeting" that consists entirely of content that is much better read directly from a collaborative project management/issue tracking tool?<p>A meeting may only be 10 minutes long but the loss of productivity is likely going to be significantly higher. Employees will need to page out[1][2] what they've been working on -- a very expensive process.<p>Managers should be ensuring that employees have quick and easy access to information of relevance on demand, rather than on an arbitrary time scale. Issue tracking software (web based for simplicity) allows teams to view and contribute to the big picture at a time that works best for each employee. These systems require full time staff to actively maintain them. Typical duties could include sorting and filtering information (via way of updating fields on an issue), creating links between issues to aid planning and discoverability, correcting mistakes, ensuring consistency and monitoring usage to implement improvements (particularly simplifying and automating the system).<p>This isn't a disguised plea for ISO 9001 Quality Management Systems because it focuses on the users (employees) getting their work done -- not rigid and inflexible processes for the sake of standards compliance. Most quality management approaches I've come across fail because they are burdensome to getting real work done. They're not user friendly. They're typically rigid and deterministic in design where the actual work is flexible and probabilistic. Users are left wondering how their use of the system actually helps the project -- there is no clear link. Tedious manual work is required where an automated approach could be implemented. The systems become too complex for anyone to comprehend. Coming back to the paging[1][2] analogy, users run out of working memory before they get a chance to input or retrieve data to/from the system -- it's all wasted on deciding[3] which button from 50 needs to be pressed.<p>Human interaction factors and cognitive science are crucial to this discussion. It is disappointing to read that many companies are blindly accepting stand-up meetings as common practice without consideration to the well established science behind organisational communication/teamwork.<p>[1] <a href="http://news.ycombinator.com/item?id=97953" rel="nofollow">http://news.ycombinator.com/item?id=97953</a>
[2] <a href="https://en.wikipedia.org/wiki/Working_memory" rel="nofollow">https://en.wikipedia.org/wiki/Working_memory</a>
[3] <a href="https://en.wikipedia.org/wiki/Decision_fatigue" rel="nofollow">https://en.wikipedia.org/wiki/Decision_fatigue</a>
After a few weeks of daily meetings, even brief ones, the quality of information being communicated really decreases.<p>I've had better results where:
A) frequency of team meetings increases as deadlines get closer, going from once per week to 2x per day if needed.
B) every day managers spend 5-10 minutes of 1-on-1 time with each team member actually inspecting their work.
The startup I currently work for uses stand-up scrum's in the morning to discuss what one has crushed the day before (completed items) and what one is going to crush today. This is also the time to explain to the various different teams (Android/Java API, C++ api, server/backend) what you changed, what things they need you to be aware of and what requires more meetings and or having a time where a switch-over is required do to changing something that touches all teams or some of the teams. For example, letting the other teams know that DNS entries now server ULA IPv6 addresses as well as IPv4 addresses and they should probably do testing to verify everything still functions.<p>It works for us, although sometimes the meetings can be a drag when the day before you spent a lot of time in meetings and you don't have a lot of input. It is one way of kinda putting you on the spot if you aren't producing anything which keeps people accountable.
The idea of stand-ups seems to stem from agile and development houses, but we network/unix admins have daily stand-up meetings with developers/operations too. We chat about what we did last 24, and what we want to do next 24, and if there are any issues we need help with. Helps to iron out any road blocks. I was really hesitant as first, and I think the group as a whole looked down on the idea, but it had really turned things around, and we are working much better as a team. Occasionally we go off on tangents, but it's nice to know what people are working on, and keeps people from slacking off when you're waiting for something.
If I worked for a company that forced me to go to "stand-ups", I probably wouldn't contribute much to the meeting. As it is, I hate these sorts of meetings.<p>This just makes it worse.