Slashdot Mirror
Ask Slashdot: Are Daily Stand-Up Meetings More Productive?
__roo writes "The Wall Street Journal reports that an increasing number of companies are replacing traditional meetings with daily stand-ups. The article points out that stand-up meetings date back to at least World War I, and that in some place, late employees 'sometimes must sing a song like "I'm a Little Teapot," do a lap around the office building or pay a small fine.' Do Slashdot readers feel that stand-up meetings are useful? Do they make a difference? Are they a gimmick?"
It's curious that they mention the military first doing stand-up meetings - when i was in the military, you stood up only when you were about to fall asleep, but that's all that needs to be said about that.
In the civilian world, if you have meetings every day, it's because your boss or some other important idiot is a bottleneck in the process and they need daily reinforcement of common sense, at the expense of department productivity.
Our daily 15 minute stand up meetings turned into daily 1 hour sit downs.....
Then we got a new manager. Meeting times went down to 2 per week, productivity went up... correlation? You tell me...
You go outside with your boss and have a smoke and tell him what's really going on..
Get up!
I'm late to a meeting, for whatever reason, and you are asking me to do what now? No. I don't think so.
But by all means, try it. Not only will it undermine your authority ( which can't be all that strong to begin with, if you have to rely on silly shit like this ), but it will create some seriously awkward moments ( which I have trained myself to be immune from, for just such a situation ).
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Email should suffice for the _majority_ of many many person meetings. (Sure, problem solving requires in person cooperation, but that's not what I would call a "meeting".)
We run an end of the day 5 minute run down meeting. It is a great way for managers to catch patterns, problems, and just generally keep a finger on the pulse of how things are running. The key is the 5 minute time limit.
It makes it easy to pass information up and down the chain and maintain the focus.
-Lifyre
I'll meet you at the intersection of "Should be" and "Reality"
That article reads like a list of every stupid idea a project manager has ever had. Here's an idea: keep the status meetings to once a week major changes in the project, keep individuals informed of changes that affect them as they happen, and let the workers do the work. When we're done, we'll update the feature/bug tracking system to indicate that we're done and move on. The tracking system will then notify the next person down the line (QA, build, PM, whoever) that something is ready for them, and if they have questions they can come talk to us directly, one on one. Go back to the agile manifesto, and screw off with all the buzzword-laden process crap.
They are a good way to break people who think they need daily meetings of the need. Doing it standing up prevents the kind of bloviating that the daily meeting types need, so that the only things you say are the things you need to say. It's basically the least wasteful way of doing a meeting where all you are really doing is exchanging status updates. For meeting where you actually need to work over issues and discuss things in depth, it's not appropriate.
When used properly.
If they are kept short, if folks give status, indicate plans and lay out blockers, without drilling down during the meeting (you can always schedule another meeting after standup, but standup is not the time for deep discussions).
In general, when used correctly, agile is just the fitting of good work habits and practices to the reality. No matter what the approach, an individual should have reachable short term daily goals, weekly goals, sprint level goals, etc. Forming the process around good work habits can indeed massively increase productivity.
With that said, no management/team approach will in and of itself fix a broken team.
Check your premises.
Seems to me that if folks have to use public shame as a whip, the team has more problems than simple standups will fix.
On the other hand, the pride of being able to come in every day and announce the accomplishments is a positive motivator.
Check your premises.
When I first brought daily 10-minute meetings to my programming team, they were skeptical. They hated meetings because they had been long and unproductive. But recently, after three years, I gave the team the option to reduce the number of meetings to, say, twice a week. Unanimously, they wanted to continue the daily meetings. Each of them said they got a lot out of them. They felt they knew what was going on, and many problems were caught before they grew.
The thing is, I respect my team members. I treat them like they are the professionals they are. In return, they give me everything they've got.
Daily meetings done right can be highly valuable. Done wrong, they can be torture.
I'm sure Scott Adams will greatly benefit from these fads. Just think about Wally participating in stand up meeting!
I've run development projects for about 15 years now. I've always considered development a creative process. And as such I've always avoided too much structure in developers time. I'm not going to say to anyone, "Every day at 9:30 we're going to spend 15 minutes talking about yellow post-it notes". There will be meetings. But overall I treat developers as professionals, I'm not monitoring their time. I'd rather have 35 hours of productive time then 50 hours on the clock of which 10 is spent avoiding work and another 10 not giving their all. And I'd rather they stay until is needed without needing to be asked when the time comes because they appreciate the freedom they get normally. Basically, I measure productivity and not timesheets. I have no problem approving a timesheet that is "short" on hours as long as I feel the production was there. Some people like working late and come in late. Some early and leave early. Some like to skip out after 37 hours a week, but if they're productive why do I care?
I might be lucky and through many stops have it always work for me. But overall a process development is simple. Get me good requirements. Do a good design. Develop with good practices and patterns. Test it. Deploy. More than that is a solution looking for a problem IMO.
I've had several developers come in early and stay late and not do as much work as someone that always sneaks out a little early. What's the big deal unless their pay levels are off? The stand up's just seem childish and are a fad. I hope!
Yes, except at my company I noticed a curious trend. Meeting invited employees have developed a spontaneous order of arriving to meetings in inverse order of seniority. The highest seniority employees often don't even arrive at work till a half to full hour after they declared the meeting to start.
Jesus effin christ... MEETINGS...
one big stroke off for the idiots running the place, to tell the
people that are really making them the money, that they aren't
making enough of it.
That, is why I'm out of the corporate bullshit circle jerk.
-AI
For me, it is far better to grasp the Universe as it really is than to persist in delusion
When people stick to the idea, previous days targets, any issues, todays targets, and move on. It fine, but when others start whining or manager wantabee start say "don't be so negative..." it turns to be a pain.
At another place I worked we had morning meeting (sit down) with all who were at work. Meeting was set a one hour max. Manger made any annoucements and floor open to issues and questions, very informal. Those ended up being good meetings very informative and some morning only 15 minutes long.
Wow, you've really synergized your paradigms for maximum best-of-breed stakeholder network impact, haven't you?
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Sadly, the word has lost it's original meeting because so-called consultants and trainers have turned "agile" into the buzzword du jour. It has been turned into a rigid set of must follow ceremonies, mostly coming from Scrum, which totally violate the original principles of the agile manifesto. If you feel daily meetings are useful do them. Personally, in my 30+ years of experience, the best way to ensure good communication (for after all that is a key agile principle) is to have the whole project team work in the same room and to use a good tracking system. As the manager/leader I half listen to the conversations going around the room and intervene when I think my input is useful or necessary or make sure people who arent in the conversation who need to be, join in. The tracking system keeps everyone focused and informed on what's important. That, along with the whip hand of a good QA manager who ensures things don't fall between the cracks. Formal meetings are important at iteration kickoffs and to discuss complex issues with customers. A strong leader will ensure meetings are short and to the point whether they take place standing or sitting.
Depends on what you're smoking.
I have done standups both as a teamlead and as a developer and in both cases they suck. I like to think of myself as a pretty good teamlead but I work by adjusting my monitoring to the skills of the individual develop and their current task. Some people work great if you just let them be and others need to be "unstuck" if they are working on something complex or be kept on track as they tend to wander off. One size of leadership definitely does not suit all.
So, as a team lead I KNOW already what the fuck everyone else is doing and during standups, especially in this companies that like to share and get everyone from cross-projects to come join the circle I find myself listening to stuff I already know or don't give a rats ass about.
As a developer, this is even worse, I know what I did, I know what I am going to do, I know what my issues are... why do I need to know this for a dozen or more other people as well? And if I get an issue, I deal with it then and there not wait for a standup where I can only speak for a short time and not have any papers or screenshots handy. Do people ever get an issue resolved from a standup they didn't already address before it? Then get you to a class on communication ASAP.
But what if you got some problem that someone else might know a solution too... THIS NEVER HAPPENS. In some dweebs fantasy land this daily standups should result in brainstorms where one guys problem is solved by someone else by magic... the rules of the standup (short) prohibit anyone detailing a problem they are having and inviting others to think about a better way to solve it... and basic nature of the adult male does the rest. Have you EVER said during a meeting or standup "gosh, I have this project and it asks me to do X and I wondered if any of you could think with me on this"? Yes, you did? Then hand over you man card right now, you balls will be collected later.
Standups only have room for blocks, not requests for brainstorms. Brainstorms should be done while comfortable and with plenty of data available and a place to write things down (another fucking idiotic thing about standing up, how are you supposed to make good readable notes, oh wait most never bother with that, so everything is forgotten and you got to mention it again after the standup).
Management often feels the need to be kept informed the problem is that they want all the information without all the information. Either a meeting only contains abstract monkey babble that confuses developers, or it becomes techno babble that confuses anyone who ever had a date. Often "when will it be finished" really means "I want it finished yesterday and don't bother me about the laws of causality".
Ideally, a good team lead can solve all this. In Dutch the term is "meewerkend voorman" basically the person on a shopfloor who both works and manages it. It is most common in blue collar type jobs but that is just because white collar jobs tend to require anyone doing management to loose any other usable set of skills.
He doesn't have to be the best coder, and with this I mean that he can code fairly well but he is not a die hard code monkey like a John Carmack from Id, but he knows the job and has done it himself. He does know about management but is not a manager rather he is a coder who then became a developer (a coder writes code, a developer creates an application) and has then learned how to do the development part of coding for other people. The talking to management, the assignment of priorities, the overview of the entire project, the dangers of regression, why security is an issue, etc etc. He then sits as a barrier and a filter between management (the customer) and his team.
Think of it as building a brick house. A foreman doesn't need to be the best brick layer ever and a brick layer he is managing might well be far better then him but if he can lay a good wall himself then he is all the better at supervising this. Because he knows about the job at hand, he can alter the amount of supervising depending
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
A few years ago, my team decided that everyone should pay a small fine of $5 into a jar whenever they failed to arrive by 9 AM. As soon as this was decided, I picked up the jar and contributed $50 for 10 days worth of sleeping in as much as I wanted. The only flaw in my plan was stuffing the cash in the jar in front of everyone, because on seeing that the new policy was immediately cancelled by management.
http://www.dilbert.com/fast/2008-04-15/
Having an "end of day" meeting is only good for making sure no one is leaving early.
If you're waiting until the END OF THE WORK DAY to communicate a problem ... what the fuck were you doing the rest of the day? Why didn't you communicate it before then?
No. Rather it is an attempt at a safety net for those managers. They should already know where the problems are. They should spot the patterns during their daily non-meeting interactions with everyone.
Good managers understand the patterns and problems and can take pro-active measures to deal with them. That way you can keep doing your work.
Taking time away from your work (and everyone else's), on a recurring basis, to directly inform management of problems is just inefficient.
I have a CS degree. If you had asked me how find the shortest path across a graph with positive edge values, I could have given you that algorithm. I even did an implementation in code.
But I didn't remember it being called "Dijkstra's", though I must have heard the term used. I've always had a rough time remembering names, and isn't the algorithm way more important than the name given it?
Furthermore why WOULD a scrum master necessarily be a CS name-dropper like yourself? I'll bet he could ask some question about SCRUM that would have you shitting your own pants.
I hope (for the sake of your team) you were fired and that your ego someday cools down to somewhere below supernova level. I can't imagine working with that level of prickery, I'll bet at that company you didn't even do anything involving graphs in code...
You strike me just like the Design Pattern guys that can recite chapter and verse every single pattern from Gamma-Helm but produce a mess of nonsense code in real life that is utterly un-maintainble because you have glued together every possible pattern (and probably a graph or two for a problem that required none!) into spaghetti code.
All of those things are great ways to learn lots of techniques for solving problems but the important thing isn't knowing any one algorithm, it's knowing how to put together software that WORKS. I don't even like Scrum exactly but I admire what them and the Agile guys are trying to accomplish in producing higher quality software faster, and you should have way more respect for the attempt than you do.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I noticed the same thing, especially being the developer with the second most seniority. The most senior developer never showed up, and I showed up about once a month. The meetings were worthless and a waste of time, which those of us who worked on the accounts with the most impact realized. I could spend 15 minutes talking about stupid crap, or fixing important crap that executives had visibility into. Which one made my job less painful?
24 beers in a case, 24 hours in a day. Coincidence? I think not!
The British Queen has daily meetings where she's the only one sitting. It's not for any formal reason but rather to make the meeting as short and to the point as possible. From what former PM's say, it works really well.
Bad meetings are a symptom of poor leadership. Meetings are a tool. As you can use a screwdriver to screw, so can you use it to stab people. Meetings are exactly the same. They can be used effectively, to improve productivity. They can be used ineffectively, and waste productivity. They can be used maliciously, to make people miserable. If you want your organization to succeed to the greatest degree possible, you want to have the maximum number of productivity enhancing meetings you can, and not one more (which practically speaking means you probably aim to come in low rather than high).
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
In a work environment that has email, web and other stuff, daily meetings were becoming a drag, so now we only meet when there is actually something to discuss.
There was an unknown error in the submission.
Britain's highest-level meeting, the 'Privy Council', has for centuries been stand-up only. All HM Queen ever says there is "assent", and that certainly keeps it quick too.
If you want to ensure meetings are fast and don't run overly long, just schedule them for 4:30. Everyone will STFU because they want to go home.
I do not fail; I succeed at finding out what does not work.
Stand-up meetings make big, tall people look big, and short, small people( women included) look small. In sit-down meetings everyone is the same size, more or less. You can say sit-down meetings were the great equalizer in corporate America. Stand-up meetings bring us back to a jungle dynamic.
How time flies.
Stand up meetings are terrible, they always felt to me like a bad version of an homage paid either towards communism or fascism. The feeling is akin to that of a komsomol meeting, and that's probably what hitlerjugend must have felt like, especially those, who weren't devoted followers, but those who only attended it out of sense of self-preservation.
Maybe this comparison is a bit too strong, but that's the first thing that comes to mind.
As to the merits of such meetings - these are always denigrating, and totally worthless, nothing of any value can really be discussed in them because they are not aimed at solving any particular problem, just a reminder that the ant-farm is still in operation for some ridiculous reason.
You can't handle the truth.
That explains it all. Agile development is never the solution, and always the problem. It is sad that so many people think that you can play code Jenga, and ship it when it is "good enough", which will be on Friday, BTW. If I could change one thing about the industry it is that so few people understand this simple reality of code development. The answer to the question "When will it be done?" is: When it works properly, passes all tests and a thorough code review for security and maintainability, and is checked in to a well managed software repository for final SQA, and not a moment before., and the answer to the question "how long is that going to take?" is: nobody knows; it's a mystery".
This is why the Linux kernel is such a solid project even with thousands of disparate developers and being cross platform on an almost ridiculous number of architectures. Not understanding this is why so much code is bloated garbage that should never be considered acceptable.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I've been pushing my department of developers from using the corporate approved modified waterfall method, which has lead to massive budget overruns since corporate pushed it down on us, to an Agile-like process (You do know you are allowed to modify Agile to your environment?). The last two projects we did that way came in under budget and only slipped the original schedule due to client-introduced requirement changes.
One of the things we did was the 2-minute stand-up meeting (there were only 3 people for that project). Kept it focused to: What I did yesterday, what I will do today and what problems I'm having. When we had the weekly meetings, we usually found out about roadblocks a week after they happened. Now, the project manager found out things within 24 hours and could fix them quickly. "Yeah, the users aren't available for testing so they're going to put it off--" "I'll talk to [their manager] and get it fixed."
So when I read all these skeptics and haters, I'm shocked. For those of us who used stand-up meetings, they are so much better than the old sit-down 1-hour meetings. Then I dug into the criticism and I think I know what's the problem: cargo cult management. That's where clueless managers follow the form without understanding the motivation or why it works. So the punishments, like singing and running a lap, makes my skin crawl. The agile manifesto explicitly says People over Process. Just a simple "You're late!" is sufficient. I've read other Agile horror stories on Slashdot over the last two years, and it seems like those shops followed the motions without understanding the why. One guy complained that he saw a bug but wasn't allowed to fix it because of some bullcrap like "You don't have the token to work on that". WTF? That's not Agile! If something's broken, anyone is allowed to jump in and fix it. But that shop seemed more interested in following the liturgy than actually being Agile. Remember the first rule of Agile:
The Agile horror stories I'm hearing are teams choosing processes and tools over people.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Fair enough assessment given the information I provided. I should probably add that the meeting was structured poorly and despite our best efforts, nobody contributed anything of value so attendance in general dropped off. We are looking at other ways to incorporate the agile stand-up meetings into our workspace, but in a different format that will provide value.
We also have weekly training meetings where historically we would talk about the application frameworks for our company's product, because some of them are extremely complex and difficult to understand (e.g. hardware and payment system integration). Lately, we have been turning these into sessions where we take a problem someone has been working on and spend a whole hour going through it. A group problem-solving session. These have been extremely productive both in terms of getting stuff done as well as hands-on training with complex, real-world scenarios.
That may not address the specific point you brought up regarding stand-up meetings, but it does accomplish much of the same thing for our organization just on a longer time scale.
24 beers in a case, 24 hours in a day. Coincidence? I think not!