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.
Pain Points
- 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
Benefits
- 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
Assessment
- Frequently evaluate existing habits and remove obsolete habits (Signficant Boost)
- Evaluate existing habits and remove obsolete habits prior to adding a new habit (Boost)
- Consistently remove dead code from the code base instead of commenting out or routing around (Boost)
- Implement a new habit without evaluating existing habits (Setback)
- Keep doing unneeded former habits (e.g., estimates, time sheets) (Setback)
- Gather irrelevant metrics (Significant Setback)
- Commenting out or routing around unused code instead of deleting it (no dead code removal) (Disaster)
Application
✓ Critical ❑ Helpful ❑ Experimental
Adoption Experiment
Steps to first adopt this habit:
Setup
- “Technical debt” applies to habits and practices as much as it applies to code
- Evaluate your habits 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
Trial
- For this trial, we are going to ask you to review your habits. This might be tough as it will require change on your part which may bring some discomfort. This can be tough for many of us, but stability only comes from constant change. To explain, perfect practice makes perfect or said another way, it is getting comfortable and confident with change that will lead to stability. 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 habits, determine what items you can forgo, even if just during an experiment with a new habit
- Pick something you can actually measure to gauge results. This can be anything from fewer missed or dropped tasks to more thumbs up at code reviews. The only thing that matters is that it is something real and tangible that can be measured.
Evaluate Feedback
- Give the change reasonable time to measure actual results and determine if this “intentional experiment” worked
What Does it Look like?
You replace existing habit and work flow with new ideas; you don’t add new habits in addition to the habits they should replace.
For instance, if you are currently using long-term, detailed estimates (as in waterfall and other heavy plan-based approaches lacking fast feedback) 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.
Warning Signs
- 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 (One Thing at a Time)(Automate Build Pipelines) Next→
