Dragan Stepanović

As the batch size goes up, the emotional investement in it goes up as well, since we’re investing more time in the given solution.
As we become more invested in the solution, the bias towards that solution becomes stronger and it’s less likely for other equal solution to surface.
It’s likely that we become defensive about it as well, just because of the emotional pain of a huge work that we would have to do in case of rework or a complete change of the solution.

Interested in how to implement Drum Buffer Rope from Theory of Constraints to product development teams?
Try out mob programming. It makes sure that the whole team will be running at the pace of its currently slowest skill (constraint), which is essential for:

Lead time = processing time + queue (feedback) time

If you didn’t feel at least a bit of pain when adding new functionality, implementing process or introducing a tool, most probably you already prematurely generalized. Empiricism assumes some pain because it’s based on learning, not speculation.

There’s a difference between:
“We’re not saying we’re not going to do this thing”
and
“We’re just saying we’re not going to do this thing now“.

Test execution time can tell you a lot about design of your service. If you have a bunch of domain logic in the parts of the service where it shouldn’t be (controllers, repositories, external gateways or any adapter of that sort), your tests have to spin up a mock MVC or embedded database or stub service in order to test it. The more logic you have in these parts of the app, the more tests you’ll have against them, the slower the test suite.

When faced with pressure, teams should cut the batch size instead of pulling in more stuff and increasing the WIP (as is most often the case).

Try with more aggressive timeouts, use circuit breakers and bulkheads.