Live data from Hacker News

Finishing what you start makes teams more productive and predictable

lucasfcosta.com

151–160 of 165 posts

Re: Finishing what you start makes teams more productive and predictable

#151

Earlier quoted context omitted.

Well, sure. I wasn't saying it never happens to non-junior engineers.

Respectfully, that seems to be what your parent comment says :). > I think for junior developers that might be true. That strongly implies, if not outright says, "this only inflicts junior engineers".

I meant "if this can be generalized onto anyone at all, then at most junior developers". Was probably not the best way to express that, haha.

Re: Finishing what you start makes teams more productive and predictable

#152

Earlier quoted context omitted.

While I agree that my job is broadly to bring order to the disordered, I would prefer if the disordered accepted that my proposed way of doing things will eventually achieve order without doubting me every morning , as it is after all my job to find the optimal algorithm to order things since I have myself optimized myself to find just that. I don't want to fight, I'm simply unable to process your disorder in real-ti…

A standup is not "doubting you" and five minutes once a day is not "real time". It's rather the opposite; everyone is trusting you to raise issues when relevant, and making space to do that, rather than letting anyone interrupt anyone else anytime they think of something. It can go wrong if you have shitty teammates, a detached PO, a selfish team lead, etc. So will everything else.

If it's really 5 minutes a day and if you're really satisfied with every monkey nodding once, then sure, this ritual can be accomplished with a moderately-sized team. But please provide data that shows that this has ever been achieved organization-wide anywhere with more than 10 employees. Seriously. I need to know.

Otherwise stop polling devs once a day when they already said the earliest you'll get anything is 2-3 days. They literally will quit over this in the long run and it's the simplest thing you can do to stop losing devs over communication issues between your team members.

They cost enough per head and you want to literally start their day with a reminder that they've unwittingly joined a cult to pay the rent?

Re: Finishing what you start makes teams more productive and predictable

#153

Earlier quoted context omitted.

A standup is not "doubting you" and five minutes once a day is not "real time". It's rather the opposite; everyone is trusting you to raise issues when relevant, and making space to do that, rather than letting anyone interrupt anyone else anytime they think of something. It can go wrong if you have shitty teammates, a detached PO, a selfish team lead, etc. So will everything else.

If it's really 5 minutes a day and if you're really satisfied with every monkey nodding once, then sure, this ritual can be accomplished with a moderately-sized team. But please provide data that shows that this has ever been achieved organization-wide anywhere with more than 10 employees. Seriously. I need to know. Otherwise stop polling devs once a day when they already said the earliest you'll get anything is 2-3…

Our 7 person standup takes about 30 seconds if nobody is blocked or has any questions. Most days it takes longer because most days at least 2-3 developers want to say something.

If your team lead (or god forbid somehow a PO is present) is lecturing or questioning individuals to report about specifics during standup, I'm sorry you have a shitty boss.

Re: Finishing what you start makes teams more productive and predictable

#154

Earlier quoted context omitted.

I hate having to ship features when I just want to work on improving reliability, doing upgrades, improving DX and clearing all the crap out of the way that's preventing us from otherwise shipping.

All that stuff is important, and I enjoy it more than most. But I also keep in mind that the only point of it is to enable shipping more features faster and better.

For sure. For me it's about ratio's though. It never makes sense to me when I encounter situations where 100% of capacity is dedicated to features, features, features when sustained velocity is in the toilet when it feels like we're standing in an entire orchard of low-hanging fruit of productivity gains to be had. I usually find that after about a year or so in a company it starts to click for people that if they just let me be more self-directed then stuff starts to improve for everyone at a faster rate and it's win-win. I know there are other devs like me, but I feel like it's not widely recognized that we exist and should be enabled to just do our thing. I don't know if you can relate, but maybe you can?

Re: Finishing what you start makes teams more productive and predictable

#155

Earlier quoted context omitted.

I'm not against stand-ups per se, just against daily stand-ups. Currently I'm in a team which does three a week. That's at least tolerable, but if it was up to me, I'd opt for once a week. Daily made me feel that I had no agency over my work, that everything to the tiniest detail needed to be negotiated with someone, most often the manager. Less agency means lower engagement in work. At least for me. I do know that t…

We must mean very different things by "standups". My standup messages are mostly "I'm working on adding feature X, it's going well", or "I'm fixing bug Y, and I wonder how to handle Z". Usually that's it. Sometimes there are questions or discussion about details. It serves to keep the team aware of what's going on. If your team is argumentative it can drag out and be a drain. That's when it is up to the manager to br…

This is also what I mean by stand-up.

These stand-ups get in the way. I'm bored when I need to listen to what people have to say, or worse, what they are making up. I'm stressed by what I need to say or make up. They take time. They often happen at a time where my productivity would be the best / when I'm in the middle of something, or else I need to rush to get on time. Or to watch for the time when we are close and interrupt everything I'm doing. This, every single day. It's fine for meaningful meetings solving real problems, but stand-ups are not this kind of meeting for me.

I very much prefer not having a daily synchronization point, and instead give status to relevant people when needed, or give my status when asked for (which is not too often, we can see what tasks is left for me in the bug tracker). If I'm blocked or if I have a question, I'll ask. If colleagues have a question, they'll ask. We have flexible hours, not at exactly the same timezone, some people are already full of important meetings. Not having a standup to babysit, to schedule, to watch for and to be stressed about is one less problem to handle.

I'm thrilled to be able to start my work day when I'm ready and not having to interrupt for this daily thing that does not seem to bring much value in the end. I'm happy to be able to have an unproductive day and make up for it the next day without nobody noticing it and without me lying about it, because in the end, it's none of nobody's business and it doesn't matter. And the day is just a bad unit of time for development tasks most of the time.

When I had to attend daily stand-ups, indeed standing-up (wtf!), I just had the impression we were (treated like) a bunch of children not able to be autonomous for a few days.

But then, it seems everybody in my current team is wired for working efficiently without this kind of things, so it works for us. We are also good at knowing what people are on to by the reading the stuff they are discussing on the chat, and the big picture, fast, weekly status update we have anyway. I don't need the details brought by the stand up, unless I do but then I will get them via efficient communication anyway.

Re: Finishing what you start makes teams more productive and predictable

#156

Earlier quoted context omitted.

If it's really 5 minutes a day and if you're really satisfied with every monkey nodding once, then sure, this ritual can be accomplished with a moderately-sized team. But please provide data that shows that this has ever been achieved organization-wide anywhere with more than 10 employees. Seriously. I need to know. Otherwise stop polling devs once a day when they already said the earliest you'll get anything is 2-3…

Our 7 person standup takes about 30 seconds if nobody is blocked or has any questions. Most days it takes longer because most days at least 2-3 developers want to say something. If your team lead (or god forbid somehow a PO is present) is lecturing or questioning individuals to report about specifics during standup, I'm sorry you have a shitty boss.

What's the point of having a standup for devs while at the same time assigning a manager to study and organize their JIRA entries? Wouldn't it be better to simply route all notifications through the manager, 7 to 1 (or 6 to 1 if you can find a dev who can reliably manage the communication network between your devs) and then just route the information into JIRA or upstream towards the bosses?

I've never had a case where it made sense to wait until the next day to bring something up to my organization and I've never been to a planned meeting where someone didn't get abused by management for only bringing up the issue at that time.

Re: Finishing what you start makes teams more productive and predictable

#157
post #34

Earlier quoted context omitted.

Yep. And if nobody actually cares about the feature like everyone thought they would, great we didn't waste time. If they hate it (usually through feature flags of product trials), and work needs to be done, simply flip the flag back off. It's a great way to do small-medium features.

No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate different DB schemas / DTOs in addition to the "lol feature flag" on the front end is absurd.

If you want to do rolling/canary deployments without downtime, or gradual rollouts to subsets of users, or a/b testing, you will have multiple versions running in parallel against the same database. Plenty of "serious work" happens that way.

Re: Finishing what you start makes teams more productive and predictable

#158

Earlier quoted context omitted.

The only way to make good reliable estimates is to pad and roll your thumbs until the nominal time is up. If there are teams that meet targets they are padding for king and country.

Picking the 99% or top decile or whatever is not padding, it's the actual job of estimating. Anyone who talks about "padding" rather than uncertainty doesn't understand estimating yet.

Ye I think I might have misunderstood you.

I've got Scrum withdrawal syndrome I can't think straight when seeing the word "estimate".

Re: Finishing what you start makes teams more productive and predictable

#159
post #68
post #50

Earlier quoted context omitted.

> Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do like having this kind of daily routine so mileage may vary obviously. Same here. I used to be in a team with daily stand-ups, reporting to the manager what work I did the day before, and they killed my will to work, consequently causing me to work ~3 times slower, which presumably is the opposite…

The problem is that a lot of developers (especially junior ones) make shitty decisions and/or just work slowly without the accountability of having to say what they worked on (and having to explain why what they said they will “finish today” 4 times already isn’t yet finished for the 5th time). They are not necessarily bad developers, just need the need the external motivator. If you have 10+ years of experience and…

I have seen this happen to junior developers.

In hindsight I think it is much more effective to pair them up with a senior developer instead of waiting for a pattern to become apparent during the daily scrum.

Re: Finishing what you start makes teams more productive and predictable

#160
I thought that was obvious? The easiest way to completely destroy the productivity of a team is to constantly switch tasks and never release anything. The team will quickly realize that the work they do doesn't matter and will switch to pretend-to-work mode or find another job.
Post reply on HN