Finishing what you start makes teams more productive and predictable • Hacker News Board

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

#161

Post by ido » Tue, Jul 26, 2022, 2:10 AM UTC

roeles wrote: post #159

ido wrote: post #68

Earlier quoted context omitted.

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.

Ideally yes, but it’s also not that easy to find senior developers and a lot of them don’t like having to hand-hold juniors.

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

#162

Post by throw1234651234 » Tue, Jul 26, 2022, 12:41 PM UTC

satyrnein wrote: post #157

throw1234651234 wrote: post #94

Earlier quoted context omitted.

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.

Same problem. Someone I used to work with wrote an article about it and you run into the same problem with A/B tests / canary deployments / etc - need to account for different DB schemas:

https://medium.com/swlh/worthwhile-modern-deployment-strateg...

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

#163

Post by Too » Tue, Jul 26, 2022, 6:18 PM UTC

klodolph wrote: post #5

Fact is, a team with five people working on five independent tasks may be able to proceed at high throughput, because of the cost of coordination when you assign multiple engineers to the same task. That is, if you have chef A making a burger, and chef B making a salad, and chef C making a cake, then they can all go at full speed because they're using different parts of the kitchen and don't need to coordinate with e…

The problem becomes a lot more difficult and interesting once you start involving multiple people.

Should everybody have many or exactly one task assigned? Should one person be on stand-by for operations? Should tasks be paired to two developers? Whole team mob programming one task? Are all the tasks truly independent?

Should juniors in team have same WIP as seniors or is the limit counted for the team as a whole? I see some teams almost give juniors a backlog of their own with the most basic cookie cutter tasks, even if they are low in prio, just to get them on board. Other teams handcuff them together with a mentor doing normal tasks. Vice versa for tech leads who often have another set of tasks only they do.

If everybody is working on a task, then who will code review others work? This can end up in a priority inversion situation, if Alice finished working a high prio task, should Bob working on a low prio task drop his work to review Alice work or should he finish his existing work to keep within his WIP limit.

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

#164

Post by gravlaks » Wed, Jul 27, 2022, 8:02 AM UTC

jraph wrote: post #155

BurningFrog wrote: post #132

Earlier quoted context omitted.

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…

Totally agree. And so does my team. We solve this by running daily Slack-ups, i.e. just tell what you're doing on Slack, which is much, much faster.

We only use daily standups when there are new people on the team.

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

#165

Post by jillesvangurp » Wed, Jul 27, 2022, 9:51 AM UTC

makeitdouble wrote: post #72

jillesvangurp wrote: post #41

Earlier quoted context omitted.

Don Reinertsen has some interesting arguments for all this based on keeping inventory of work in progress low, maintaining short work queues (amount of time things sit in an issue tracker), minimizing the number of things being worked on at the same time, and minimizing time to delivery (cost of delay). Basically his reasoning is that overloading teams with more work than can be handled actually leads to delays and i…

I went through the video. For the HP example, their core issue was a quasi infinite backlog because they would add to the pile regardless of their velocity. This looks to me to be a problem that is orthogonal to doing tasks in parallel or not: in the single task a time model, the extreme case would be an employee stuck on a single task without any lever to unlock it. Both scenarii are a failure of task management, an…

It's a very common thing that I've seen in many projects. Bad inventory management basically. PMs just build a huge backlog of stuff. By the time people get around to that stuff it's months out of date and probably half wrong anyway. That's why waterfall is not a thing. Developers are not great at multi tasking. And switching tasks has a cost of making a context switch. If you spread things out over time, you basically get a lot of cost related to that and you stretch the time to initial feedback on whatever it is you are doing.

The smarter way to manage projects is to deliver stories, design, etc. just in time to have them ready for immediate implementation and thus shorten the cycle time from coming up with a thing to do all the way to having the thing in production. That minimizes context switches and ensures everybody still has everything that was agreed in their heads.

I've been on projects where PMs had 10 sprints completely planned out and they'd be shitting their pants by sprint 2 because it wasn't working out as they wanted it. That's not agile, that's waterfall and it cannot possibly work. But it's what a lot of people revert to.

Reinertsen's points are that there are good reasons that you can reason about from an economical point of view to do things differently that neatly align with a lot of intuitions developers have anyway. Queue theory applies to all sorts of queues, including issue trackers and backlogs.