Whatever principles I try to live & work by, I try to apply them just as much & as often as possible. Yesterday, though, a lawn chair taught me a valuable lesson about the principle of flow.
The Principle of Flow states that, all else being equal, smaller batches of value more frequently is worth more than that same value delivered in fewer, larger batches. You’ll find the Principle of Flow working every corner of Extreme Programming—software design, planning, testing, integration, deployment, conversations—every corner.
Lawn Chairs
Back to the lawn chairs & my obsession about principles. I was getting 2 chairs out of the box in which they shipped. First I said, “I’ll get grab one first because that will be easier.” Followed quickly by, “Hey, this is the Principle of Flow. Aren’t I a good boy to be applying my principles throughout my life? Talk about integrity!”
Followed by 10 minutes of thumping & swearing. Every time I moved the top chair, the bottom chair would shift. The shift deformed the cardboard box (which I couldn’t destroy), causing the top chair to be more firmly stuck. (At this point a diagram would likely help, but that seems overkill for the eventual conclusion—trust me that moving one chair caused that chair, indirectly, to be more stuck.)
Principled action can be extremely expensive if you’re dumb about it.
Eventually I thought, “Well, I wonder if I can shift the bottom chair?” One tug & both chairs popped right out.
More obscenities. Okay, what just went on here? What was wrong with my principles or my interpretation of my principles?
One [X] At A Time
The problem is that tricky phrase, “…all else being equal…”. In this case, 1 chair at a time wasn’t at all equal to 2 chairs at a time. 1 chair at a time caused nearly infinite friction, infinite at least from the perspective of my aching back. 2 chairs at a time had no friction, just the (light) weight of the chairs.
The bigger batch reduced effort. That may be the rare case. Incentives abound to thoughtlessly increase batch size. I don’t want to make a habit of increasing batch sizes when I encounter trouble. But I need to be aware of the twin possibilities of increasing & decreasing batch size. I need to be prepared to solve for X in “One X at a time”.
(The other lesson is about hubris. Just because I have some principles that seem to work in most situations, I don’t have it all figured out. I need to observe, pay attention, & think.)
There are tons of examples like this.
Tool efficiency, where you don't want to swap tools every minute but rather use the same tool with one kind of job until the job is done, then move to the next tool for the next job.
Alignment, where in order to construct parts you need a greater whole prepared, like plumb lines or foundation stones.
Getting smaller parts done, does not mean smaller parts are useful in themselves.
I built a bonsai cultivation area, we burned all the wood at the same time. We didnt burn one, install it, then burn the next and install it. We burned all the wood, installed all the wood in sequence.
An example of the tradeoff described here that I seem to run into very frequently is when breaking down large stories: often times breaking them down small enough for developers to manage and finish in a single sprint means QA might need to test twice. Sometimes testing can be also broken down but that's not always the case given the current state of QA tools, processes, and skills.