You don’t need standups • Hacker News Board

Re: You don’t need standups

#161

Post by brazzy » Thu, Aug 02, 2018, 9:56 PM UTC

ApolloFortyNine wrote: post #127

Shaanie wrote: post #115

Earlier quoted context omitted.

Why are you estimating things in hours? Why is management tracking the amount of story points every developer completes in a sprint? Why are you not working on the highest prio stuff in the sprint? Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?

People always say not to estimate in hours and instead to estimate in "points", but at the same time teams tend to plan around how many points they're taking into a sprint. If you have 40 points but usually take only 30, you'll be asked to bump something out. And once you agree on a number of points to do in 2 weeks, it's not rocket science to figure out an estimated number of hours per point.

The point (heh) is not that there is no mapping between story points and time, the point is that it helps us acknowledge that these are estimates, not promises that signify failure if broken. No individual estimate is expected to be exact, but we hope that deviations from the estimate average out across the stories in a sprint.

And most importantly, story points make it easy to base our sprint commitment on the available evidence from previous sprints. We say that we can do 40 story points in a sprint, because we know that is roughly what we managed to do in the last few sprints. The conversion factor can change over time as the team gains experience, or the team changes, or the nature of the work changes. It's much harder to do such adjustments when you directly estimate hours.

Re: You don’t need standups

#162

Post by brightball » Thu, Aug 02, 2018, 9:59 PM UTC

Not going to lie...I like stand-ups, but I am an extrovert. I also like them as a full time remote because it's the only way I regularly see my team.

As long as it doesn't interrupt people. 10am is to late if the work day starts at 8:30am. About 45 minutes after the "beginning" of the day is about as long as can be tolerated. Give people time to arrive, account for traffic, get coffee, check some email, quick stand-up with the team and then get to it.

At the same time, there's not a point where I think stand-ups encourage prioritizing features over tech debt. Usually, that comes from sprints themselves and the planning around sprints. Stand-up shouldn't be anything more than a quick "how's it going" for the team.

I would have no argument as a developer working under this unless the quarterly goals were out of control.

What you're describing is basically Kanban.

I agree with almost every word.

Re: You don’t need standups

#163

Post by colinprince » Thu, Aug 02, 2018, 10:00 PM UTC

DanielBMarkham wrote: post #31

I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how. According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour. That may be true, but…

Let the developers alone.

This means the tech lead must find something else to do.

Good.

However, all the tech leads I've met think their job is to get up in my hair.

Stop doing it, is what I want to say.

However, we need to show the tech leads what we really need from them.

So they don't displace their activity getting up in my hair.

Re: You don’t need standups

#164

Post by Benjammer » Thu, Aug 02, 2018, 10:02 PM UTC

RussianCow wrote: post #158

chomp wrote: post #63

Earlier quoted context omitted.

"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…

> ...there are times when we are waiting for something, and there's nothing able to be done currently. Especially when the immediate tasks are already doled out and your leader doesn't want to pull more work into the current sprint. Subsequent tasks could be too large or complex to be pulled in. Current tasks could be unable to be broken up any further... I find this concept very strange. Maybe it's just me, but asid…

I have no direct experience, so take this with a grain of salt, but I think this type of thing only really tends to pop up in large multinationals that literally just end up with too many moving parts at certain points to be able to keep every gear spinning at once. The business process dependency tree is just plain old _too complex_ to get 100% utilization of every piece at every point in time. It's more profitable for the business at that scale to have a certain role just "idle" for a period of time rather than fundamentally change business processes to maximize individual resource utilization.

Re: You don’t need standups

#165

Post by ravenstine » Thu, Aug 02, 2018, 10:03 PM UTC

matthewmacleod wrote: post #55

ravenstine wrote: post #28

One 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…

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. That would raise immediate, massive, flashing red alarm bells in my teams! I understand that different environments have different requirements, and different teams have different needs though.

Maybe other teams work radically differently, but everywhere I worked it was inevitable that team members would occasionally get "meaty" projects to work on where they would take primary ownership. Under the repetitiousness and time constraint of stand-ups, it still outwardly appear that the smaller tasks broken out of a large project can all sound the same to others on the team who are only mildly interested in the details of other people's tasks.

If I was working on a very functional team where we had the employees and resources to work very collaboratively across projects, I'd certainly agree that (groups of) tasks that take that long should raise alarm bells. But most companies, in my experience thusfar, minimally value their developers and only hire X amount of them, so the developers they did hire are naturally forced to take on large projects to the point of taking sole ownership of them.

Disregarding that, I don't see it as unreasonable that tasks shared between multiple people would take weeks to figure out. If I were hiring developers, I wouldn't want them to race to make a bunch of horseshit that's going to fail, but instead they should take their time to figure out the right approach. In conjunction, they should be able and allowed to communicate when long-running tasks aren't going anywhere, without any shame. As long as they document the steps they took along the way, there's no reason that standup needs to play a role; with documentation, a manager should be able to tell if an employee is incompetent or merely trying to do their job right.

I don't think that stand-ups are really a big deal, but if I were running a team, I probably wouldn't use stand-ups in a traditional sense. Rather, I'd keep stand-ups but not make them goal-oriented or strictly related to work in any sense. As I said earlier, I think it's positive for people on a team to interact at least once throughout the day if they are in the office, and a quick and optional stand-up in the morning would be a great way to facilitate this. If someone wants to bring up an issue or asks if another team member knows how to do X thing, then awesome. In fact, I suspect people would be more comfortable in doing so if they aren't wasting time thinking up how to summarize their work for stand-up, and if stand-up was kept casual and didn't devolve into employees reporting to their manager.

Re: You don’t need standups

#166

Post by Jach » Thu, Aug 02, 2018, 10:05 PM UTC

walshemj wrote: post #124

kolinko wrote: post #33

Earlier quoted context omitted.

Besides that, I hate that they took me out of rhytm of work. If a standup is at 10am, and I arrive at 9am to do dev work, there is very little I can do before being interrupted - I need at least 2-4h of interrupted time to do some good work.

That's why you should do them at the end of the day as we did of my first very successful Agile project - presented at the IIIE I believe after we finished. Though that was the full on clean room high level sponsor route, collocated with the customer.

I did that (4pm standups) for a while on a team that was just me and another guy plus our team's dev manager, qe manager, and product manager. All the managers were in HQ, my teammate and I were in separate remote offices, so it was done over Hangouts. We loved it being late and got a lot done for just two of us over the few months, but the managers didn't like it (very few times they'd all show up, and dev manager always showed up while on a bart train) and killed it (back to 10am meetings) a few weeks before the team dissolved.

I've been on 11am standups lately and they're not too bad, but it incentivizes me to either come in at 8 or come in at 10-10:30. The latter is what usually happens.

Re: You don’t need standups

#167

Post by fakecigar » Thu, Aug 02, 2018, 10:05 PM UTC

Shaanie wrote: post #131

s73v3r_ wrote: post #80

Earlier quoted context omitted.

1. Isn't the standup usually the place you're told to initially ask for that help? 2. Aren't most people, at least the developers/designers in the same standup, supposed to be working on the same project?

Don't wait until the standup to ask for help if you don't have to. I'm also confused why OP is having standup eith people who havent even heard of the project he's working on. Doesn't sound like he's working on the same product as the other developers.

+1

The standup should be the place of last resort for bringing up barriers impeding a task. The more resourceful you can be at solving a problem/brainstorming outside of the standup the better ime

Re: You don’t need standups

#168

Post by mmcnl » Thu, Aug 02, 2018, 10:07 PM UTC

vfc1 wrote: post #81

Standups always felt to me that they had a core negative message to developers. It's not about communication at all. Its about control, its about saying: We don't trust you. We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance. Its also about putting constant psychological pressure on developers, to make sure they complete the…

Standups are about developers updating eachother. Basically no one outside the development team should be in the standup. I don't get what's negative about this.

Re: You don’t need standups

#169

Post by ravenstine » Thu, Aug 02, 2018, 10:08 PM UTC

walshemj wrote: post #138

ravenstine wrote: post #28

One 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…

Then that is a project that should not use Agile in my opinion.

I first read your comment as the inevitable "that's not true agile" response. Haha

Perhaps companies should just pick and choose what parts of Agile methodology suits the situation. I don't really buy the idea that Agile only works if there's an ensemble effect from every workflow aspect made Agile.

Re: You don’t need standups

#170

Post by lmilcin » Thu, Aug 02, 2018, 10:08 PM UTC

This is easy to explain. Main premise of agile is spending a lot of effort on improving the process. These are the standups, demos, retrospectives, etc.

It is no wonder you get more done if you cut the effort. You are coasting on past improvements. This is only going to work for a while until your performance starts to slip because the team stopped correcting and improving.

Spending time on improvements is important for other reasons. If your team spends 100% of the time on project work it is inefficient by definition (though not very intuitively, but see constraint theory). Spending time on improvements creates necessary flexible buffer. This is an alternative task when there is shortage of project work or it can be temporarily cut if there is too much project work.