Noise is something that we usually associate with a sound, especially a strong or unexpected one. Truly, it's much more than that, and it can be felt in different forms and shapes.
It can be as simple as just mentioned, a louder sound that emerges above the others. A car or motorcycle engine, an ambulance. It can also be associated with interference in communications. Loss of packages during transmission, or a voice on the phone line that you simply can't understand. It can manifest visually, as when someone scratches a drawing on the traffic signal, making it difficult or impossible for drivers to decode.
All of these manifestations are considered by most of us as harmful, bad for health, bothersome. As a result, we have laws that prescribe how much noise is acceptable and where the limit is.
Paradoxically, though, most of us need noise. We just need it!
Why? Because we are accustomed to it. Kids, dogs, cats, TV, radio, neighbors, birds chirping or cars going by outside. The truth is, most of us feel strange if nothing is producing any noise, whether it's "good" noise or not. Finding balance regarding noise is as difficult balancing many other things in our lives. We need to decide what type of noise is good for us, and what types to get rid of. Neighbors shouting typically is not a good noise. On the other hand, a phone call from an old friend (which can generate a lot of noise) is fantastic!
Have an open mind to experiment and experience different approaches to the noise in your life, and don't forget to analyze the consequences.
And before moving on to the way all this relates to Scrum, I would like to thank my colleague Hugo Santos, who literally rang the bell. He woke me up to the positive consequences of my constant attempts at noise removal — the evil kind, I mean.
As a ScrumMaster, I'm a guy (but not the only person) who's in charge of impediments removal. Impediments come from:
- External dependencies
- Bad planning
- Unpredictable technical problems
- Unpredictable absenteeism
- Bad relationships
- Lack of motivation
- Legacy systems
- People not talking the same language
On first approach, ScrumMasters focus on the impediment itself, struggling to remove it or at least to minimize its impact.
Next, beyond the problem itself, they try to identify the root cause and start working on it. Typically, and if the team has independence, they talk about it during a retrospective and establish a plan to eliminate it.
I always do these two things; there is no way escape from them. (In some cases, starting with the second approach means you get the first as a prize for your persistence.) So I struggle on a daily basis to avoid the noise that an impediment can generate. And when it's impossible to avoid, I fight to eliminate it as soon as I can. It's like a hemorrhage: The sooner you stop it, the sooner you get better.
But don't forget the beginning of this article. As important as it is to identify and remove evil noise patterns, you also have to practice the extremely difficult ability to leave some kinds of noise untouched, because it's actually good. For example, let's say the project leader (someone outside the team) appears at the daily stand-up. This can be bad. But if his appearance is to congratulate the team about the last release result, it can be awesome. If the ScrumMaster simply expelled him from the meeting, the team would lose something important, a big motivator.
Noise can also provide an excellent means of judging the size of the impediment you have to deal with. Note that if you look at the impediment itself, it remains the same. But if you listen to the "radio carpet," you'll realize how much the snowball is growing. That's noise at its best!
I'd like to identify and share with you some of noise-removal techniques I usually use. Remember, this is not an easy task. You will need to be brave every day.
- The problem is something you have to solve: Just face it!
- Doubt is something you need to clarify: Just ask, as many times you need to.
- Rumor is just that, until it becomes a fact: Investigate, and until it's a fact, don't give it too much importance.
- The problem requires some digging: Discover and act on the root cause.
- A cloud (not the IT kind) is something gray, and we like blue skies: Clean it!
A real-life example
A recursive nightmare of our project is the performance tests. Some of their characteristics are:
- Many manual tasks
- Executed on an environment not controlled by the project team
- Out-of-date tools
- Enviroment shared for many tasks, with a busy time-sharing calendar
As you can see, there are several variables influencing the final result. Therefore, the performance tests often get into trouble. At worst, they started to be the "guilty guy." So I had to solve this problem, a recursive one. I did it in a simple way, establishing commandments as discussed with the team:
- Performance tests are mandatory.
- Performance tests include some manual tasks that need to be accomplished.
- Performance tests are as simple as they are well planned and prepared.
- Problems with the environment escalate quickly.
- When you run a plan like this, be the first to be there, because you need inspect and adapt your own plan.
These performance tests had generated a whole lot of "noise" that no one liked. But that noise also helped us gauge the number and scale of the impediments. With the help of the team, I used my arsenal of noise-removal techniques. And I can state now that our plan worked out, and the team could move on to the next challenge.