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 or technical practices in that area. Similar to closet space, teams and organizations have a finite amount of overhead. To do something new, you have to give up something old.
- 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 benefit
- Code base does not contain any dead code and does not contribute to technical debt
- Frequently evaluate existing practices and remove obsolete practices (200pts)
- Evaluate existing practices and remove obsolete practices prior to adding a new practice (100pts)
- Consistently remove dead code from the code base 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)
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- “Technical debt” applies to practices as much as it applies to code
- 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 consuming, or is particularly disliked by the team
- Change is tough for many of us, but stability only comes from constant change. Some elite teams have a mantra “get comfortable being uncomfortable.” While that may be a little excessive, it’s not wrong
- Once you’ve deliberately thought about your practices, determine what items 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 experiment” worked
What Does it Look like?
You replace existing practice and work flow 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, or the more continuous style of a mob programming approach.
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
- You create a Software Process team to keep track of your process
- 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)(Automate Build Pipelines) Next→