Picture a large dark cave with a small flashlight: you need to always take small steps, within the limited range of the flashlight. That’s a good image of this concept. Always make several small, successive changes rather than one larger one whether you’re implementing code, scheduling stories/features, changing the team, or the process.
Small achievable goals are less risky, and more likely to succeed.
Small steps provide feedback faster, so you have less time to go wrong and more time to hit the target you wanted.
A small step in the wrong direction won’t set you back as far as a larger investment would have.
You can switch directions more quickly by not having large, long-term liabilities / commitments, which makes you much more responsive and nimble.
Smaller, incremental movement is an excellent risk reduction strategy.
A lot of business literature likes to use the example of ”How to Eat an Elephant,” emphasizing that the only way to eat an elephant is one bite at a time. However, that misses the larger issue: an elephant is generally too big to kill, prepare, and store. A nice cow, or perhaps a chicken would probably be a far better and more realistic choice. So not only do you need to take small bites, the whole meal needs to be of an appropriate scale to the environment.
And instead of the slow consumption of a large animal, a better metaphor is probably considering changing the sea (a.k.a, a “sea change”). You could pump out the whole ocean first, and then pump in the new water, but that approach is prohibitively expensive and risky. Bleeding in a little of the new water at a time, while siphoning off the old water will take longer, but it has the benefit of being actually possible.
In the real world:
When changing your process and workflow 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.
Similarly, in code, developers made small changes, with frequent check-ins to version control, using a Tracer Bullet style of development.
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.
Beware taking on all the things you “know” you need to do—don’t blindly start doing them. Start on the list, perhaps, but 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 many (most?) cases, the future needs you anticipate never arrive. 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.
Moving faster than you can see the ground ahead of you (using the flashlight analogy from above).
Staying only where you can see (i.e., never moving, never growing beyond 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 almost never ends well. The concept of small bites says to commit fully to a short-term, known goal with good feedback. Remember the large dark cave with a small flashlight: you need to always take small steps, within the limited range of the flashlight.