Daily Meetings Are Great but You Should Never Have Them(wellbredgrapefruit.com)
wellbredgrapefruit.com
Daily Meetings Are Great but You Should Never Have Them
http://wellbredgrapefruit.com/blog/2013/05/28/daily-meetings-are-great-but-you-should-never-have-them/
45 comments
I think there's a No True Scotsman effect at work here: "meeting" is the general abstract superclass used to refer to "people talking at a table." However, "meeting" has some very useful subclasses--for example, debate and negotiation. Real things get done in debates and negotiations. But people don't think of those at "meetings", per se, so "meeting" gets stuck with all the negative connotations and none of the positive ones. (In est, a useful meeting is not a True Meeting; it's something else.)
Ok, I'll take the bait.
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 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
Unfortunately these daily meetings hardly ever work out that way -
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...
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...
You make an excellent point. Meetings are basically "team work breaks", where everyone gets to stop working but must remain together. Usually, team members discuss work, as that's always something these people have in common.
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).
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).
Well, a lot of places that are "doing Agile" (whatever that means) are really just doing waterfall with some different rituals and labels. E.g., the 30-minute standing status meeting, which has nothing in common with the Extreme Programming stand-up meeting except that people are standing. (Sometimes. I've seen places where they do the daily "stand-up" sitting down.)
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.
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.
That just means you're not doing a good job running the meeting. If it's not working for you, change the things that aren't working so they are.
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.
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.
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 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".
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".
Context switching from what? If you're standup is first thing when you get into the office, your context switch is from a cup of coffee.
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.
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.
Context switching from what?
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
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
This article is like magic! By which I mean the exciting part is all misdirection.
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.
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.
Well said. In my experience, standups were short and covered a lot of ground. Problems were rapidly back-and-forthed. If you didn't have a standup, people would get annoyed because they needed to jaw with the group on something. It was a small, diverse team (one hardware guy, one firmware, two web, two support, a smattering of others) and that may have contributed to the need to cover ground quickly, but the idea that the daily meeting is by default a waste of time is laughable.
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.
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.
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
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 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.
Sure, and I am saying it takes a lot more work to write that up well than to have a conversation.
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 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.
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 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.
Yeah, I could imagine contexts where not much is going on, or where the work is pretty routine, or where collaboration is low. In which case, no need to talk frequently.
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 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.
People can talking without having a daily, scheduled, standup meeting! If the only time people are talking is during the standup, I would consider that an anti-pattern. :-)
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.
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.
Of the Three Pillars of Standup (what you did yesterday[1], what you are doing today[2], what are you stuck on[3]) I really only find [3] to be of much value.
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."
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."
You know, you have an excellent point. If you wanted to tweak standups, how about just doing #3? Everybody say where you're blocked and how we can help. Boom. Standup over.
It'd be fun to try.
It'd be fun to try.
Yep - a team near my desk routinely has sub-30 second standups following that format. I am probably a bit sour on standups in general since my last project had 10+ person, 15+ minute meetings (sometimes with the client present...) that added very little value for their cost ($1XX x 0.25 x 12).
Team size kills so many things. I had a client once that couldn't start a project without at least 15 people. Those projects were doomed from the start.
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.
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.
If you're blocked, why don't you just contact the scrum master directly when you are. Why do you have to get everyone together to mention it.
Because you have a widely experienced team and you don't know who might have the answer.
Even with that, a email would suffice.
The scheduled, mandatory standups interrupt everyone the same as any other meeting.
The scheduled, mandatory standups interrupt everyone the same as any other meeting.
Email interrupts too, and probably worse because it happens ALL THE DAMNED TIME. Slicker systems like Campfire can be better, but you're still dealing with asynchronous versus synchronous communication. Synchronous is almost always more efficient.
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.
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.
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.
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.
Interesting, how is synchronous communication ever more efficient than asynchronous communication? It might be more efficient for the person asking, but rarely for the people being asked.
> hint: you probably don't unless you are manager/team lead/product owner
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.
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.
Sure - definitely agree with you on seeing all the pieces fit together. I get a way better picture of that with other methods (Kanban, story map) than from someone listing which classes they wrote yesterday.
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.
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.
If people are actually listing classes in the stand-up, I agree that's a problem. For me the stand-up "did yesterday" content is more, "We worked on X and have it almost finished. In the course of that, we made a neat utility for X, and cleaned up some ugly code in Y. If anybody wants to talk about refactoring Y further, let's talk."
2) can be useful for when you say you're about to do something and someone else in the team has added a helper or done something similar in that area.
This has it's own set of problems, namely, it is more difficult to do this over email than it is to just talk face-to-face; that is, it is slower.
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.
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.
We have these kind of daily meetings and I would never replace them with an email thread. Answering the three questions in writing would not only be more burdensome but you would also lose out on the valuable instant feedback.
What I dislike about this is how preoccupied people are with how the rules of daily meetings should be enforced. As if it is a given that a) there must be daily meetings, and b) they must be defined as rules. I would rather we focused on the goal instead: The dev team must be coordinated, and they must not deviate enormously from the schedule without the project manager at least knowing about it.
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.
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.
Well, as long as there are observable regularities in your work, you have a process, just not a formal process. As long as there is a way for people to do things and get called out or admonished for it, you have norms, just not explicit rules.
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.
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.
> Getting a team to self-organization is tricky. Sometimes rules help.
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.
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.
I'm sort of onboard with this and sort of not. I certainly believe that actual face-to-face communication has a place, and that it should occur with some regular frequency. I also believe in short, fast, lightweight meetings ala what a daily Scrum meeting should be.
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, 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.
There are other costs to daily meetings - namely when should you have them? If you have them in the middle of the day, you interrupt the schedule. At the end of the day, then the energy you're looking to develop in the meeting goes the wrong direction (plus it inevitably interrupts someone who was in flow and just wanted to keep working). Therefore you want it at the beginning of the day.
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.
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.
From the title I was expecting to disagree, but this isn't about "not having" the meetings, it's about taking them offline. I think I agree with this. I should have done this at my previous job. The devs had flexible schedules (which I support), and trying to have a fixed schedule for daily stand-ups was unworkable and I eventually gave up. This would have worked much better.
I used to work as a process engineer at a semiconductor manufacturing plant. The plant ran 24/7, so we had (almost) round-the-clock engineering coverage. "Stand-up" meetings weren't viable because many of the engineers on the same team would work at different hours, so at the end of the day each engineer was required to send a "passdown" via e-mail.
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.
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.
Daily meetings are not really for obtaining useful status information. They're about habituating people into doing real work every day, so that they don't feel like jackasses when they have to report to their peers that they didn't do anything yesterday.
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.
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.
Meetings are synchronous, email is asynchronous. The feedback loop is tighter.
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.
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.
My team uses IFTTT for daily standup emails, and it's really been a huge help for us. Here's the recipe if anyone else wants to use it: https://ifttt.com/recipes/86294
I swear I see a variant of this article every week, and the discussion is always the same. TL;DR make sure your standup meetings are incredibly fast.
I've yet to participate in a useful meeting.
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.