Daily Meetings Are Great but You Should Never Have Them
wellbredgrapefruit.com
wellbredgrapefruit.com
Sorry, not even going to bother with non-snark response. I did that the 32903 times before, and someone else already took the bait.
But I'll bite on this though:
> All meetings are terrible.
Meetings can be awesome. I've been to meetings full of great new ideas. I've been in meetings that saved companies. I've been in meetings in which shit was actually decided and followed up on!
I've been in meetings that lasted for days(!) but eliminated months of painful processes and left people feeling exhausted but victorious.
Meetings can be great. Meetings can be fun. Meetings can have a purpose. Meetings can have results. Meetings can change the world.
It's badly organized, forced and unproductive meetings with the wrong people that suck. Guess what, that applies to virtually any activity with a group of people. Including orgies. Especially orgies.
I need to make a web page about standups and just start posting links to it. It's the same question time after time, and I keep thinking I'm going to forget part of the answer.
Standups are not meetings, at least not like I know them. Some teams have "standups" while doing a morning walk. Some meet at the coffee shop. Some have stopwatches and pigs and chickens and all sorts of other things. So what? Meetings usually involve sitting around, an agenda, a leader, a desired set of outcomes, and so forth. Standups really don't have any of that in the traditional sense. The output from a standup is just an informal agenda for the day. People meet, they discuss what's up, they break up and informally get together to do stuff. Standups are designed to prevent meetings, not be another one.
"Because it’s the information that’s great: the meetings are time-sinks."
No, it's about non-verbal communication and social interaction around common team problems. We've found that listing the 3 things helps do that. You might get the same effect with having each person act out an improv based on their feelings. I don't know. Give it a shot. But it's not about information. No. No. No, no no. Technology teams are made of people, not robots, and the work of everybody getting on the same page and keeping up is a human job full of social nuance, not the exchange of status information.
Later on we get here:
"...the only benefit to having a meeting is the face-to-face discussion that it allows for. Or, to put it another way: if you’re structuring your meeting around trying to eliminate anything that isn’t a two-minute “this is what I did/am doing/am having trouble with” update, why are you having a meeting at all?"
"Discussion" a much better word, but you're once again assuming that it's all some kind of information flow happening. The hardest part of working in technology teams is the social factor, not the bandwidth of information flow. Standups are about physically looking each other in the eye, figuring out where everybody is, and figuring out if you can help. It's not information, and it's really not discussion.
I'll put in a plug for anybody that's interested: I've created a no-frills "Agile Team Tune-up" email course. No selling, just a weekly concept explained with ways to apply in your team. If you're interested, here's the sign-up: http://bit.ly/15sz0Pl
I don't know... for most "here's what I did yesterday, here's what I'm doing today, here are my blockers" type meetings, I don't see that "look 'em in the eye" is that critical and certainly not on a daily basis. At least that's been my experience. Maybe if you're trying to read body language to see if somebody is more afraid than they're letting on, or to try and pick up if somebody is sandbagging or something. But that's why I advocate for a compromise of cutting the meatspace meetings back a little in frequency (but not necessarily eliminating them) and replacing some of the meetings with a technology solution.
The standups do have a cost, even the ones that stick to the short and sweet "nobody talks more than 2 minutes and we're out of here in 15" ones. For example, they still force a context switch, and depending on when in the day they are scheduled, they can really f%!# with somebody's ability to get into - and stay in - "flow state".
they can really f%!# with somebody's ability to get into - and stay in - "flow state"
I call BS. I can't for the life of me, find one consistent thing that can either get me into or get me out of a state of flow. It just happens. If you know the answer than I can create and scale the most perfect team of human engineers ever on this planet.
Depends on what time it's scheduled, and what time you come in. Could be anything.
If you're standup is first thing when you get into the office, your context switch is from a cup of coffee.
Absolutely. And if every member of your team arrives at the same time, and that time happens to coincide with "time to grab a cup of coffee then beat it to the room for the meeting" then sure, that makes sense. I haven't found that to be the case for most of the teams I've worked on.
I call BS. I can't for the life of me, find one consistent thing that can either get me into or get me out of a state of flow.
I can't identify one specific thing to get into flow state, but I can give you a laundry list of things that will break my "flow" once I get there. And having to go to a meeting is pretty much at the top of the list. shrug
In Scrum, for example, a daily project team meeting occurs. It’s called a daily scrum, or stand-up. The stand-up has guidelines, including limiting the meeting length to 15 minutes. My experience is that this never occurs – stand-ups usually run on for at least half an hour, during which I’m subjected to anecdotes, show-offs, excuses and, if I’m really unlucky, insinuations and blame. The worst stand-ups include managers – their presence turns any self-respecting stand-up into a status report.
Ref. http://www.wittenburg.co.uk/Entry.aspx?id=dce9dde8-d770-47c2...
I'm contrasting this with the typical work break, where the team breaks into individuals for 10-15 minutes and everyone goes to a different location (water cooler, phone, bathroom, outdoors to smoke or stretch or walk).
When you find you're getting away from something that was working... just go back to it. If there are anecdotes and side stories, develop a system where you can stop them.
If they run long, that's when a timer can be useful. Whether it's a series of 2 minute timers or a 15 minute one.
Don't slam an entire system because "it 'inevitably' stops working," just go fix it.
If you're working in a place with a screwed-up culture, a daily stand-up will make a number of the dysfunctions obvious. Removing the meetings doesn't make things better, it just makes the problems subtler, and therefore harder to fix.
Anyhow, I also see plenty of places that make this work well.
In meetings, the time lost is obvious. Which is why people focus on doing them well. By moving it to email, you're not saving time; you're just hiding it. And, I'm sure, increasing it.
I'm a fast writer. I practice pretty much every day. But there is no way I could write my standup contributions as quickly as just saying them. I'd guess writing is 5-10x as long. In a stand-up, I can point at the board and say, "I'm done with this; it was easy. I'm still working on that; it got hairy." If somebody needs more, I can see it on their face and raise an eyebrow; they'll ask me what they need to know.
To write a decent status update, I have to guess at all the reasonable questions and head most of them off. It is much more work. And then to keep up, I have to check my email. And integrate each person's comments with everybody else's to try to form a coherent picture. And then to follow up on the mysterious bits. A giant waste. I try to keep email off my coding machines entirely; distraction is a productivity-killer.
This also ignores so much of what I get out of stand-ups. I can see who's happy and who's dragging. I get an easy opportunity to grab somebody for a quick discussion. I get information through tone of voice, posture, and expression. Information about relationships, about features, about code. I get charged up at the beginning of the day knowing that we are all diving in on the same thing.
I think the assumption here is that there is a very limited set of basic questions that apply to everybody and that become the default. For example: "What did you work on yesterday?" "What are you working on today?" "Do you have any blockers or concerns?" If you just got everybody to submit those three questions and their answers, it would go a long way.
I guess it could be that people were answering those things in an entirely dull way. In which case, no wonder the meeting was seen as worthless. I'd suggest putting the boring information in a shared artifact. Personally, I tend to use as physical board. I also see virtual teams using a virtual board (like Trello) for that.
The value of the stand-up is in what people say that goes beyond the obvious.
I agree. I just don't necessarily think that you need that level of interaction for a status meeting every day. OK, maybe some teams do.. and I can see why some people might prefer it. But my experience has been that it's overkill.
That said, different teams, different cultures, different situations, could definitely dictate different approaches.
My biggest gripe with the daily meetings is that they force a context switch that somehow seems to always come at the most awkward possible time, no matter when you schedule the meeting. Requiring lots of face-to-face meetings also runs counter to the idea of having distributed teams and a lot of "work remotely" flexibility, which I also tend to favor.
But, again, YMMV.
I usually work in exploratory, high-volatility contexts, where there's plenty to talk about. I also favor continuous deployment; I think the last shop averaged about a release per engineer per day.
Given that very exploratory context, I also really like people generally being present. If that's the default, you can iterate much more quickly.
I'm certainly not advocating not communicating or collaborating, and frequently. Just saying that the daily standup isn't always required.
Given that very exploratory context, I also really like people generally being present. If that's the default, you can iterate much more quickly.
Fair enough.
Trying to convey a lot of the things we encountered in text would have taken a lot more than 2 min/day, unless you were satisfied with rubbish and unilluminating two-liners. Sure, some days would go by with everyone saying 'going fine, nothing here', in which case we lost all of two to three minutes - around the same time as this magical email that apparently covers the more complex stuff.
Git log/Kanban board can tell you [1]/[2] if you actually need to know these things (hint: you probably don't unless you are manager/team lead/product owner).
Kanban blocker stickies can do [3] but I think a designated "safe haven" to get help is useful, at least for teams of varying skill level and comfort with one another.
My favorite standups have been the ones that "devolved" (in the formal capital-A Agile sense) to "Anyone blocked?" crickets "Okay. Good standup."
It'd be fun to try.
Maybe I'm getting old and cranky, but lately 7 is becoming my limit for people on a team, with team size as low as 3 looking pretty damned good.
The scheduled, mandatory standups interrupt everyone the same as any other meeting.
The whole problem with the OP's premise is that his root cause analysis is flawed. He sees that most meetings are inefficient, and therefore assumes inefficiency is caused by meetings. But meetings also provide other efficiencies. As long as the added efficiency outweighs the cost, meetings are a net win.
Synchronous is almost always more efficient when there is very close to zero processing time necessary between receipt of communication and response to it.
As you get away from zero processing time, the efficiency of synchronous communication drops very, very quickly.
Also, that's assuming 1-on-1 communication. Even when a synchronous exchange is between two parties is efficient, every unnecessary party whose work is blocked because they are a party to the meeting drops the overall efficiency considerably.
Which is why meetings tend, in practice, to be very inefficient if they aren't well planned: while synchronous communication can be efficient for certain communications and a properly chosen set of participants, meetings often involve lots of people unnecessarily bound up waiting for other people to complete synchronous exchanges, and often involve subject matter where asynchronous exchanges would have been more efficient even for 1-on-1 communication.
Depends on how you're working. I prefer a collective responsibility model. I know some people prefer to have their units of work spoon-fed to them, and are willing to trust some manager that everything will fit together in the end. But especially at startups, I think things go better when everybody feels responsible for the results.
I do agree that minimizing 1 and 2 is good, but I think you can get a lot of that just by holding the meeting around a physical Kanban board and letting people point at things.
Once you learn to "read the board" as a team, 1/2 can largely go away. And the best part is that the board is asynchronous - I can go look at it whenever I want without bothering anybody.
Yes, what the author offers here is asynchronous and most developers love that idea. However, in practice I've seen this method fail more often than it succeeds. Why?
Face-to-face synchronous communication matters. Problems are addressed quickly, brainstorms happen. Personal relationships develop; mentors and mentee relationships evolve. Perhaps another developer had your problem with some pesky JS library last week and gives you just the clue you needed, and so on. I actually think standup meetings are not only not the worst thing ever, but the best thing ever for a growing developer as they allow them to quickly see what others are doing, and quickly get feedback on their own work.
So here's our process for ensuring this:
Nothing.
It turns out that when you have skilled and motivated people working without process handcuffs, they are able, and actually eager to self-organize.
- How do we keep in touch? We set up a HipChat room where we discuss things both on and off topic asynchronously. Is our process "we will use a chat room for daily chitchat"? No. We use it because it makes sense, and when it stops making sense, we do something else instead.
- How do we catch one dev needing help? He says so. Then we can meet up and pair program or discuss the issue or whatever makes sense. Do we have "pair programming tuesdays" to enforce this? No. It just happens when it needs to.
- How do we make sure one dev doesn't drift off procastinating for two weeks? Turns out that's not really a relevant problem for us. We find that skilled devs given freedom and responsibility will live up to it. But on the off chance that it happened, we would notice the lack of work flowing from checkins and code review and work tasks.
- How do we make sure the project manager knows of any problems? We tell him. Simple as that. And usually on the way to luch, he asks "things going ok?" and we answer "yep" or "slightly behind it seems, we might delay task X till next week". Do we have a "pre lunch meetup" process to define this? No. It happens naturally because we all have a desire to cooperate.
- How do we make sure the devs don't shit in the sink while on the bathroom? We could have a process in place with a post-bowel-movement checkup rota. Or we could enforce pair toiletgoing with a senior architect. But we decided not to. It turns out the devs have a sense of hygiene, and therefore shit into the toilet bowl of their own accord.
What you're talking about is, at least in the Agile world, described with the shu-ha-ri model. People at the "shu" level really want rules so they know what to do. People at the "ha" level want rules for others. It's only at the "ri" level, that of mastery, that you can fluidly do what works without discussion.
Getting a team to self-organization is tricky. Sometimes rules help.
For example, I know one team that really loved their daily stand-up, but they had a problem with chronic lateness wasting a lot of time. So for a while they created a rule that lateness was punished by $1/minute into the beer jar. I once saw the CEO put $45 in. He was pretty pissed, but he was on time after that. Eventually, everybody got their shit together and they didn't need the rule anymore.
Absolutely true. I actually feel bad for not emphasizing that properly. Teams of self-organizing people aren't as common as it should be.
My point is that we should not add rules unless we really need to, and that people are more likely to self-organize if given freedom.
E.g. If we turned out to have actual persistent problems communicating to the project manager, we would introduce rules.
But, between the fact that a lot of these meetings devolve into something that is not short, fast or lightweight, and my observation over the years that daily is probably overly frequent for these meetings, I tend to mostly agree with the author of TFA.
Every team has it's unique needs, but for a lot of teams I'd go for a compromise with one, maybe two meatspace meetings per week (maybe Monday and Thursday) and then a technical solution using email or blogs or an enterprise social network or whatever, for a daily "standup".
It's not just "scrum" type meetings that could be replaced with a "no physical presence required" techie solution either... some companies have a culture of accountability (which is a good thing) taken to an extreme degree where half the company spends most of their time tied up in "status update" and "checkpoint" meetings. I've talked to people who say they can never schedule a real meeting (that is, a one off for attacking a specific problem) in their companies, because all of the participants are too over-committed with these status meetings! For these, I absolutely advocate finding a way to communicate most of thi status information electronically, and cut the frequency (and length) of the meatspace meetings back dramatically.
But what if people want to start their days at different times? Now they can't!
I feel this a lot right now. Due to unexpected personal circumstances I have wound up needing to go from "provide child support" to "provide financial support". So I just began a job search. But one past employer who would be otherwise reasonable to apply to went onto my list of places to avoid applying to for a while. Why? Because most of their teams have daily standups at around 9:30-10 AM, and there is still rush hour traffic around Los Angeles at that time. I'd like to spend the morning with my kids, get ready, arrive at 11 AM and totally miss rush hour. (Then leave late and miss it on the other end as well!) But they can't accommodate that.
If you have daily meetings, have you discouraged someone from working for you? Quite possibly so. But if my experience is a guide, you probably won't even hear about it.
A passdown included the experiments that ran on your reactor for the day, the experiments that were planned for the next day, and potential research directions based on the results. With a trail of passdowns, any engineer could easily pick up on the thread of logic from the previous engineer and continue working in their stead (if they are on their weekend, vacation, sick, etc.).
The nature of the job necessitated leaving behind a trail for someone else to follow, but I think it's a great process to be adapted to other work environments.
People ostensibly do work to get paid, but that's not really what motivates them to get anything done. Fear of losing face is one such motivation. The dollar is the currency of this century, but social currency is millions of years old and works much better.
And that is why these meetings must be face to face; email doesn't generate enough shame.
Standups get lots of bright minds in the same place at the same time.
Standups let you know what else is going on, which is indeed useful. I've never understood this thing about silos and belittling out-of-band communication. The only way to get the Big Picture is to hear what other people are working on, preferably in an unfiltered manner. Then again, a lot of developers seem to prefer their little heads-down silo, worrying that their little room is uncomfortably warm without knowing the house is on fire.