I am reading the book called Lean Startup by Eric Rides and one particular idea resonated well with my recent experience.
I noticed a pressure coming from around me to lengthen our 3 week long sprints (if only we could add one more week we could complete more valuable complex stories) and/or lengthen our release by adding one more sprint (we need more compelling release content). While different arguments are used to justify these calls - its all boiling down to attempts to increase the size of our our "production batch".
By now my intuition strongly points me to keep the batch size small. I know it will help to keep the level of waste down. However in the heist of debate I sometimes look for ways to describe why the small batch size is important, in simple layman terms.
Here is the story from the book that I found helpful.
The guy placed the bet with his daughters that it will be faster to fold 100 letters, place them in envelopes, seal and affix a post stamp by doing one envelope at a time (small batch size of 1) vs. folding 100 letters, then stuff 100 letters in envelopes, then seal 100 envelops, then affix 100 stamps (batch size of 100). The guy won the bet as the girls didn't at first realize the increased cost of dealing with larger batch size (e.g. keeping a stack of 100 envelopes from falling to the floor) and the cost of making a mistake when it gets magnified by the size of the batch (e.g. incorrectly folded 100 letters that don't fit into envelope - all 100 have to be redone instead of just one).
I noticed a pressure coming from around me to lengthen our 3 week long sprints (if only we could add one more week we could complete more valuable complex stories) and/or lengthen our release by adding one more sprint (we need more compelling release content). While different arguments are used to justify these calls - its all boiling down to attempts to increase the size of our our "production batch".
By now my intuition strongly points me to keep the batch size small. I know it will help to keep the level of waste down. However in the heist of debate I sometimes look for ways to describe why the small batch size is important, in simple layman terms.
Here is the story from the book that I found helpful.
The guy placed the bet with his daughters that it will be faster to fold 100 letters, place them in envelopes, seal and affix a post stamp by doing one envelope at a time (small batch size of 1) vs. folding 100 letters, then stuff 100 letters in envelopes, then seal 100 envelops, then affix 100 stamps (batch size of 100). The guy won the bet as the girls didn't at first realize the increased cost of dealing with larger batch size (e.g. keeping a stack of 100 envelopes from falling to the floor) and the cost of making a mistake when it gets magnified by the size of the batch (e.g. incorrectly folded 100 letters that don't fit into envelope - all 100 have to be redone instead of just one).
Well I have to disagree with you on that one. History (and by that I mean Frederik Taylor, Henry Ford and the assembly line) has already demonstrated that doing one simple thing at a time in batches is done a lot quicker than context switching to achieve a complex task.
ReplyDeleteIt all comes down to putting a good process in place, which in the case of your envelopes could be simply achieved by doing a POC on just one envelope to verify the process (avoid the wrongly folded letters).
So I call BS on that example!
But otherwise I agree with you, since developing software is the exact opposite of an assembly line (every single piece of software is actually unique when you think of it), it's better to consider each new feature as a prototype, therefore it should be kept as small as possible in order to be able to validate it as soon as possible!