Are stand-ups (meetings) getting mainstream?(online.wsj.com)
online.wsj.com
Are stand-ups (meetings) getting mainstream?
http://online.wsj.com/article/SB10001424052970204652904577193460472598378.html?mod=WSJ_hp_mostpop_read
19 comments
Arbitrary schedule and bad habits about wasting time on stupid problems aside, I'd agree that a standup for a well functioning, co-located dev team is largely going to be redundant.
The most value I've found in standups are when you have a cross functional team that can communicate status on different things to everyone all at once. BAs, QAs, devs, IM/PM, and product owners aren't all going to stay up to date with each other naturally on most teams.
Of course, if teams are working in very long iterations with out-of-cycle QA then each functional aspect of the team staying up to date with each other on a daily basis yields less value. Such a setup tends to bring about other problems in many scenarios though.
In the end it's all about context. To say a daily standup is a stupid practice without context (implying in any context) is a bit too broad of a statement IMHO.
The most value I've found in standups are when you have a cross functional team that can communicate status on different things to everyone all at once. BAs, QAs, devs, IM/PM, and product owners aren't all going to stay up to date with each other naturally on most teams.
Of course, if teams are working in very long iterations with out-of-cycle QA then each functional aspect of the team staying up to date with each other on a daily basis yields less value. Such a setup tends to bring about other problems in many scenarios though.
In the end it's all about context. To say a daily standup is a stupid practice without context (implying in any context) is a bit too broad of a statement IMHO.
Thing is:
1. In general, I'd like to receive information asynchronously. Meetings should be for solving problems. They're a team-mutex, and mutexes should be avoided.
2. Standups are generally by definition, not for solving problems.
1. In general, I'd like to receive information asynchronously. Meetings should be for solving problems. They're a team-mutex, and mutexes should be avoided.
2. Standups are generally by definition, not for solving problems.
Standups are good for both surfacing as well as identifying problems (e.g. things that don't appear to be problems).
Standups aside, sure, ssync information is good. However, it's not nearly as rich as face to face communication.
I'm not sure why you say meetings should be for solving problems. The majority of my meetings are about sharing information and planning. I solve problems at my desk.
Standups aside, sure, ssync information is good. However, it's not nearly as rich as face to face communication.
I'm not sure why you say meetings should be for solving problems. The majority of my meetings are about sharing information and planning. I solve problems at my desk.
I've worked at places with these meetings. I was always talking to people who either already knew the information or didn't need to hear about it every day. In that setting a quick weekly status update would have made more sense.
Two other unfortunate things happened at one place that were I guess more a sign of dysfunction than a problem with stand ups per se. First, there was an arms race of "what I did yesterday" type descriptions that turned stand ups into a 30-minute production. Second, our manager had a habit of calling people out in the meetings in front of everybody (!). It created a stressful situation where people rambled on about nothing at length every morning. Stand ups were probably the least desirable part of that job.
Two other unfortunate things happened at one place that were I guess more a sign of dysfunction than a problem with stand ups per se. First, there was an arms race of "what I did yesterday" type descriptions that turned stand ups into a 30-minute production. Second, our manager had a habit of calling people out in the meetings in front of everybody (!). It created a stressful situation where people rambled on about nothing at length every morning. Stand ups were probably the least desirable part of that job.
Stand-ups are trying to push a rope. Good teams already know how to communicate well, and know how often they need to talk. Often, it's unconscious. It just works.
On bad teams, it's not going to help, and it will eventually become a source of irritation and resentment.
On good teams (which are humming along just fine, thank you), the process becomes an irritation and a resentment.
On bad teams, it's not going to help, and it will eventually become a source of irritation and resentment.
On good teams (which are humming along just fine, thank you), the process becomes an irritation and a resentment.
What about the following:
What if you had a team dashboard, minimalist in style. It had a selection whereby you could choose one of 3 status for how your efforts were going: Red, Orange, Green.
At a certain time, you are prompted to pick one of the 3 status.
All team members pick their status - and the lead gets a weighted summary of overall status. If too many orange/red status are selected the team meeting gets called - if more green/orange then he can choose to defer, if mostly green then it says no meeting necessary.
You'll never know what other members pick and, by default, the lead wont know who picked what (unless he wanted to audit).
This would be an non-intrusive method of polling the team, without risk, as to whether or not a meeting was required.
What if you had a team dashboard, minimalist in style. It had a selection whereby you could choose one of 3 status for how your efforts were going: Red, Orange, Green.
At a certain time, you are prompted to pick one of the 3 status.
All team members pick their status - and the lead gets a weighted summary of overall status. If too many orange/red status are selected the team meeting gets called - if more green/orange then he can choose to defer, if mostly green then it says no meeting necessary.
You'll never know what other members pick and, by default, the lead wont know who picked what (unless he wanted to audit).
This would be an non-intrusive method of polling the team, without risk, as to whether or not a meeting was required.
I'm not sure I understand.. "won't know who picked what", and "without risk".. Are you trying to solve the problem of people being afraid to report that things aren't going great?
I think that's a dysfunction that should be repaired, not institutionalized.
I think that's a dysfunction that should be repaired, not institutionalized.
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?
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.
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).
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.
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.
[1] http://news.ycombinator.com/item?id=97953 [2] https://en.wikipedia.org/wiki/Working_memory [3] https://en.wikipedia.org/wiki/Decision_fatigue
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.
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).
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.
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.
[1] http://news.ycombinator.com/item?id=97953 [2] https://en.wikipedia.org/wiki/Working_memory [3] https://en.wikipedia.org/wiki/Decision_fatigue
After a few weeks of daily meetings, even brief ones, the quality of information being communicated really decreases.
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.
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.
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.
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.
Do any larger companies (Google, Apple, etc) implement stand-ups? I'm curious to know if this is being adopted by companies with larger staff numbers.
They do. SCRUM morning meeting in our case.
I don't particularly like them because I don't really care what 20 other people have been working on yesterday, and we generally unblock ourselves immediately instead of waiting for next day's meeting, so that's not helpful either.
I don't particularly like them because I don't really care what 20 other people have been working on yesterday, and we generally unblock ourselves immediately instead of waiting for next day's meeting, so that's not helpful either.
Most teams that I know of at Amazon do. The 2 teams I have been on aren't so strict about the whole "you MUST stand up" part though.
While I was working at a completely unrelated company that started off as a book store and turned into a global online retailer and PaaS provider there was a period of several months when my team was doing standups every day of around a dozen people (devs, test, mgmt) which tended to last anywhere from half an hour to an hour and a half.
At Google it varies by team. Each team figures out what works for it. Outside of code reviews and code style, there is little that is dictated company wide.
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.
This just makes it worse.
This just makes it worse.
It's a "brute force" way to get people to communicate on a team.
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.