Small Bites Always

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.

Pain Points

  • Angry users and customers
  • Large, broad initiatives never seem to actually finish
  • Projects take far longer than you have available and then fail anyway
  • Feedback arrives too late because releases are huge and occur far apart in time
  • Large investments in consultants or tools or infrastructure don’t deliver results


  • Small steps provide feedback faster, so you have more chances to correct and your the target
  • A small step in the wrong direction does not set you back as far as a larger step would
  • You are more likely to succeed using small achievable goals with a short success horizon
  • You can switch directions more quickly by having small, short-term liabilities/commitments, which makes you much more responsive and nimble
  • Smaller, incremental movement reduces risk


  • Product releases are very frequent with a small number of new features, optimizations, and fixes in each (Major Boost)
  • Experiments have fast Feedback, are Inexpensive, No permissions required, Easy to perform and understand (FINE, See AnswersFromExperiments) (Significant Boost)
  • Team membership changes are infrequent and small (Boost)
  • Process and work flow changes are small and easily understood (Boost)
  • Process and work flow changes are large and complicated (Setback)
  • Experiments are expensive, cumbersome, require approval, or manual reporting (Significant Setback)
  • Team membership changes are frequent and/or large (Significant Setback)
  • Product releases only happen quarterly or longer and contain a huge number of new features and fixes (Disaster)


✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

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:


  1. Adopt TracerBullets
  2. Pick a number of upcoming work items (five or six, no more than ten)


  1. For the first work item selected, decompose the item into discrete very small components. Your goal is to decompose this item into components that will only take a few hours work each. Focus on each discrete component at a time and progress through many small, specific steps. Each step will only be considered done if all tests pass and it is checked in to the mainline.
  2. Once you have decomposed at least two days worth of work, start coding and collaborating with others.
  3. During the development process, frequently check your code into the version control system your organization uses. See VersionControl.
  4. Continue this iterative process of decomposition and development until you have delivered the work items selected.

Evaluate Feedback

Questions to answer and debate

  1. Were you able to develop a rhythm of continuous delivery?
  2. What worked well? What needs improvement?
  3. Did you find your ability to deliver value changed?
  4. Did this process help you mitigate or avoid risk in the development process?

What Does it Look Like?

The OODA Loop

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.

Risk Management

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.

How long should “small bites” take?

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:

  • quickly delivering value
  • the ability to pivot without wasted effort
  • reducing uncertainty
  • improving reliability
  • developers focusing on what they love

The smallest possible bite

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.

Warning Signs

  • Every proof-of-concept (pilot) is a “success”. Nothing is never seriously challenged and **nothing is learned
  • All projects are large, all teams are large, every meeting is large, everything is a high-ceremony big deal, and you justify it all by crying “Enterprise!
  • No working software can be generated in less than a quarter or worse
  • You have an intricately detailed five-year plan (and it’s even worse if you believe it!)

How To Fail Spectacularly

  • Moving faster than you can get feedback
  • Never taking any “bites” (i.e., never moving, never growing beyond your small current context)
  • Having a “Change Control Board.” Trying to control change is the wrong approach; instead you want something like a Change Infusion Board. Change is a good thing. You want it to be pervasive, in a constant flow of small quantities, not a single, large, officially blessed and debated event
  • Constantly committing yourself and your team to the unknown. Agreeing to deadlines and even whole budgets for undefined, unknown work. That’s a risk bomb, and never ends well. The concept of small bites says to commit fully to a short-term, known goal with good feedback.

  ←Prev (Remove Proxies to People)(Answers From Experiments) Next→

  1. The Agile Manifesto Principles, online at

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.