One Thing at a Time
Only change one thing at a time, whether it’s a new practice, debugging code, communications/messaging, or culture-related. You can more easily detect the isolated feedback from that change if you alter only one thing at a time.
- Everyone works very hard, but results are chaotic. Nothing works and no one knows why
- Conflated results; can’t tell which experiment was responsible for which results
- Build is broken, no one knows who broke it
- Long-term feature branches that all need painful merging
- Individuals constantly change things, but without understanding what fixed what, or what didn’t
- “Programming by Coincidence” is common (see The Pragmatic Programmer)
- Full traceability from experiment to concrete results
- Prevent chaos
- Ability to replicate success and avoid failures: you can do more of the stuff that works
- Prevent “Programming by Coincidence”
- Simplifies troubleshooting and debugging
- Faster identification and correction of build issues
- Team adopts one new practice at a time, getting feedback from each (50pts)
- Team usually adopts one new practice at a time, but sometimes does two or more related practices (25pts)
- Making a change results in clear feedback to confirm or reject the change (25pts)
- Version control change log reveals you changed more than one thing (-10pts)
- Team adopts multiple new practices at once (-50pts)
❑ Critical ✓ Helpful ❑ Experimental
Steps to first adopt this practice:
- Spend some time to really think about priorities of work and what item is most important to deliver next.
- Think about how long it will take to complete the item and if it’s longer than a few days, can it be split into mulitple components to deliver?
- Once the team has determined this is the most important thing that needs to be done and it can be done in a relatively short time frame, ask a question: Can everything else wait for a couple days while we focus on completeing this?
- If this is truly the most important thing, then that’s what the team should focus on and commit to, if not, start over at step 1 of Setup.
- Teams commit to completing their priority item and stay focused on the capability until it is completed. If an interruption occurs, it’s up to the entire team to fight those interruptions to allow them to finish their priority work.
- How did you do?
- Were interruptions managed well?
- Is this an item for discussion in continuous review?
What Does it Look like?
Although this seems fairly obvious, here are a few hints and tips:
Debugging code: first, prove the bug exists, preferably with a test written in code. Change one thing that you think will fix it, and run the test again.
Debugging process: similarly, don’t make a change unless you have some feedback showing the problem. Change one thing, and re-evaluate the feedback.
Changes to one area results in unexpected results somewhere else: that’s good information to track down; there’s a connection there you weren’t aware of. But now, how to handle this unexpected, unplanned line of investigation?
When you’re doing “just one thing,” and the unexpected pops up, how should you handle it? If it’s directly related to the “one thing” you’re working on, it’s probably best to investigate it now. If it can wait, defer it until later.
If it’s not clear, have a short, time-boxed meeting to determine a course of action. At the end of the alloted time, take some action, even if that means flipping a coin or rolling a dice to make a decision. Action is still preferable to inaction. Also, any investigation and/or correction doesn’t have to involve the entire team.
When this sort of thing happens regularly, then it’s a sign that you need to spend more regularly-scheduled time understanding the code base better.
- Don’t know what works and what doesn’t.
- Trying to adopt a whole suite of practices at once (e.g., GROWS, RUP, Scrum, XP, SAFe, etc.)
- People can’t keep up with numerous changes
- No one knows what’s expected of them because of multiple new changes to process/workflow
How To Fail Spectacularly
- Ignoring feedback from a change (e.g., soliciting feedback from the team, and then ignoring it)
- Changing everything all at once
- Changing things without letting everyone know
- Not changing anything
- Not changing something because of a previous investment (see the “sunk cost fallacy“)
- Thinking you can change more than one thing at a time by claiming “My teams are great at multitasking!” or even worse,
- “I’m great at multitasking!”
Studies have repeatedly shown people are not good at multitasking at all and in fact it costs them a great deal of productivity. See, for example, these studies, or the books Pragmatic Thinking & Learning by Andy Hunt and Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi for more information. And only change one thing at a time.
(Small Bites Always) Next→