Don’t mistake the lack of your pet solution as the problem itself

• “The problem is: we need more automated testing.”
• “The problem is: our documentation is out of date.”
• “The problem is: we don’t have a cohesive sprint goal.”

Those aren’t problems. They’re possible solutions to whatever the actual problems are.

The book Thinking In Systems says to start with the history when defining a problem:

Starting with history discourages the common and distracting tendency we all have to define a problem not by the system’s actual behavior, but by the lack of our favorite solution.

Listen to any discussion, in your family or a committee meeting at work or among the pundits in the media, and watch people leap to solutions, usually solutions in “predict, control, or impose your will” mode, without having paid any attention to what the system is doing and why it’s doing it.

Donella H. Meadows, Thinking In Systems

So what’s the history of the problem? If you think you need a cohesive sprint goal, then why? What has been happening that makes you say that? How did that start happening? If you change nothing, what will happen over time? And what’s working well, which you need to preserve?

Start with the history before you look at solutions, and never mistake the lack of your pet solution as the problem itself.