Tool efficiency, where you don't want to swap tools every minute but rather use the same tool with one kind of job until the job is done, then move to the next tool for the next job.
Alignment, where in order to construct parts you need a greater whole prepared, like plumb lines or foundation stones.
Getting smaller parts done, does not mean smaller parts are useful in themselves.
I built a bonsai cultivation area, we burned all the wood at the same time. We didnt burn one, install it, then burn the next and install it. We burned all the wood, installed all the wood in sequence.
An example of the tradeoff described here that I seem to run into very frequently is when breaking down large stories: often times breaking them down small enough for developers to manage and finish in a single sprint means QA might need to test twice. Sometimes testing can be also broken down but that's not always the case given the current state of QA tools, processes, and skills.
> I need to be prepared to solve for X in “One X at a time”.
Very interesting thought.
Two wooden boards that need the exact same screws in the same places can be thought as one single thing, because you can streamline the process of picking up the screws and driving them in.
Two components of LEGO bricks, that need to be built in the exact same 5 steps with the exact same 10 bricks can be thought as the same thing, because you don’t need to search for these 10 bricks once, assemble them, and then search for them again.
Will keep that in mind when thinking about batches, thanks a lot!
super relevant. I recently got a huge PR to review, and I couldn’t fully explain why I wanted smaller batches of work. Really appreciate the articulation here :) thanks for sharing!
There are tons of examples like this.
Tool efficiency, where you don't want to swap tools every minute but rather use the same tool with one kind of job until the job is done, then move to the next tool for the next job.
Alignment, where in order to construct parts you need a greater whole prepared, like plumb lines or foundation stones.
Getting smaller parts done, does not mean smaller parts are useful in themselves.
I built a bonsai cultivation area, we burned all the wood at the same time. We didnt burn one, install it, then burn the next and install it. We burned all the wood, installed all the wood in sequence.
An example of the tradeoff described here that I seem to run into very frequently is when breaking down large stories: often times breaking them down small enough for developers to manage and finish in a single sprint means QA might need to test twice. Sometimes testing can be also broken down but that's not always the case given the current state of QA tools, processes, and skills.
> I need to be prepared to solve for X in “One X at a time”.
Very interesting thought.
Two wooden boards that need the exact same screws in the same places can be thought as one single thing, because you can streamline the process of picking up the screws and driving them in.
Two components of LEGO bricks, that need to be built in the exact same 5 steps with the exact same 10 bricks can be thought as the same thing, because you don’t need to search for these 10 bricks once, assemble them, and then search for them again.
Will keep that in mind when thinking about batches, thanks a lot!
Very good principle. Engage in fine grained iteration, but don't do it blindly. Got it!
super relevant. I recently got a huge PR to review, and I couldn’t fully explain why I wanted smaller batches of work. Really appreciate the articulation here :) thanks for sharing!