Sometimes, when engaged in lean-flow trainings or discussions, I will use my "church meeting" example to explain U-Curve optimization for finding optimal batch size (eg: transaction cost, holding cost). Thought I'd share.
It goes like this.
After a church social (or any other meeting, in particular the one at the moment), we usually volunteer to put away the folding chairs. The big, strapping, football jock will (in an attempt to impress Mary) grab 6 of them under each arm and hold them out like an iron cross as he toddles toward the closet.
He can press two-times his weight, after all.
Next phase of Operation Folding Chair: waddle with a half dozen chairs under each arm, over towards the hallway connecting the rooms. In the process: knocking over the nice cupcake lady, spilling 2 glasses of purple punch on the new laminate floor and denting the drywall. Our guy eventually makes it to the storeroom like a Category 5 hurricane. Once in the storeroom, he proceeds to drop 4 of the folding chairs (now that Mary can't see him), knocking the previously organized chairs over and tearing one of the seat covers. He might have even strained his wrist. Coach ain't gonna be happy.
On his next trip he tries 4 and finally settles on 3.
The holding costs of keeping the chairs in the gossip chamber a few more minutes is nothing.
The transaction costs go up with the batch size and the frequency and total number of trips to the storeroom.
At this point we can explain how we this applies to things like: code check-in batch sizes (replace big-strapping jock with over confident joe programmer), number of #userstories in an #agile #devops release, and #kanban #wip limits. We don't want to check in code for evert single character we write but we probably don't want to wait for more than a few hours, either.
We can continue to learn that you figure it out your batch sizes in precisely the same way:
Trial and error and continuous #measurement.
Go find your optimal batch size! But please, tell the Church Lady you're sorry if she gets knocked over in the process.
It goes like this.
After a church social (or any other meeting, in particular the one at the moment), we usually volunteer to put away the folding chairs. The big, strapping, football jock will (in an attempt to impress Mary) grab 6 of them under each arm and hold them out like an iron cross as he toddles toward the closet.
He can press two-times his weight, after all.
Next phase of Operation Folding Chair: waddle with a half dozen chairs under each arm, over towards the hallway connecting the rooms. In the process: knocking over the nice cupcake lady, spilling 2 glasses of purple punch on the new laminate floor and denting the drywall. Our guy eventually makes it to the storeroom like a Category 5 hurricane. Once in the storeroom, he proceeds to drop 4 of the folding chairs (now that Mary can't see him), knocking the previously organized chairs over and tearing one of the seat covers. He might have even strained his wrist. Coach ain't gonna be happy.
On his next trip he tries 4 and finally settles on 3.
The holding costs of keeping the chairs in the gossip chamber a few more minutes is nothing.
The transaction costs go up with the batch size and the frequency and total number of trips to the storeroom.
At this point we can explain how we this applies to things like: code check-in batch sizes (replace big-strapping jock with over confident joe programmer), number of #userstories in an #agile #devops release, and #kanban #wip limits. We don't want to check in code for evert single character we write but we probably don't want to wait for more than a few hours, either.
We can continue to learn that you figure it out your batch sizes in precisely the same way:
Trial and error and continuous #measurement.
Go find your optimal batch size! But please, tell the Church Lady you're sorry if she gets knocked over in the process.