Only change one thing at a time, whether it’s creating a new habit, debugging code, communications/messaging, or environment related. You can more easily detect the isolated feedback from that change if you alter only one thing at a time.
Don’t start the next new thing until you’ve completed adopting the last new thing
✓ Critical ❑ Helpful ❑ Experimental
First steps to create this habit:
Again, the important aspect is to be clear (or at least, as clear as possible) on what changes affect which outcomes. In a complex system, you won’t be able to isolate all effects or identify all causes, but you will be able to observe changes to the whole system.
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.
Improving process: have a hypothesis about how the change will impact feature delivery. Use AnswersFromExperiments to create and test your theory. Do the answers from your experiment support your thinking? If not, make another change and run another experiment.
Changes to one area create unexpected results somewhere else: that’s good information to track down; there’s a connection 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 meeting2 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 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.
Studies have repeatedly shown that humans are not good at multitasking. In fact, it costs a great deal of productivity. For example, see these studies at the University of Michigan,4 for more information.
And only change one thing at a time.
see The Pragmatic Programmer [(Thomas & Hunt, 2020)] ↩
See TimeBox for more. ↩
See SmallStableTeams for more. ↩
www.umich.edu/~bcalab/multitasking.html] or the books Pragmatic Thinking & Learning [(Hunt, 2008)] and Flow: The Psychology of Optimal Experience [(Csikszentmihalyi, 1991) ↩
Follow @growsmethod in the Fediverse, or subscribe to our mailing list:
Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.