Software Delivery in Small Batches

Hello and welcome to Small Batches. I’m your host Adam Hawkins. In each episode I share a small batch of software delivery education. Topics include DevOps, Lean, continuous delivery, and conversations with industry leaders. Now lets begin today’s episode.
The through line between lean manufacturing and lean software delivery is scientific thinking. The lean perspective only sees opportunities for improving the current condition. These opportunities express themselves as challenges or objectives. These are "target conditions" in the lean lexicon.
Taiichi Ohno, the father of the production system, would issue challenges to his teams such as "OK, now do it with with two fewer people" or "reduce the batch size by half". The same concept applies to the daily work of delivering software: "reduce build time by five minutes", "decrease lead time by 25% percent", or "support 3x the traffic with the current hardware."
Achieving these target conditions requires scientific thinking and actions. Sure, it would be easy to "just start" and take it from there. Developers, myself included, are usually keen to open up an editor and start hacking away on code.
The wonderful Dr. Deming has something to say about that. His quote goes something like: "experience teaches nothing without theory". In other words, the practice means nothing without understanding why you’re doing it.
In typical Deming fashion he points to the problem and provides a solution. The solution is a simple acronym for a scientific feedback loop: PDCA for Plan, Do, Check, Act. PDCA’s power is that anyone can apply it from the C-suite company executives to frontline staff.
The p stands for plan.Plan means writing down your understanding of the current reality and the expected outcome. This simple act forces participants to clarify their mental model and explicitly state the assumptions about the current reality. Those assumptions predict the outcome. Plans without predictions cannot be checked, so the cycle cannot continue without them.
The D stands for Do. Now actually do the planned activities. Do not deviate. Follow through on the plan as best as your abilities. Deviations from the plan will impact results.
The C stands for Check. Interrogate the results against those in the plan step. Were the predictions correct? If so why? Were the predictions wrong, if so why? Did something completely unexpected happen, then why? This step reconciles the results with the earlier plan step, therefore generating new knowledge and understanding among the participants.
The A stands for Act. The checks drive actions. Is it time to repeat a new PDCA cycle with a few tweaks? How about abandoning the experiments because it failed? Perhaps, the outcome is so positive that it’s time to standardize a new approach.
The beauty here is that the process applies at any scale. Process improvements and the development of new products are all enhanced by applying scientific thinking guided the PDCA cycle.
Continually applying this simple cycle leads to developing the high velocity edge. It goes like this: organization set standards, teams apply kaizen (or improvements) guided by PDCA, successful improvements lead to increasingly higher standards.
Conversely, teams fall short by only focusing on PD-PD. Plan-Do, Plan-do, but never checking the expected outcomes. You an observe this in your own team and company by looking a new features that’s never checked against user metrics in production.
A short aside for interested listeners. Deming modified this from Walter Shewarts "PDSA" for Plan-do-Study-Act who he worked with early in his career. Deming took the concept to Japan where it was used in the manufacturing companies such as Toyota, then eventually wrapped up into lean. It may also be referred to as "The Deming Cycle". There’s a similar acronym: OODA for Observe-Orientate-Decide-Act that was popularized by the United States Air Force for teaching combat operations.
I want to wrap up I by sharing some implicit PDCA loops in my daily work of delivering software.
The first is the all important TDD feedback loop. Plan: write the test. Do: write the code. Check: tests pass? Act: Green tests: refactor, red tests: repeat. Ideally this cycle plays out hundreds, if not thousands, of times a day. Writing the test first is the plan that forces me to clarify my understanding of the architecture and the desired functionality. The TDD feedback loop is how I reconcile architecture and code.
The second is the continuous deployment feedback loop. Plan: commit a small change guided by the TDD feedback loop that delivers value in production as measured by production telemetry. Do: apply TDD, commit, and push to kick off the deployment pipeline. Check: deploy pipeline. Act? All green: plan next iteration. Deploy failed? Apply jidoka checks as early in the pipeline as possible and repeat. Metrics red? Plan test suite changes and repeat.
Alright, that’s all for this batch. Deming and PDCA is the tip of a larger iceberg. There are so many resources I’d like to share to help you continue learning.
The first is the Small Batches slack app. The app posts daily snippets of software delivery education on topics like PDCA, Deming, Lean, TDD and continuous deployment to your team’s slack channel.
The second is a bunch of links to further explore Deming, PDCA, Toyota, and kaizen, and the all important tool that is "A3 thinking".
Find links to all the above at SmallBatches.fm/69.
Well I hope to have you back again for the next episode. Until then, happy shipping!