Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finishing what you start makes teams more productive and predictable

lucasfcosta.com

Post reply on HN
Print view View original

31–40 of 165 posts

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

#31

Post by makeitdouble »

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 the tasks in parallel. Conveniently, there is no real explanation of the status quo, teams must have been really lazy and couldn't think by themselves why they were doing so.

This really feels like one more motivational preacher trying to sell that one weird trick to solve all your problem.

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

#32

Post by von_lohengramm »

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.

I think the purpose of this ratio is that a predictable low is better than an unpredictable high. It's sort of the same idea as padding out an ECD. Better to sometimes impress than sometimes disappoint.

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

#33

Post by gravlaks »

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…

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.

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

#34

Post by thejosh »

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…

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.

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

#35

Post by mirekrusin »

nickreese wrote: post #24
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…

Sounds like a book in the making. Would love to read this.

The essence is right there in the comment, no? Why the whole book about single idea?

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

#36

Post by coderintherye »

nickreese wrote: post #24
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…

Sounds like a book in the making. Would love to read this.

There's been some talk in Agile about such a metric: https://gorillalogic.com/blog/completion-against-commitment-...

Changing to it was inspired by a few things one of which was: https://www.strategy-business.com/article/10204

As well as a talk at CTO club which unfortunately is not shareable but can share the footnote listing: [1] 2014 State of DevOps Report https://devops-research.com/research.html [2] 2016 State of DevOps Report https://devops-research.com/research.html [3] 2015 State of DevOps Report https://devops-research.com/research.html [4] Westrum, R. “A Typology of Organizational Cultures”, http://bmj.co/1BRGh5q [5] Shook, J. “How to Change a Culture: Lessons from NUMMI” http://sloanreview.mit.edu/article/how-to-change-a-culture-l... [6] https://www.slideshare.net/reed2001/culture-1798664/93-Highl...

Though if you are interested in a good book on loosely related subject, highly recommend "Principals of Product Development Flow" https://amzn.to/3Ox4PgB

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

#37

Post by topkai22 »

roberttod wrote: post #13

I think those initial diagrams/explanations miss a key detail. The longest step in cooking burgers is the grilling step, in which the cook is just waiting for the burgers to cook, and won't speed up the process by giving attention to one burger instead of 2. The idea that 3 burgers would take 12 minutes while 1 takes 4 isn't realistic, even without all the batch processing math later in the article. I still agree wit…

This was the most glaring flaw of the post. They almost got there when they started talking about the “transaction costs” but failed to acknowledge idle times.

To drive this home to software development, if I’m blocked on a requirements clarification, awaiting permissions to a data source, or blocked by a bug in an external system it certainly doesn’t make sense for me to just do nothing. I should pick up another task and work on that.

It’s going to be near impossible to substantially limit WIP below the level that ensures near fully committed personnel. That means that as external blockers go up, so will WIP. It’s important to try to fix those things causing blockers (better up front requirements, automated permission processes, etc…) but different teams and organizations will have different fundamental limits on being idled on projects. For some software product feature teams this can be kept very low- a strong requirements process is established, the data needed is consistent and owned by the team, and reliance on 3rd party systems is low. Teams dealing in enterprise IT systems (like mine) often can’t, as much as we seek to improve things, there is a degree of irreducible complexity.

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

#38

Post by rgoulter »

kqr wrote: post #27
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…

Don't people start to go, "oh, we're definitely going to do this, we just haven't committed yet"?

I liked the ideas I read about 'kanban'. If there's a feeling that work flows well, then there's less concern about when things will be done by. If you can maximize flow, or minimize work in progress.. a kanban board should try to be a visual aid to support that. -- "commited / completed" sounds along the same lines to me.

In that sense, I think "it's desirable, but not in progress" isn't necessarily bad in itself. I think it would be better phrased as "this isn't a priority for us right now".

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

#40

Post by doix »

solatic wrote: post #7

Article relies on a non-sequitur assumption that you should work on an entire feature start-to-finish without interruption. What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority. This is what actually reduces batch sizes. Then deciding to prioritize the work to finish a feature instead of new work for a different feature becom…

> What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority.

I would say this is pretty standard, and personally I really hate it. I think it works well if you want to prioritize hitting a date above all else, especially with a junior team or in a "low trust" environment (cheap off-shore team). But for other metrics, I don't think it's great.

In my experience it results in a lower product quality, people do the bare minimum to finish a ticket and throw it over the wall. Since tasks are so split up, things don't end up connecting coherently. The problem you're trying to solve for the user gets completely lost and you end up with a bunch of features that don't necessarily make sense.

In my opinion, it also really sucks for job satisfaction. It makes me feel micromanaged and have 0 autonomy. But I have met people that love it, their reasoning being "I can just zone out and write code without having to think about other things". So that's more of a personal thing.

> If Development doesn't deliver business value because Product can't stick to a coherent feature strategy, that's Product's fault, not Development's.

While you might technically be right, that's not a great attitude to have.

Post reply on HN