Recognizing Signals #scrum #xp #agile #lifehack

Signals come from everywhere, they are tell us something about our environment. Whether it’s hot or cold, wet or dry, and painful or pleasant. These signals are rarely binary, there are gradients in the signals. And we have signals with which we aren’t dealing at that moment, which we’ll call noise in that instance. Feedback is also a signal, perhaps it causes a painful sensation or it causes a pleasant sensation. Whatever the sensation it causes that sensation too is another signal which we can choose to regard as noise.

In Test Driven Development we give a higher priority to creating controls which alert us with signals we consider negative, such as a unit test failing or a build failing, and race to improve this. Yet in our personal contacts we tend to give a higher priority to positive signals, and disregard or become angry about negative signals such as feedback. These are the signals we can use to improve ourselves, and in my experience there are few controls which alert us to this signal, it can be difficult to recognize them as information rather than as criticism. Jerome Groopman M.D. states that a doctor – like everybody else – can become “increasingly convinced of the truth of his misjudgment, developing a psychological commitment to it. He becomes wedded to his distorted conclusion.”^[1] Once the signal becomes corrupted it is difficult to interpret, and “[a] signal is only as good as your interpretation of it.”^[3]

Misinterpretation of valid signals can lead to extreme difficulties.
All it takes to solve a misinterpretation problem is insightful understanding.

In SCRUM and XP we use our Daily Stand Up, Paired Programming/Negotiation and Retrospective to help improve the functioning of the team, and as a free and open space to give feedback for the benefit of the team and team members. This creates feedback loops in which the results of the feedback become controls which can be used to verify the resulting actions. In our personal contacts there is not as much space for these feedback loops to be created, there is no daily SCRUM or pair situation, and there is certainly no retrospective.

“When faced with a result that doesn’t go according to plan, a series of perfectly effective short-term tactics are used until the desired outcome is achieved.”^[2] In development we sometimes choose to go for short term wins, this work well with inert systems which do not have many links in the process chain. For larger systems we usually ask ourselves: “[H]ow structurally sound are those solutions?”^[2] This is where heuristics can made life much easier, little shortcuts which can enable a developer to develop code more effectively, efficiently and reliably. Similar heuristics can be used in the personal context.

Groopman gives a good example: “During my training, I met a cardiologist who had a deserved reputation as one of the best in his field, not only a storehouse of knowledge but also a clinician with excellent judgment. He kept a log of all the mistakes he knew he had made over the decades, and at times revisited this compendium when trying to figure out a particularly difficult case. He was characterized by many of his colleagues as eccentric, an obsessive oddball. Only later did I realize his implicit message to us was to admit our mistakes to ourselves, then analyze them, and keep them accessible at all times if we wanted to be stellar clinicians.”^[1]

Read more articles on Agile, SCRUM or XP…

Unlike Groopman’s cardiologist I believe that achievements should be registered with failures, both are signals and information. Thomas Edison said: “I didn’t find a way to make a light bulb, I found a thousand ways how not to make one.” He documented the ways that didn’t work, just like the ways that did work. Edison rightly remarks that both need to be known. In the past peer review journals contained the failures, it was considered important to know what not to do, now they seem mostly to contain the successes. There is a reason that George Santayana quote: “Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it.” is drilled into the minds of children when learning history, one can learn from one’s mistakes and successes only by registering them. These patterns can then be turned into you own shortcuts for life.

This can be the end, as it answers the question of recognizing signals. The issue is that it merely the answer to how to recognize the signals. What Sinek and Groopman call the WHAT and HOW, or Smart calls “The content of thought” and “The structure of thought.” It doesn’t address the WHY or “The nature of thought.” There are heuristics that don’t sit right, like having a 4GB memory footprint, or robbing a Peter to pay Paul as a shortcut to wealth. How structurally sound are those heuristics?