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.
Pain Points
- 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
Benefits
- 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
- 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
Assessment
- 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 work flow changes are small and easily understood (25pts)
- Process and work flow 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)
Application
✓ Critical ❑ Helpful ❑ Experimental
Adoption Experiment
Steps to first adopt this habit:
Setup
- Adopt TracerBullets
- Pick a number of upcoming work items (approximately 10 to 15 items) that will be candidates for an upcoming Timebox
Trial
- For the work item selected, start decomposing the item into discrete, smaller components. Your goal is to decompose this item into components that are smaller than a day’s work so you can focus one discrete components at a time and progress through many small specific changes rather than build and deliver a monolithic application
- Once you have decomposed at least two days worth of work (possibly around a handful of elements) you can begin coding and collaborating with others on delivery.
- During the development process, frequently check your code into the version control system your organization uses. See VersionControl
- Continue this iterative process of decomposition and development until you have delivered the work items selected
Evaluate Feedback
Questions to answer and debate
- Were you able to develop a rhythm of continuous delivery?
- What worked well? What needs improvement?
- Did you find your ability to deliver value changed?
- Did this process help you mitigate or avoid risk in the development process?
What Does it Look like?
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.
Similarly, in code, developers make 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.
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
- 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→
