GROWS logo

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,

Pain Points

  • Chaos
  • Constantly changing things, but without understanding what fixed what, or what didn’t
  • Not knowing why something succeeded or failed
  • “Programming by Coincidence”

Benefits

  • Traceability from experiment to results
  • Ability to replicate success and avoid failures: you can do more of the stuff that works

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.

If these unexpected surprises comes from other groups (sales, support, etc), involve your ProductOwner. They have the big picture perspective that helps them effectively triage “urgent” requests. There’s always a balance between responsiveness and getting work done. Your team needs to decide where you need to be on the sliding scale.

Warning Signs

  • Don’t know what works and what doesn’t.
  • Trying to adopt a whole suite of practices at once (e.g., RUP, Scrum, XP, SAFe)
  • No one knows what’s expected of them
  • People can’t keep up with changes
  • Contradictory feedback: you did the right thing, but people are mad. So you did the wrong thing, but with the right motivation.

How To Fail Spectacularly

  • Ignoring feedback from a change: 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“)
  • Claiming “My teams are great at multitasking!” or even worse,
  • “I’m great at multitasking!”

No, 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.


(Small Bites Always) Next→

Follow @growsmethod on Twitter, 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.