Monday, 19 September 2016

Agile 101: Broken Windows Theory

In the late 1960s, a university professor carried out a psychological experiment. He left two identical cars in two different neighbourhoods. One in a poor, high-crime neighbourhood in the Bronx, New York. The other one in a rich, quiet area of Palo Alto, California. Shortly after it was abandoned, the car in the Bronx started to have all its parts stolen. First the radio, then the tires, the mirrors, and anything of value. Yet the car abandoned in California remained undamaged. The study did not end there. When the car in the rich neighbourhood had been intact for a week, the researchers broke one of its windows. This escalated quickly, and soon afterwards the effect was the same as it had been in the Bronx. Theft and vandalism swiftly reduced the car to its bare bones in both neighbourhoods. A car with broken windows sends out a message of disrepair and negligence. It spreads the notion that anything goes. Every new act of vandalism reinforced and broadcast the idea that nobody was taking care of that car. That nobody cared.

A similar idea can be seen in the training of health professionals. If a patient or an elderly person has a stain, or gets dirty somehow, that person should be cleaned. Even if it’s only a little spot. If patients stay in that state, they will be less careful themselves in keeping clean. They will tend to feel that it doesn’t matter anymore, it’s already dirty. So their general state of hygiene, self-esteem, and thus health level will start to decline.

The results of this psychological study are applicable in many situations of our daily lives: from the care of our home to the maintenance of our car. But they’re also applicable to our jobs. For example, if you’re a programmer or a project manager, and you allow for a new version to be deployed. But you haven't had it sufficiently tested. Or if you leave that technical “debt” unpaid in the code now —because “we’re in a hurry.” You’d be broadcasting to the whole team the feeling that anything goes. That “it’s enough as it is” and that one can leave quality aside. Sooner or later the phone will ring with complaints from users. Soon we will see a lengthy queue of reported bugs in our queue.

When we apply this theory to software, it’s helpful to explain the term entropy. In physics, entropy is the level of disorder or randomness in a system. Say you see badly indented or commented code. Or a bad choice when naming a variable or some bad design. Fix it as soon as possible or schedule its correction for the near future. Take some sort of action to limit disorder or it will expand. It will create the feeling that any patch or quick fix is valid.

If some code (or thrown-together code) will make your system deteriorate quickly, impeccably written and designed software will have the opposite effect. It will make new programmers avoid breaking something so beautifully built. They will make an effort to put in place the best code they can write. Now you know: make your life and your project easier by fixing broken windows as soon as they appear.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).
Book on Scrum: Agile 101, Practical Project Management
Agile 101 - Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

No comments:

Post a Comment