Throw Out Before Add
Before adopting any new-style practice or tool, you must make room for it by discarding some or all of any previous organizational practices (or tech) in that area.
TODO: unlearning bad habits, per/re/ceived wisdom, etc.
- No one knows why you have to do a practice, but everyone does it
- Overall process just keeps accumulating more and more practices and habits
- You constantly have to lookup how to do a process so you can debate how to do it
- You’ve adopted the most painful portions from several processes, and lost any useful practices
A small, light-weight process which is constantly tuned and adjusted to fit the context in which you are living today
No wasted effort or investment in rituals that no longer have material benefit
Code base does not contain any dead code and does not contribute to technical debt
❑ Critical ✓ Helpful ❑ Experimental
Steps to first adopt this practice:
- We’ve all heard the term “technical debt” and many organizations have their fair share of it and it applies to practices as much as it applies to code resulting from those practices.
- This practice is simply prompting you to evaluate your practices and think specifically about anything you’d categorize as “that’s just the way we’ve always done that”
- Think deliberately about why you do something especially something that seems wasteful, time consumig or is particuarly disliked by the team.
- Change is tough for many of us and it’s a good idea to get your team thinking about change. Some elite teams have a mantra “get comfortable being uncomfortable.” While that may not be totally necessary, the idea has merit. Change is required for improvement and change can be uncomfortable.
- Once you’ve deliberately thought about your practices, determine what item you can forgo, even if just during an experiment with a new practice.
- Give the change reasonable time to measure actual results of the change and determine if this “intentional experiement” worked
- Frequently evaluate existing practices and remove obsolete practices (200pts)
- Evaluate existing practices and remove obsolete practices when adding a new practice (100pts)
- Consistently remove dead code from the codebase instead of commenting out or routing around (50pts)
- Implement a new practice without evaluating existing practices (-25pts)
- Keep doing unneeded former practices (e.g., estimates, time sheets) (-25pts)
- Gather irrelevant metrics (-50pts)
- Commenting out or routing around unused code instead of deleting it (no dead code removal) (-100pts)
What Does it Look like?
You replace existing practice and workflow with new ideas, you don’t add new practices in addition to the practices they should replace.
For instance, if you are currently using long-term, detailed estimates (as in waterfall and other plan-based approaches) you would not continue to use those with agile-style, short-term work decomposition; it’s one or the other.
If you have a weekly, team-wide status meeting, you’d replace that with the faster daily team sync.
For code, there’s a range of what “throw out” might mean. For code in progress, it might be as simple as delete the outdated code immediately. For a framework that’s been deployed and is in wide use, you’ll need to deprecate it: migrate to the newer replacement for future development, and schedule the old code’s maintenance and end-of-life appropriately.
Remove the old as you introduce the new
But in any case, it is vitally important to remove the old as you introduce the new in order to keep things manageable.
- Process keeps getting larger and more complicated
- Reporting the same thing different ways or to different systems
- A third-party reporting tool to roll up reports from multiple sources
How To Fail Spectacularly
Trying to shoe-horn an incremental, iterative approach into a rigid, naive, plan-based “traditional” infrastructure.
←Prev (Small Bites Always)(Version Control) Next→