Remember the last time you faced a big failure. How difficult was it to acknowledge it and how long did that process take? As you know, sometimes we can go whole life without being willing or ready to face it.
»
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).
»