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

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

#41

Post by jillesvangurp » Mon, Jul 25, 2022, 7:58 AM UTC

makeitdouble wrote: post #31

It seems to me that actually, productive and predictable teams finish what they start. Going through the whole explanation, the base assumption is that tasks are clearly defined, there is few surprises, task pipelines seldom break in the middle because of external factors. Which is the hallmark of a predictable dev environment and by proxy, a productive team. All the team has to do to increase it output is stop doing…

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 inefficiency. You get teams and developers waiting for each other and being blocked on each other. So, they start switching tasks and increase the amount of work in progress, which leads to even more blockage. It looks like everybody is super busy but it's actually very inefficient. Before you know it, you have lots of half finished things blocked on something and an issue tracker full of work that was specified months ago and probably is not even valid anymore. People get stressed and deadlines start slipping.

All this increases cycle times of individual work items. Reducing the amount of work in progress means things move faster through the system overall and less things get blocked. And when they get blocked, it gets resolved faster. Also people feel better about things because they get things done. And, they get feedback faster, which is also a good thing. The counter intuitive thing with this is that reducing the amount of work increases overall throughput and increases predictability.

I rewatch this once in a while because it is just such a great presentation: https://www.youtube.com/watch?v=L6v6W7jkwok&t=3601s

I try to manage my teams and products accordingly by creating clarity on what it exactly is that we are building from week to week and what the priorities are. I like having small teams or groups of people rather than having big teams. Because that allows me to have more than one thing being worked on. When it comes to product management, I don't like specifying too much ahead of time. There's no point in having months worth of inventory of feature work that won't get worked on until months later. By the time work starts, half of it is probably invalid anyway because requirements and priorities always change.

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

#42

Post by jraph » Mon, Jul 25, 2022, 8:08 AM UTC

gravlaks wrote: post #33

jraph wrote: post #23

Earlier quoted context omitted.

Releasing is great. Unused work is quite sad. A big condition for motivation though is if people are not pressured to rush features. Being in a rush does not work long term and not being happy with the quality of the work done is very demotivating and impairs the sense of meaning. Micromanagement too. Personally, the two week sprints and daily stand-ups did this to me in my previous job, but I can see they could be a…

What kind of micromanagement did you experience / E.g. do you have an example? I'm in the position where I as tech lead don't fully know if I can trust my team (yet) to do the right decisions. One of the reason is that our product is quite new, and we haven't discussed developing principles yet. And some people tend to over engineer stuff all the time. But I also don't want to micromanage.

Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do seem like to have this kind of daily routine so your mileage may vary obviously.

Having to fit tasks in two weeks periods was a problem too, with all these ceremonial meetings where we end up having to make things up and which actually take a lot of time. Being able to give feedback is good, but I don't like to be polled every two weeks on this in a far too long meeting, and waiting the end of the sprint if something is actually wrong is not ideal neither. We ended up merging shit code if the tasks actually needed more than two weeks and artificially splitting those tasks into smaller ones is a lot of overhead and can have deleterious effect on the code architecture. I think we were also not very good at planning a bit ahead so decisions needed to be taken and validated by the boss too often, which can feel like micromanagement too.

Trusting your team about taking the right decisions is probably not an issue, if you have meetings where you make the general "big picture" (design) decisions all together. It'll probably help you notice that your team can make the good decisions too. But if you do have the big picture, it's a good thing you participate in this. I think small decisions should be left to the developers though.

Not trusting they will do their job would be an issue.

Good luck :-)

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

#43

Post by boffinism » Mon, Jul 25, 2022, 8:09 AM UTC

I once worked in a VERY chaotic startup with near-constant pivots and priority shifts. In each case, at the time, the change in direction could be justified... but morale was chronically low, particularly among software engineers. I spoke to one who, after a year, mournfully revealed that none of the code he had written had ever shipped. He, and most of his colleagues, burnt out and dropped out pretty fast.

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

#44

Post by thundergolfer » Mon, Jul 25, 2022, 8:18 AM UTC

captnswing wrote: post #18

Henrik Kniberg recorded this fun 5min video a long time ago, about the relation between "utilization" and "flow" and how to optimize for both. I keep showing that to people, never gets old https://www.youtube.com/watch?v=CostXs2p6r0

I just read The Goal, and that video has translated one of the lessons from that book, which is about industrial parts manufacturing, into the Agile software dev world.

Good book, and good video.

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

#45

Post by ChadNauseam » Mon, Jul 25, 2022, 8:33 AM UTC

sebcat wrote: post #25

coderintherye wrote: post #22

This is why when leading an engineering org I narrowed down to one metric: Committed to Completed Ratio It encourages completing things and only committing to what you can complete. It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. Bu…

You get a pretty good ratio by doing very little using only that metric.

A slightly better one: (committed + 1)/(completed + 2)

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

#46

Post by d0m3 » Mon, Jul 25, 2022, 8:35 AM UTC

This article makes some assumptions that could easily change the result. By the way, if you have a batch size of 1 you're back to the initial hypothesis which is obviously not how things work in the fast food industry. I think it misses the point of idle time and availability. From the supply chain theory, if your resources are always 100% busy, your delivery time will go infinite because as soon as something takes a little more time as expected then you can never catch up. This applies particularly well to software engineering.

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

#47

Post by baby » Mon, Jul 25, 2022, 8:44 AM UTC

jraph wrote: post #23

jmathai wrote: post #17

In my experience on small teams that I've been on - a key motivator for people is shipping products and features. The sooner and more frequently you can do this the more positive reinforcement there is for the entire team - not to mention reduced risk of something never making it to the target users. Teams that have figured out the optimal way to get product and features into the hands of users as quickly as possible…

Releasing is great. Unused work is quite sad. A big condition for motivation though is if people are not pressured to rush features. Being in a rush does not work long term and not being happy with the quality of the work done is very demotivating and impairs the sense of meaning. Micromanagement too. Personally, the two week sprints and daily stand-ups did this to me in my previous job, but I can see they could be a…

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

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

#48

Post by js8 » Mon, Jul 25, 2022, 8:56 AM UTC

If we all were just workers, it could work. In practice, I see lot of the high-level ideas/strategizing people starting new projects without finishing the old ones. They never bother with details required to finish or complete something. Starting and not completing is fundamental to labor division in capitalism, for better or worse. Without it, there would be less labor extraction.

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

#49

Post by valenterry » Mon, Jul 25, 2022, 8:56 AM UTC

baby wrote: post #47

jraph wrote: post #23

Earlier quoted context omitted.

Releasing is great. Unused work is quite sad. A big condition for motivation though is if people are not pressured to rush features. Being in a rush does not work long term and not being happy with the quality of the work done is very demotivating and impairs the sense of meaning. Micromanagement too. Personally, the two week sprints and daily stand-ups did this to me in my previous job, but I can see they could be a…

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

I think for junior developers that might be true. Does the name connect? :)

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

#50

Post by yakubin » Mon, Jul 25, 2022, 8:57 AM UTC

jraph wrote: post #42

gravlaks wrote: post #33

Earlier quoted context omitted.

What kind of micromanagement did you experience / E.g. do you have an example? I'm in the position where I as tech lead don't fully know if I can trust my team (yet) to do the right decisions. One of the reason is that our product is quite new, and we haven't discussed developing principles yet. And some people tend to over engineer stuff all the time. But I also don't want to micromanage.

Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do seem like to have this kind of daily routine so your mileage may vary obviously. Having to fit tasks in two weeks periods was a problem too, with all these ceremonial meetings where we end up having to make things up and which actually take a lot of time. Being able to give feedback is good, but I…

> 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 of the intended effect.