Finishing what you start makes teams more productive and predictable
1–10 of 165 posts
Re: Finishing what you start makes teams more productive and predictable
#2This is a fun experiment along the same lines: https://m.youtube.com/watch?v=Dr67i5SdXiM
The result surprised me even though I know intellectually I should have expected it.
Re: Finishing what you start makes teams more productive and predictable
#3This article is very thorough, but makes one fairly big mistake: it assumes there is low variability in task size.
This could be a reasonable assumption if you're very good at adjusting scope, but I would be skeptical unless you have measured it and have the numbers to prove that in practise, tasks indeed turn out to be roughly the same size (±20 % or whatever -- I don't know the exact threshold.)
Why this matters is that under cheap context switches and even modest task size variability, it's -- surprisingly -- a performant queuing policy to pre-empt the currently processing task to handle every incoming task. The intuition behind this is that if a task is still processing when a new one comes in, it's likely to be a "big" task, and it's worth letting small tasks ahead in line. Reduces mean response time.
Of course, this could all be moot anyway because context switches are certainly not cheap for software engineers. I just thought I should mention it for nuance. Rules of thumb only get you so far, at some point you have to more accurately model the situation and simulate.
Re: Finishing what you start makes teams more productive and predictable
#4If you liked this post, the book Making Work Visible is a great expansion on these topics. Making Work Visible: Exposing Time Theft to Optimize Work & Flow https://www.amazon.com/dp/B09L3B9YK1/ref=cm_sw_r_apan_AX66TB...
Re: Finishing what you start makes teams more productive and predictable
#5Fact 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 each other much. Individuals pay for context switches, but teams can assign different tasks to different team members.
Or maybe I don't understand the point the article is trying to make here. It seems really obfuscated with metaphors involving burgers.
Re: Finishing what you start makes teams more productive and predictable
#6This article is very thorough, but makes one fairly big mistake: it assumes there is low variability in task size. This could be a reasonable assumption if you're very good at adjusting scope, but I would be skeptical unless you have measured it and have the numbers to prove that in practise, tasks indeed turn out to be roughly the same size (±20 % or whatever -- I don't know the exact threshold.) Why this matters is…
Speaking to the task size point, I’ve found (via leading a number of teams and training many more team leads) it’s possible to decompose any task into smaller tasks so that every task is within a small constant factor of each other.
If it seems impossible for a given task, maybe because it’s particularly complex or has lots of unknowns, then no problem, simply create a “spike” task to research or prototype whatever you need to in order to decompose the big task into appropriately sized chunks (for your team’s idea of appropriate).
See you end up with a bunch of tasks that are all roughly the same size or are spikes of similar size, and you can have the very nice predictability and productivity that the author is speaking about.
(btw, I also agree that contact switches are never cheap for software developers, so it’s better to let them finish whatever they’re working on whenever it’s not too unreasonable to allow it)
Re: Finishing what you start makes teams more productive and predictable
#7Article 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 becomes a matter of discipline, not process. This is important because it allows management to stop throwing good money after bad on features that the business decided that they don't actually want anymore.
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.
Re: Finishing what you start makes teams more productive and predictable
#8Diagrams are utterly meaningless.
Author apparently has never understod 'assembly line' nor knows how such things work.
Of course my analogy doesnt map to code delivery, but neither does his burgers.
Worthless
Re: Finishing what you start makes teams more productive and predictable
#9This article is very thorough, but makes one fairly big mistake: it assumes there is low variability in task size. This could be a reasonable assumption if you're very good at adjusting scope, but I would be skeptical unless you have measured it and have the numbers to prove that in practise, tasks indeed turn out to be roughly the same size (±20 % or whatever -- I don't know the exact threshold.) Why this matters is…
This assumes that tasks can be defined as small and large ahead of starting them which goes back to a similar mistake that you pointed out - our estimates need to be true and have high confidence. Estimates for tasks have high variance and some of them will turn out to be inordinately complex, though not clear at first. Second one is that it assumes all tasks are of same priority and the utility of all tasks are equal.
Both of them are not true for software tasks. The assumptions behind the queueing policy are not true here.
Re: Finishing what you start makes teams more productive and predictable
#10This article is very thorough, but makes one fairly big mistake: it assumes there is low variability in task size. This could be a reasonable assumption if you're very good at adjusting scope, but I would be skeptical unless you have measured it and have the numbers to prove that in practise, tasks indeed turn out to be roughly the same size (±20 % or whatever -- I don't know the exact threshold.) Why this matters is…
Speaking to the task size point, I’ve found (via leading a number of teams and training many more team leads) it’s possible to decompose any task into smaller tasks so that every task is within a small constant factor of each other. If it seems impossible for a given task, maybe because it’s particularly complex or has lots of unknowns, then no problem, simply create a “spike” task to research or prototype whatever y…
This has been true in my personal research too. When projects are sufficiently decomposed, a "ticket" about implementing part of a project is generally speaking within the same order of magnitude.
However, this article is not talking about "tickets" but rather about the entire project. So that you may or may not be able to break the project down into roughly-constant chunks is irrelevant for the arguments of this article.
What matters is the size of the full project that you need to see through from start to finish in order to get business value out of your work.
(Yes, you can usually break down the project into smaller chunks too, so that you see business value quicker. However, these are rarely of constant size anymore, in my experience.)