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?"
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!
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.
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'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!
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.
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.
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.
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
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.
Mod parent up. I've been in software development for 5 years now and Dijkstra's algorithm has never come up even once. I learned it in college, I know it, but claiming it's any sort of litmus test or secret handshake is just wrong.
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.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking