Wow...i Have completely failed to keep writing in this blog at all. A lot has changed since I've lasted posted. New job, new house, new projects. But that isn't what I'm going to be writing about today. Today I'm going to be writing my thoughts on daily stand-up meetings.
I hate them. Dear god do I hate them.
I understand there are different ways to do a stand-up meeting. The stand-up meeting I've actually experience is the standard run of the mill variety I see posted online on how to do stand-up meetings. Everyone standing in a room, and one by one what they did yesterday, what they are working on today, and if they have any estimates on completion time and if there are any problems.Here are my grips with this
1) "Did you do your homework"
When I'm asked what I did yesterday, I'm reminded of my mother making sure my homework is finished before I started playing video games. I shouldn't have to remind the team what I'm working on, much less what I've accomplished. Even what I'm working on is relevant to another teammate's work, in which case they are probably aware of what I am doing as long as there is good communication, or it isn't, in which case they don't need to worry about what I'm working on. I don't need my hand to be held to make sure that my work is getting done. If a daily stand-up is needed to make sure someone stays on track, that person probably isn't a good fit for the job.
2) "It is OK if I got nothing done?"
We all know the song, "99 little bugs in the code, 99 little bugs...take 1 down patch it around, 136 bugs in the code." When asking what I've done the day before, an acceptable answer better be "found yet another way to bring down the SQL Server". It's code, not physical labor. Some days nothing gets done. Code should not be written just so one can say they did something. I'd rather have someone write no code for a week, instead thinking about how it should be done, investigating different possible ways to do something, and then spend maybe a day or two writing code, than someone who writes off the top of their head and then a month or two down the line it needs to be debugged. Having to say that I haven't accomplished my task for five straight days is just depressing. Especially when the other team members may not be quite familiar with the code you are working on. We all had that though about another coder that took a bit too long, "God he is so slow, I could do this task in half the time." No, we can't. There is a nasty edge case that really screws with the code that we are unaware of. Having to justify why you accomplished nothing the day before just encourages either bad code for the sake of being able to accomplish something or lying about what was accomplished.
3) Nagging
"Is it done yet, is it done yet?" No I have no idea if I'll be done today or tomorrow. We all think it'll take just 10 minutes to write some code, then that nasty edge case from above rears it's ugly head and now you aren't done until two weeks later. It is tough to estimate how long code takes to write (correctly that is). In my opinion it should never be done in days. At a minimum it should be estimated in week or even month increments. Days are too hard to predict. And, please never give an estimate of completion in percentages. Because the first 90% of a project takes 10% of the time and the last 10% takes the remaining 90% of the time. So saying you are 45% done is ultimately meaningless.
4) Encourages bad communication the rest of the day
I've heard someone tell a coworker to bring up an issue in the next day's stand-up. This was at 11:15 in the morning. So half the day the question didn't get answered. That's a half a day wasted in my opinion. Having a daily stand-up brings up opportunities to ask questions or discuss potential roadblocks, or find someone who can help. It is one of the three core questions. (What did I do yesterday? What an I working on today? What are any roadblocks I may have?). But that is a problem, if people feel that is when these issues will be addressed, they've wait until then to address them, instead of getting them addressed right away. Or even try to find the answer for themself if they think someone else has the answer.
Not everything about daily stand-ups are bad. There are a few good points.
1) Being in the know
This point isn't about knowing what everyone is working on. It is more about knowing what is going on at the higher levels. Having everyone in the same room allows for announcements. New employees starting? Special events coming up? Sure you can email announcements, but some people get a ton of email and it may get lost in the shuffle.
2) Priority shifts
I'm talking about major priority shifts. A new project, or sub-set of a project needing more attention. Maybe some task isn't as important and you can let other teams fight to have extra engineers for their tasks, Thunderdome style. This does not include asking a developer to work on a bug different from the one he is currently working on. You can find him at their computer and let them know of that small shift.
And...that's really all I can think of that are good about the standard "daily stand-up". If anyone ends up reading this they'll probably think I'm just someone who either doesn't get it or that I haven't been in one properly done. I prefer the weekly or bi-weekly meeting, where there is a giant spreadsheet and things are crossed off that are finished and the rest prioritized right then and there. A 1-hour weekly meeting actually takes less time than five 15 minute meetings. And I'm only interrupted once in the week instead of worrying every day about how I'm going to explain how I spent the previous day refactoring a method to make it easier to work with because running the debugger thru it was like trying to get a hyped-up 10 year old to go bed.
I guess some people like daily meetings though. If they work for your team then they work. Can't argue with results.
No comments:
Post a Comment