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, or changing the process. Don’t bite off more than you can chew.
- No initiative ever finishes
- Projects take far longer than you have available—years in some cases—and then fail anyway
- Feedback takes too long because releases are so huge and far apart
- Making large investments in consultants or tools or infrastructure with no piloting or immediate results
- Small achievable goals are more likely to succeed
- Small steps provide feedback faster, so you have less time to go wrong and more time to hit the target
- A small step in the wrong direction won’t set you back as far as a larger one 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 reduces risk
- Product releases are very frequent with a small number of new features and fixes each (100pts)
- Experiments have fast Feedback, are Inexpensive, No permissions required, Easy to perform and understand (FINE) (100pts)
- Team membership changes are infrequent and small (50pts)
- Process and workflow changes are small and easily understood (25pts)
- Process and workflow changes are large and complicated (-50pts)
- Experiments are expensive, cumbersome, require approval, or manual reporting (-100pts)
- Product releases contain a huge number of new features and fixes and only happen quarterly or longer (-100pts)
- Team membership changes are frequent and/or large (-150pts)
❑ Critical ✓ Helpful ❑ Experimental
Steps to first adopt this practice:
- Similar to the adoption experiment in the one thing at a time practice, start by ensuring you understand your priorities and you know what is the most imprtant thing to deliver next.
- Once you are in agreement on the next priority, if you have any trending history or a “track record” established to help you get a good huristic of the approximate amount of work it would take to complete the item, use that information to determine if this capability could be completed within a few days time.
- If you don’t have any historical information available to help you gauge the size of the effort, or if there are some differences that would make you suspect this differs from other past efforts, do a deep dive on the work by walking through how you plan to tackle the work and what tasks and depdendencies are required to deliver the capability.
- Your goal is to break work items down to chunks that take no more than three days to complete.
- How did you do? What requires adjustment?
- It’s much easier to manage expectations of multiple stakeholders competing for the team’s time when you are constantly delivering value and releasing small capabilities and also builds trust with users in the process.
What Does it Look like?
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.
Avoid the 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.
- 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
- 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 (One Thing at a Time)(Throw Out Before Add) Next→