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.
Although just because that is the best way now with the current tools, I believe Toyota would be looking for ways to, continually, alleviate the bottleneck and move *closer* to single piece flow. You have to invent new methods and tools along the way
Agreed. We should always be aware of progress on both scales--in their case making cars & getting better at making cars. Similar to Tidy First's features for cash flow & design for options.
I feel like this applies to the project I'm working on. For contractual and compliance reasons we have a lot of "paperwork" around releasing application versions to staging and production environments. It means trying to release very small changes has a huge overhead, and thereby a tendency to group things together in larger releases.
The better solution here would probably be to reduce the friction caused by the paperwork. It is not something I can do as an individual, but I could probably invest some time in convincing those who can make it happen.
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!
Oh, tunnel vision is real. Today, I'm looking at an old project that I never completed, and man, so many bad decisions. lol. I should have taken waaaay more breaks when I was writing this.
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.
Although just because that is the best way now with the current tools, I believe Toyota would be looking for ways to, continually, alleviate the bottleneck and move *closer* to single piece flow. You have to invent new methods and tools along the way
Agreed. We should always be aware of progress on both scales--in their case making cars & getting better at making cars. Similar to Tidy First's features for cash flow & design for options.
I feel like this applies to the project I'm working on. For contractual and compliance reasons we have a lot of "paperwork" around releasing application versions to staging and production environments. It means trying to release very small changes has a huge overhead, and thereby a tendency to group things together in larger releases.
The better solution here would probably be to reduce the friction caused by the paperwork. It is not something I can do as an individual, but I could probably invest some time in convincing those who can make it happen.
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.
What is this "QA" of which you speak? Why does code that is done need to be tested? 😉
> 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!
We are always trading off latency, throughput, & learning (people forget about the learning part).
Very good principle. Engage in fine grained iteration, but don't do it blindly. Got it!
Easy to say. Hard to do in the moment.
Oh, tunnel vision is real. Today, I'm looking at an old project that I never completed, and man, so many bad decisions. lol. I should have taken waaaay more breaks when I was writing this.
This made me smile widely and feel happy about this post, although I am not sure why :D This is hilarious and inspiring! :) Thank you
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!