Dragan Stepanović

Systems with high transaction cost will always revert back to big batches no matter how much we try to encourage individual actors to reduce the size of the batch.
Actors act rationally within a given set of constraints imposed by the system, so the intervention point must be at the system level, not on the individual level.

Building quality in and fast flow cannot happen without short feedback loops.
And prerequisites for short feedback loops are high flow efficiency and low inventory.

It’s more likely that a team will need to mob on an outage if they’re not mobbing during the development.

More collaboration dilutes roles, siloed skills, heroes culture, and variance in engagement.

Big Batches™ embed:

• more assumptions
• way more second-order, compounded assumptions as a product of first order-assumptions (A x B x C x … x N)
• carry all of these for a longer time

It’s not about:

• Continuous Integration
• Trunk Based Development
• Pair Programming
• Mob Programming
• Limiting WIP

An example is of transaction cost is how long it takes us to get enough confidence that our change didn’t break previous functionality.

an indication of a lack of mechanism to reduce the transaction cost.

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.