Ask Slashdot: Are Daily Stand-Up Meetings More Productive? 445
__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?"
Curious (Score:5, Funny)
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.
Re:Curious (Score:5, Insightful)
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.
Alternatively, it's a great way for a manager to enforce office hours on their should-be-flexible-schedule programmers if they set it early in the morning, but then that just bottles down again to "a manager who insists on micromanaging everything, and being a bottleneck".
Re: (Score:2)
Re:Curious (Score:5, Interesting)
This is what I came to say. We had standup meetings every day and it devolved into one particularly megalomaniacal aspie micro-manager telling staff how to stand in the most abusive tone possible. I quit shortly after that started.
Re:Curious (Score:5, Insightful)
It's fundamentally impossible for any process to defeat a bad employee with the authority to subvert it. This is why hiring is the single most important meta-function that occurs in any organization, and if you don't put a LOT of energy into it you are screwed.
Re:Curious (Score:5, Insightful)
I think a better way to go would be to stop inviting everyone from the top down to meetings that could be better served via email, or even IM. I find a don't pay attention to meetings that have little to no affect on my daily work yet they continue to invite me regardless, 'just in case' or because it's a major announcement for some VP who is changing departments, or some tweak to benefits, etc. I also get invited to technical meetings for various topics on projects I am only peripherally working on yet I'm on the invite list for every meeting regardless. They would be better served inviting key folks and let the disperse the info as needed rather than inviting people who's time is better spent getting work done.
As to the 'gimmick', yes it might wake people up, but it will also make them irritable, rebellious, and take them out of the proper productive frame of mind that often generates good ideas.
Comment removed (Score:5, Informative)
Re:Curious (Score:4, Insightful)
We called them "Power Meettings". The time you do it depends on the goal of your meeting. Do you want to inform how you did? End of the week. What you want to do? Begin of the week. And no, no 9:00 meetings.
Unless they officially contain coffee and breakfast.
Re:Curious (Score:5, Interesting)
I think this depends much on the dysfunction of the organisation as a whole.
Regular daily stand-ups are great for dysfunctional organisations, not exclusively but particularly, as much signal can be added to noise. "Dave has X issue yesterday, this is how he fixed it." "We're expecting high volumes over the coming week." "There's a new UAT manager in Y." Absolutely fantastic for these things, but very short and sweet. It ensures everyone hears the osmosis at a high level, and allows the team coordinator to share their daily dashboard highlight view, all to enrich each of their views.
Not in a meeting room, not sitting down, just standing up for 5 minutes face-to-face. That level of information sharing, especially in dysfunctional organisations where an individual's inbox may receive 900+ emails per day, which I have seen and been horrified at, is essential.
Absolutely not saying they're only useful for dysfunctional organisations, but are a necessary daily for dysfunctional organisations.
How to do them well? Empower all; do not dictate; keep to 'team' size which should be 5-10 people, any teams larger than this probably have difficult structural issues, a team larger than 10 cannot empower a stand-up as it will unless with great skill degenerate to a grand town meeting.
Re: (Score:3)
Re:Curious (Score:5, Interesting)
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.
From the article:
The current wave of stand-up meeting is being fueled by the growing use of "Agile," an approach to software development, crystallized in a manifesto published by 17 software professionals in 2001.
Which is true.
Don't be so quick to blame management. I know it's a reflex here on /., but the current craze for stand-up meetings, scrum, agile, etc., are being driven by tech staff.
Re: (Score:2)
Are they being driven by tech staff within the companies affected, or some know-it-all tech staff somewhere else, like the 17 jerks who wrote that manifesto, and now these companies' managers are reading this manifesto and trying to apply it to their own organizations?
Re:Curious (Score:5, Interesting)
but the current craze for stand-up meetings, scrum, agile, etc., are being driven by tech staff.
That's daft and primitive though. The real tech way of having more productive meetings is: require most meetings to be done via text instant-messaging (IM):
That way:
1) you automatically get minutes of the meeting (the bosses could require the transcripts to be posted somewhere).
2) you can be in multiple meetings at the same time, potentially even chairing one meeting while attending a few others. Heck the bosses could attend them all, not to chime in like an idiot, but in case his/her official approval/opinion for something is required (reduce latency!).
3) you can do work and other stuff (slashdot, youtube)[1] while attending the meetings.
4) You can set "AFK", go to the toilet, come back, and scroll up to see what happened while you went AFK, without requiring everyone to recap or wait for you.
Now of course programmers generally are better off with an uninterrupted stretch for heavy-duty coding. So what bosses could do is require most/all meetings to be within a certain time range of the day. With IM meetings, it is not a showstopper if you have a few meetings scheduled for the same time.
This way bosses can squeeze even more out of employees ;).
Of course this requires employees who can actually read and type at reasonable speeds, and multitask.
With normal physical presence meetings (stand-up or not), you could have 5 people mostly idle, with the only the chairperson reasonably busy, for the entire meeting time. Not very efficient.
IM meetings could take a bit longer - many people don't type as fast as they can speak and do a normal presentation, but I don't think that's a show-stopper.
FWIW, are stand-up meetings really more productive and effective than other sort of physical meetings? Or are they merely shorter, leaving more time to get the work done... You can actually have productive meetings - you must have a good reason for meetings, agenda, etc etc (plenty of stuff written on that already).
[1] This gets harder once there are too many meetings in parallel that require your concentration, but hey you want productive right?
Re: (Score:3)
That is ultimately how my team does it. We use chat (originally IRC, but recently XMPP chat on a company server). There is no requirement that anyone be in at a particular time, and we have logs that keep track of what was discussed automatically. It takes all of about 1-2 minutes of anyone's time each day at most.
Contrast that sharply to another team in the building that's 3-4 times our size and insists upon having actual meetings. It is not uncommon to see them spend over an hour and a half discussing
Re:Curious (Score:4, Insightful)
But you could do the same thing for sit down meetings too. If the chairperson is focused and has the authority, the meeting can be effective and short, whether it is stand up or sit down.
People have written plenty of stuff about holding effective meetings, and reasons to hold meetings. Some even suggest writing down the rough cost of the meeting on the whiteboard as the first thing, to help get people focused ;).
As for:
* I did this yesterday
* I'm doing this today
* Here are my impediments (if any).
If you try and fix problems (impediments) in the stand-up - you're doing it wrong.
If that's all you're doing then it seems a waste of time. That's the sort of thing that would be better off done by getting people to email updates or do something similar. Why you are forcing this to be serialized, when it can be done in parallel? Then that person who rambles on, can ramble on in an email and not waste everybody's time. And the project manager can tell that person privately to not ramble so much, without her losing face in front of team members, OR let her ramble, if she appears to be able to still get her stuff done anyway, the extra information might come in handy (assuming project manager can read fast).
Even if there's no rambling, if there are 15 people in a team, you're forcing 15 people to stand around for a minimum of 7 minutes (not including synchronization (waiting for everyone to arrive), initialization and clean-up time - which can be significant). Just to hear each other talk for 30 seconds, one after another. What's the point?
I can understand holding physical meetings where the boss can look everyone in the eye, do the "General motivating the troops" or "General announcing major defeat" speech. And also 1 to 1 meetings where a manager meets with a team member to try to fix/workaround any potential problems before they blow up. If you're physically in front of the person, it is easier to gauge the emotional state and know that a rant is about to begin, so that you can shut up and let the person let it all out, and just nod acknowledgement or stuff like that. Rather than type *nods* every now and then ;).
But it seems a waste of time to hold a meeting just to share status updates.
Re: (Score:3)
A sit-down meeting requires everyone to stand up, go to meeting room, sit down, wait for stragglers to arrive. It is a core advantage of the stand-up meeting that the last three of those steps are removed, and if they aren't, your stand-up isn't being done right.
Re: (Score:3)
Ahhh this explains so much. A previous boss had spent his entire career in sales and was now in charge of the IT department. Nobody could figure out why he started the day with an hour long inspirational speech, and often a second one after lunch. As far as I can guess, after being raised in that sort of sales environment, I can understand why he might think that would be effective with a different part of the company.
Fragile development (Score:4, Insightful)
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 [slashdot.org], 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 [wikipedia.org]. Not understanding this is why so much code is bloated garbage that should never be considered acceptable.
Re:Fragile development (Score:4, Informative)
Meanwhile, in the real.world companies are deriving great value from less perfect code and cant accord to.commit their businesses to open ended and unbudgeted developmenta that may never end.
If you cant tell me when I start getting return on my investment in your software then I don't invest in it.
Re:Curious (Score:4, Insightful)
Seriously, what does this have to do with anything?
I've read and reread it several times and it makes absolutely no sense. How are being a scrum master and knowing Dijkstra's algorithm connected in any way?
Re:Curious (Score:5, Insightful)
Well I did a computer engineering degree and I don't know Dijkstra's algorithm inside out. Of course, we spent our time actually learning and solving problems, not memorizing algorithms.
Re:Curious (Score:5, Insightful)
You do realise that scrum teams are cross-functional, right? As in, your backend developers, UI developers, DBAs and testers are all part of the Scrum team, and any one of them can be the ScrumMaster? And the entire role of the ScrumMaster is to facilitate the team with the Scrum/Agile process, and to help clear any road blocks in place?
That, and the fact that your snobbish arbitrary litmus test is complete bullshit, and would only ever be performed by a basement coder desperate to prove his worth with meaningless, idiotic technical buzzwords. It's the kind of test a startup company asks in a job interview, in order to really ensure that no developer worth his salt would want to work there.
Re:Curious (Score:4, Insightful)
Nonsense. If you were spending a lot of time on an algorithm that can be learned in 10 minutes on wikipedia then your education was progressing at an interminably slow rate.
Re:Curious (Score:5, Insightful)
Sorry, but no.
Dijkstra's algorithm is an important notion in computer science, but it's not used on a day-to-day basis in day-to-day programming tasks in the software industry. Using that as a dick-measuring stick is inaccurate because it emphasizes stuff-college-students-were-told-was-important versus real-world-software-development knowledge. If you asked me who I'd rather have as a "Scrum Leader," I'd choose someone with solid, real world software development leadership any day over someone who could recite Dijkstr's algorithm off the top of their head.
I think that the fact that you used a phrase like "scrum master" says a lot about the type of software developer you are.
Re:Curious (Score:5, Insightful)
Re: (Score:3)
Re: (Score:3)
So, what you seem to be saying is that, at the drop of a hat, you expect someone to be able to approach a problem area they may never have dealt with an duplicate the solution of a Turing award winner who also happens to be one of the most influential computer scientists to have lived? Seems reasonable.
For college taught engineers, this test makes some sense because they probably were taught it in college. For se
Re:Curious (Score:5, Insightful)
Dijkstra's algorithm is a good litmus test of somebody's programming and software development knowledge and experience.
BZZZT. Wrong. It is a litmus test to see how recent of a graduate you are of a computer science course and whether your training focused on memorizing search algorithms or honing your problems solving skills.
Anyone with any formal computer science, computer engineering, or software engineering education will know it inside out. Even many people who studied mathematics or physics will be familiar with it. It's a relatively simple algorithm that's easy to explain quickly, but it also touches on a variety of important concepts, and is quite applicable in the so-called "Real World".
Sorry, but computer science does not alway prepare you to be a proficient software developer as the course material can vary considerably from institution to institution.
Many software development professionals see it as a not-so-secret secret handshake, so to speak. If you know what you're doing, you'll find explaining it trivial. If you don't know what you're doing, you won't be able to. It's a fast way to separate those who can do from those who just talk the talk.
Sorry but you don't seem to have a clue about how modern software development functions and how it differs from pure computer science.
To be a scrum master, you should have at least this minimum level of knowledge of the field. That's where the connection comes in. Seeing if somebody knows Dijkstra's algorithm is one of the most basic and effective ways of seeing if somebody is qualified to be involved with software development.
Sorry but you do not understand what the function of the scrum master is. The main function of the scrum master is management of the team's velocity in an iteration. The contents of an iteration is determined by a combination of end user priority, estimation points on the stories which were candidates for consideration and the estimated potential velocity/throughput of the team involved. In essence, a scrum master is an imbedded team lead/manager/product architect.
Knowledge of how to implement a search algorithm is pretty much useless in most real world applications in businesses especially when most people would just leverage what is already present in a framework like .NET's linq or use the power of a RDMS to sift through data. There is often no need to "reinvent" the wheel and even if there was such a need, chances are, someone on the team would have already written a generic common library function for the most efficient search algorithm if you happen to be using a framework poor language such as C/C++.
Re:Curious (Score:5, Interesting)
This is exactly the point I wanted to make. I've been doing professional software dev for over 20 years and if an interviewer asked me to explain an algorithm off of the top of my head I would immediately know that this is not someone I would ever want to work for – primarily because it tells me they're clueless and quite likely in way the hell over their head. Frequently, software development isn't about what you know... it's about what you don't know and how quickly you can learn it. Yes, there are some core things that help along the way, but being able to regurgitate a bunch of facts only tells me that you'd do well on the MCSE exam. How well you could deal with unknowns (i.e., whether you can do problem solving or not) is unrelated to amount of trivia you can spout.
As to standing meetings... been there, done that; circa 1998 or so (IIRC). Yet another attempt to avoid the correct solution to "the meeting problem". The correct solution is to stop having regularly scheduled meetings. You can easily schedule meetings as the need arises. I would also be for voting by the invitees as to whether the meeting is necessary or not.
Re: (Score:3)
The correct solution is to stop having regularly scheduled meetings.
No, you are wrong.
What is important is to stop spending time on meetings without concrete results.
When you participate in a meeting where no decision has been done and where not everybody was necessary, it was just a waste of time.
I'm a retrospectives facilitator, and I can assure you that holding regular retrospectives helps the teams evolve incredibly.
The goal of a retrospective is to discover what were the lessons to learn.
If you don't use this kind of regular meeting, nobody progresses in your teams, be
Re: (Score:3)
cripes...
s/in favor/be in favor/
I hear some of the newer websites have invented this thing called "editing". Probably just a fad. And potentially IP encumbered. Must... stay... away.
Re:Curious (Score:5, Funny)
I guess the egoless programmer part of Agile methodologies wasn't for you then.
Comment removed (Score:5, Funny)
Re: (Score:3)
What's curious is that despite being developing software for 12 years and scrummaster for 6 this is the first time I ever hear about this Dijkstra's algorithm.
What a prick (Score:5, Insightful)
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.
Re: (Score:3)
. None of those scale. As complexity increases each of those techniques reaches a point where they fail, badly.
traditional Dijkstra implementation : O(edgesCount+vertexesCount*ln(vertexesCount)) how does that does not scale ?
I assumed that you meant elements count when you wrote complexity, if not please specify what kind of complexity are you talking about. You might have might accidental complexities, but those are slowly being taken away by our tooling's.
You might have meant business domain complexity but if you meant that, it is related, as if you can translate a problem into a path finding problem in a weighted graph, you then have a solution with a relatively low O bound.
So please specify what did you meant by complexity ?
Well, it is somewhat useful if you are trying to find the shortest route on a map or network topology but that is a pretty niche requirement and chances are that someone has already solved those problems a million times already. In the "real world", most developers don't have the time or desire to resolve problems that already have cheap solutions.
Re: (Score:3)
you missed the problem translation part, that part of a true CS education, enables the utilization of one well tested solution to a seemly unrelated problem. Math rule's, I recently used a part of Dijkstra algorithm to optimize the generation of oversized PDF, I went from 6Gb of ram to 700Mb to merge 8Gb of pdf down to a 55mb file and the performance went from 4 hours to a big 55 seconds on the same hardware....
You might ask what the link between Dijstra and a pdf file...
Well a pdf file is a serialized obj
Re:Curious (Score:5, Interesting)
The daily meeting has other advantages.
1. It puts everyone in the same room at the same time and they know what is going on daily. This can stop duplication of effort as sometimes you get multiple requirements across many people but the work is actually nearly the same.
2. It helps focus on what your tasks are for the day. Let's face it, there are days that you slack off on not because you don't have enough work but because your daily goal wasn't there. A quick meeting where you need to state your goal keeps you honest and helps you know your goal is for the day.
3. It is informal and no notes, nothing gets fixed in stone, allows for more of an honest assessment.
4. Team lead is informed on what is going on, and when pressed by management he has the answer.
5. Simple problems can get solved easier. After the meeting people's schedules can disconnect and it could take days to answer a simple question.
6. It keeps your team together.
Re: (Score:2, Funny)
The daily meeting has other advantages:
1. It puts everyone in the same room at the same time and they know what is going on daily. This can stop duplication of effort as sometimes you get multiple requirements across many people but the work is actually nearly the same.
Do you all even talk to each other? Like, getting up and vocalizing rather than fucking off on Facebook all day?
2. It helps focus on what your tasks are for the day. Let's face it, there are days that you slack off on not because you don't have enough work but because your daily goal wasn't there. A quick meeting where you need to state your goal keeps you honest and helps you know your goal is for the day.
You should probably hire less microcephalics and other unmotivated, underpaid interns to do the actual work.
3. It is informal and no notes, nothing gets fixed in stone, allows for more of an honest assessment.
None of you have the balls to say that daily meetings are redundant and stupid, so you're all lazy, underpaid, or dumb.
4. Team lead is informed on what is going on, and when pressed by management he has the answer.
Why does the lead have to be pressed to know the answer? Once again, your company is full of idiots.
5. Simple problems can get solved easier. After the meeting people's schedules can disconnect and it could take days to answer a simple question.
Schedules can disconnect? Anybody who can't walk to another cube and "co
Re: (Score:3)
You have certainly been forced through too many meetings; with being an antisocial and stuff, no wonder you're so aggressive.
That and you haven't even considered virtual teams or global teams; you know, like teams which consist of 5+ people spread around the globe.
I have team mates in IN, US, IE, RO and IT. In order for us to actually be in sync, meetings are required. Of course, I would love to never participate to meetings and rot in my own cubicle while slacking, but I've seen where that takes.
We used to
Re:Curious (Score:4, Funny)
Not even close to the same thing.
Well, not unless every person in your morning company formation sequentially breaks ranks, runs to the front, does an about face and gives a personal status:
"Company! Yesterday, I did a lot of pushups! Then I low-crawled! Then I cleaned my weapon and did some more pushups! Today, I'm going to walk a lot! My impediments are the group of people across the wire trying to kill me! Hoooahh!!"
Re: (Score:3)
Re:Curious (Score:5, Interesting)
"Company! Yesterday, I did a lot of pushups! Then I low-crawled! Then I cleaned my weapon and did some more pushups! Today, I'm going to walk a lot! My impediments are the group of people across the wire trying to kill me! Hoooahh!!"
Not everyone's 11B, you know.
When I was a medic, we had a simple, informal process for shift change and report. "Here's what happened on the night shift, here's what's going on with the patients we have in here right now, hope you have an easy day." Once a year or so, the DoD would go through some management-techniques craze sold to the brass by some Senator's brother-in-law, and the word would come down from on high to use whatever the latest buzzword methodology was. We'd play along for a little while, and then when they weren't looking over our shoulders any more, we'd laugh and forget about it and go back to doing what actually worked.
Nothing I've seen in my years in industry and academia since getting out have convinced me that there is any value at all in any kind of meeting ritual. The more "process" you try to ladle onto the job of communicating with your co-workers, the less actual communication takes place. This is true regardless of whether you're trying to take and hold ground, save lives, or just get the damned code out the door.
Re: (Score:3)
Re: (Score:3)
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
Re:Curious (Score:4, Interesting)
> 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.
I know this might be a little foreign to someone from the military, but some of us get multiple things done in a day. Our team has a daily standup to ensure we don't step on each others' toes too often, while we're getting shit done. The manager is almost never present, nor does he speak unless spoken to in the standups (with exceptions, if he's gone and done something related to one of our features or has a concern about contingency).
Your sentiment is backward, at best.
stand up - sit down (Score:2, Funny)
Our daily 15 minute stand up meetings turned into daily 1 hour sit downs.....
Re:stand up - sit down (Score:5, Informative)
Then you're doing it wrong. The standup should be for status and blockers only - if you need another meeting, schedule it during the standup.
Re: (Score:3)
The key to making these meetings go fast is: participants are not allowed to interrupt, discuss, or ask questions while other people are giving status updates. It makes the status updates go really fast. Afterwards, people can stick around and discuss if they want, but are free to leave if they don't need to be part of that discussion.
-- 77IM
Re: (Score:3)
We do a weekly meeting. In between we do a lot of informal meetings; one off two-three person hallway get-togethers. Lots of times those are standups; if they longer than a few minutes we'll grab some chairs.
This lets me keep tabs on what's going on, keep in touch with how people are doing (yes I'm management) and also gauge where people are in their lives.
I know a lot about my employees through these meetings; projects, clients, co-workers, kids, wives, husbands, relatives, so I know if someone's child i
Re: (Score:3)
It really depends on the team size. You just cannot afford to have a daily stand up meeting, if 20+ people need to report updates everyday. On the other hand, if your team size is small, you are doing it wrong.
If your team is larger than 10 then you are doing it wrong.
Really? (Score:2)
I guess there are lots of ways to get people laughing at you, which is what would happen if you tried to institute this at my workplace.
Re:Really? (Score:5, Insightful)
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.
We had dailies (Score:3)
Re: (Score:2)
Re: (Score:2)
sure they're helpful (Score:5, Insightful)
You go outside with your boss and have a smoke and tell him what's really going on..
Re: (Score:3)
Hah! Reminds me of the stereotypical Japanese company meeting, where nothing really gets done; it's the drinking parties before and afterwards where real communication, agreements and work get done.
Re:So wait, (Score:5, Funny)
Depends on what you're smoking.
No electronics rule (Score:2)
No two-way pagers (how I started), no phones, no laptops.
Come in, complete your agenda, manage the meeting so if participants need to cover something in detail, go off and do it and give a quick report at the next meeting, or send it to the project manager to distribute to the group.
If you are to busy to focus, then don't attend.
I'm sorry, what? (Score:5, Insightful)
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 ).
Re: (Score:2)
Sounds like a good occasion to quit on the spot.
Re:I'm sorry, what? (Score:4, Insightful)
You are late. Have a good reason? No? FIRED!
You are talking like good engineers are growing on trees. In reality they are very hard to find, and they *will* quit on the spot if you pull a stunt like that.
Besides, what is a good reason? A car broken down? A traffic jam? A child who was sick all night? A family problem? A developer who read an important technical book all night and overslept in the morning? A cell phone with a bad battery? Who is there to decide?
Performance of employees is a multi-edged graph, of course. One employee may be rude; another is always late; another's code is not even refactorable, let alone compilable. There could be all kinds of problems. Manager's job is quite messy. He has to deal with "human factor" more than he deals with hardware. Engineers will take care of the hardware; the manager's duty is to take care of engineers. Firing them left and right for disrespecting your meeting times will leave you all alone in the department. Who is going to do the job? You will be fired on the next day, and your fame in the industry will be far worse.
No meetings are even better (Score:3)
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".)
Re: (Score:3)
Re: (Score:2)
Re:No meetings are even better (Score:5, Insightful)
Their great if done right. (Score:5, Insightful)
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
Re: (Score:2)
Re: (Score:3)
I disagree. (Score:3)
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 sp
wow (Score:5, Insightful)
Re: (Score:2)
Yea (Score:2)
Re: (Score:2)
Re: (Score:3)
Then your meeting host was incompetent, and you didn't care about wasting your coworkers time. But that's a personnel problem, not a fundamental flaw in the meeting design.
Standups can be extremely useful. (Score:5, Insightful)
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.
Only works with respect (Score:5, Insightful)
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.
Dilbert! (Score:3)
I'm sure Scott Adams will greatly benefit from these fads. Just think about Wally participating in stand up meeting!
I'd rather not stand (Score:5, Insightful)
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!
Re:I'd rather not stand (Score:4, Insightful)
I have two with my dogs every day (Score:2)
stand ups dont work well (Score:2)
I tried to get my team to do daily stand up meetings, but everyone quickly ran out of fresh material and no one was funny anymore.
The funniest thing I've heard recently is that I'm doing it wrong. That was a kick.
Meetings... (Score:3)
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
Re: (Score:3)
At my last job it was exactly this, your doing it wrong we have no suggestions and you better fix it with all that free time you have doing 3 peoples work cause we are bleeding money cause no one in the entire place has a clue of a goal or how to reach it, so we do redundant work.
Job before that meeting were fine, here is what we are doing, here is how we all could improve, what are your ideas, and we will try that and see how it goes from there!
So yes it totally is related to the incompetence of the bosses
Not too often (Score:5, Insightful)
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.
Agile has become another marketing buzzword (Score:3)
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.
They are a gimmick (Score:4, Insightful)
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
Re: (Score:3)
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.
If you don't give a rat's ass about what people are doing on other projects, ever, you're probably not a very good team lead or developer, but more importantly not a very good co-worker. And even if you know, does that mean everyone else on the project does? Everyone else in the company? Does IT know this afternoon would be the 100% worst time to update the servers? Does the designer doing a videophone assessment with Slovenia know the network is going to be saturated at 2:00?
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.
What if no one on your immediat
Dilbert (Score:5, Funny)
http://www.dilbert.com/fast/2008-04-15/ [dilbert.com]
The Queen (Score:5, Interesting)
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.
failure (Score:3)
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.
Precedent (Score:5, Interesting)
If you want to keep meetings fast (Score:3)
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.
It's AWFUL (Score:4, Informative)
How time flies [slashdot.org].
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.
Cargo Cult management (Score:3)
I've been pushing my department of developers from using the corporate approved modified waterfall [wikipedia.org] 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 [gigaom.com]. 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.
Re: (Score:2, Insightful)
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.
Re: (Score:3)
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 ti
Re: (Score:3)
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 d
Re:No magic bullet (Score:5, Funny)
Wow, you've really synergized your paradigms for maximum best-of-breed stakeholder network impact, haven't you?