Always make several small, successive changes rather than one larger one. This idea applies to implementing code, scheduling team work, changing the team, and changing the process. “Never bite off more than you can chew,” that is, always maintain a short success horizon.
✓ Critical ❑ Helpful ❑ Experimental
Small Bites Always applies to everything; changes in your product code base, changes in your process, changes in your organization. This adoption experiment looks at Small Bites Always applied to changes in your product. The same pattern applies to changes in process and in your organization.
Steps to first adopt this habit, using the example of coding:
Questions to answer and debate
Small Bites Always leverages Col. John Boyd’s Observe, Orient, Decide, Act (OODA) loop.
First, this is a loop. As you take Small Bites Always you move through the loop. Each pass should focus on providing value at the end of the Act. This allows you to recognize revenue sooner than big bang releases.
Second, it includes interactions with the environment. This feedback prevents an echo chamber and mindlessly moving to the next small bite. You have the chance to Observe the results of the previous Orient/Decide/Act and improve your current Orient/Decide/Act process. This reduces uncertainty as you are always comparing results to reality. It also builds reliability as the looping allows repetitive tasks to be automated.
Third, the Orient step allows you to evaluate if you’re doing the right thing. Doing the wrong thing “righter” simply digs the hole you’re in deeper and faster. Developers can focus on creating new features/value.
Fourth, taking Small Bites Always allows you to quickly change directions when your context changes and new business opportunities appear. As each loop delivers value, there is no waste when it becomes beneficial to pivot and pursue a new path.
Working in small bites reduces risk. You get user feedback sooner. Instead of major releases where misconceptions and mistakes are solidified like concrete creating brittle code, each pass through the loop provides information about the value delivered. Code changes if needed occur close in time to the code creation when the thinking supporting the code is still fresh in the developers’ minds.
As consultants say, “it depends.” It depends on the activity at hand and your particular context.
In general activities include coding, creating features, holding meetings, and improving processes.
In code, developers make small changes, with frequent check-ins to version control and automatic builds/testing, using the TracerBullets development style. These should occur in hours, one or maybe two.
For features, aim for finishing in a day or two at most.
With system architecture, you want to consider a project as a series of smaller, lightly and loosely coupled projects that work together, instead of one giant, tangled, monolithic risk-bomb. Again, this should be a matter of days, not weeks.
When changing your process and work flow to a new approach, start with small pilot teams, each of which takes small steps, changing one thing at a time. Spread from the pilot teams out to the general audience slowly, over time. Process changes may take a week or so to get rolling.
You may have other important activities. In general, you need to know about how long these activities take, then find ways to break up the activity so you can do less each looping and shorten the time between starting and verifying the results.
A small step can succeed or fail. If it fails, you’ve learned something, and you can more easily correct and try again. If it succeeds, you have a success! And more importantly, you have a success within a short time frame—a short success horizon. This has huge psychological benefits as you quickly move from success to success, with small, easily managed failures.
Context matters. “Good enough” for web development is different than good enough for medical device software, which in turn is different than the regulations governing financial software or nuclear power plants. There is no “one size fits all.” But there is general guidance.
Obviously, you must avoid the one giant, tangled, monolithic risk-bomb. But more subtly, you want to avoid the “business as usual” risk bombs that may not be giant, but are still too large. Large enough that when they blow up, they cause not only immediate damage but a fair amount of collateral damage as well.
You do this by reducing the amount of work in progress and the size of the work elements. This provides the following benefits:
The smallest possible bite is no bite at all.1
“Simplicity—the art of maximizing the amount of work not done—is essential.”
Beware taking on all the things you “know” you need to do—don’t blindly start doing them. Start on the list, perhaps, but only in small pieces. Small pieces ensures that you get feedback as you go, not only on the specific task itself, but also on the ongoing need for the later tasks you haven’t gotten to yet.
Feedback advises both current development and the priority and needs of future development.
And in most cases, the future needs you anticipate never arrives. Not the way you thought.
The Extreme Programming folks call this the YAGNI principle, for “You Ain’t Gonna Need It,” and they are usually correct. Small Bites Always ensures any speculative investment in the future remains inexpensive and less risky.
←Prev (Remove Proxies to People)(Answers From Experiments) Next→
The Agile Manifesto Principles, online at http://agilemanifesto.org/principles.html. ↩
Follow @growsmethod in the Fediverse, or subscribe to our mailing list:
Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.