One Thing at a Time

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

Pain Points

  • 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 common1

Benefits

  • 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

Assessment

  • Team works on one new habit at a time, getting feedback from each (Significant Boost)
  • Team usually adopts one new habit at a time, but sometimes does two or more related practices (Boost)
  • When fixing a bug, you fix one thing at a time (Boost)
  • Making a change results in clear feedback to confirm or reject the change (Boost)
  • Version control change log reveals you changed more than one thing (Setback)
  • Team adopts multiple new habits at once (Disaster)

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

First steps to create this habit:

Setup

  1. Choose a new habit or technique for the team to try. Review AgreeToTry.

Trial

  1. Go through an adoption experiment for that new habit.
  2. Don’t start adopting any other new habit until you’ve evaluated feedback from the new habit adoption experiment.

Evaluate Feedback

  1. Once you’ve gotten feedback from the new habit or technique, consider if you have enough data yet. If not, continue the trial, getting feedback, and tuning your approach.
  2. As team members get a clear understanding of what’s being affected and what isn’t, you can move on to the next “one thing”

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.

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.

  • 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.

Warning Signs

  • You try to multitask
  • People try to work on multiple teams at once3
  • Misunderstood Vision leaves people scattering in many different directions at once
  • Don’t know what works and what doesn’t.
  • Trying to adopt a whole suite of practices or habits 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

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.

How To Fail Spectacularly

  • Taking on too large a work task and reporting that it’s “in process” for days, weeks, or months at a time.
  • 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!”

And only change one thing at a time.

  (Throw Out Before Add) Next→

  1. see The Pragmatic Programmer [(Thomas & Hunt, 2020)] ↩

  2. See TimeBox for more. ↩

  3. See SmallStableTeams for more. ↩

  4. www.umich.edu/~bcalab/multitasking.html] or the books Pragmatic Thinking & Learning [(Hunt, 2008)] and Flow: The Psychology of Optimal Experience [(Csikszentmihalyi, 1991) ↩

Find Out More...

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.