As someone who hates standups I tend to disagree. I've found that without some kind of forced daily interaction, lines of communication in a team break down very quickly if they aren't already extremely tight knit. Once that happens, your project is toast.
You don’t need standups
101–110 of 341 posts
Re: You don’t need standups
#102I think a lot of the themes in this article I can agree with, but I come away with the overall impression that the author hasn't necessarily worked in a healthy agile environment before. Basically, I agree with many of the conclusions (or solutions) but disagree with a lot of how the author came to them.
Standups aren't inherently bad. Also it sounds like he moved his team to more of a kanban style workflow -- which many people use already. That isn't ground breaking. There is still iterative planning, even if they aren't "sprint planning" sessions.
Re: You don’t need standups
#103The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time.
I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to me for that sprint and just thinking...really? If I don't complete the second high-priority task before the end of the sprint, so what? I still made progress on it.
It just felt like so much time was being wasted. We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. If you had 30 hours worth of tasks assigned to you already, and there was a 20-hour high-priority task in the queue, it'd get bumped to the next sprint with 10 points of low-priority tasks assigned instead. It was more important to them to get precisely an estimated 40 hours of tasks completed, rather than getting supposedly high-priority tasks done.
Obviously, this frequently resulted in priority inversion, not to mention the problems from poor estimations of task time.
Management was often clueless. You only earned the points when you completed the task. So if you took on two 20-hour tasks, and just barely didn't finish the second one before the end of the week, but then completed that plus 40 hours the next week, they'd question why your productivity swings so much because you only got 20 hours done one week, but 60 hours the next!
And of course, as mentioned, these "hours" were all estimated hours, not the actual hours done. People started overestimating the hours needed for tasks, but management was apparently smart enough to catch on to that when they noticed everyone was getting 50-60 hours worth of work done, despite everyone only working about 40 hours per week.
I've rambled a bit, but you get the idea. I think the author is spot on. Just use your task tracker.
Re: You don’t need standups
#104A team where the Engineering Lead(or any kind of manager) thinks that you don't need retros because there are no problems is exactly the kind of team that needs retros.
Meh. A team with a leader/manager like that isn't going to get much value out of retros because either the leader/manager isn't going to listen to what's being said, or everyone won't feel safe enough to be able to say what needs to be said.
Re: You don’t need standups
#105The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to m…
>The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time.
That's because sprints weren't designed for us. They're designed for management. Product managers and VPs need to be able to think of their "resources" in manageable, discrete chunks. Vagaries are an absolute antithesis to their world view. Small boutique firms can avoid this, but mass production means the need for mass conformity.
Re: You don’t need standups
#106One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing t…
"working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with. "I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Sta…
> "working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with.
Don't take people so literally.
Re: You don’t need standups
#107I'm so in alignment with this. I've always hated standups. As a night owl, it's a morning meeting I have to make every single day and I hate it. I also don't understand how I can't just communicate in Slack to say "hey this is what I'm working on, this is what I worked on. Here are the questions I have." And move on. And if the PM prioritizes the backlog, always pick from the top just makes sense . And yes, retros fe…
We have some teams that do "slack-ins" but I find few people read the updates and even fewer questions are answered or asked. At best, this gives micromanagers satisfaction while not doing much, and at worst it's a log of "well I told you so"
The fact that everybody tunes out these updates suggests that the things being communicated are of low value.
Re: You don’t need standups
#108Earlier quoted context omitted.
I think that's either a team culture issue, a management issue, or a business culture issue. Teams I've worked on have had no issue brainstorming ideas for a person who's stumped. Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an abso…
Are stand up meetings the correct venue for brainstorming?
Maybe not, but if your peer said "hey can someone help me with this task" in a standup, wouldn't you want to help them once the meeting is over?
Re: You don’t need standups
#109One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing t…
The best meeting updates are just the surpises.
Sometimes I’d start meetings with, “first, let’s go around the table and report any surprises this week”, and then adjourn the meeting.
Re: You don’t need standups
#110Earlier quoted context omitted.
1. Agile is not personally great for programmers. 2. Agile is good for managers. 3. Managers run the business and make sure it exists. 4. Programmers need the business in order to have a job. 5. Agile is therefore good for the business, 6. And therefore Agile is good for Programmers, though not personally.
I would disagree with almost every claim on this list.
I don't really have that strong of an attachment to any specific one of these claims. I was just pointing out the logic of the parent comment is very narcissistic (without saying as much).
The logic falls apart when you look at different individuals and different companies. For example, if your company is very political then what is good for managers very likely is not good for programmers. If your company focuses on teamwork and has a strong one-for-all;all-for-one culture, then whats good for managers probably is good for programmers.