I cannot have a fast feedback if I don’t have small batches.
But, I could have a slow feedback even if I have small batches.
That’s the case when WIP is too high, which causes queueing in the system, which then delays the feedback.
So, here’s the thing.
»I’m aware that many people like async way of working, which usually comes with remote work, but it’s actually causing your company’s WIP to skyrocket.
»The problem, which is often overlooked, with not slicing the work is incurring all the opportunity cost of not doing something else more valuable while working on the less valuable parts and thus missing a chance to increase the throughput of the value.
»Big batches lock the capacity of a team for a longer time, which renders the team unresponsive for a longer time.
»Test-Driven Development = Continuously check/test
Continuous Integration = Continuously integrate code
Pair/Mob Programming = Continuously review and integrate ideas
Refactoring = Continously make (small) changes
only when we don’t express the intent, but keep the code implicit and low level. So, it’s not really about mocks, but about the design.
»High transaction cost incentivizes for big batches. And lack of availability, causing long waiting times, drives the transaction cost up. I.e. the more something is rare to find, the more valuable it’s perceived as.
»one line of code change that is reviewed immediately.
»but an inevitable consequence of a desire to drastically tighten the feedback loop to review and integrate the code and ideas.
»