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
»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 WIP (as it’s almost always the case).
»Try with more aggressive timeouts, use circuit breakers and bulkheads.
»Reducing inventory accelerates the feedback, so THE way to build quality in is to reduce the inventory and thus shorten the feedback loop.
»Same scene in Berlin U-Bahn (metro) this morning.
»In systems with very short feedback loops there are almost no events. Everything seems to be boring. The longer the feedback loop, the more pressure builds up with time elapsed, the greater the sense of relief and achievement this produces on emotional level when the feedback loop is closed (marking an event that has just happened in the system). Ironically enough, watching for moments of relief and achievement says a lot about existence of events that are too big, which in turn reflects the existence of too long feedback loops.
»