In a Dutch article titled “Traffic is safer without rules” traffic expert Hans Monderman explained that the flow of traffic at an intersection can increase, while at the same time casualty rates decrease, when all traffic lights and road signs are removed. The reason is that, in a situation without rules or guidance, people feel compelled to take responsibility and to judge for themselves how to reach the other side safely and in one piece.
The cause of this paradox can be found in risk perception and false security. Remove the green traffic light (false security) and car drivers will not blindly go full throttle on the assumption that they have priority over everybody else. Wipe away the crosswalk and pedestrians will better watch out for any dangerous vehicles (increased risk perception). Monderman claimed that the number of accidents diminished, and traffic throughput increased, in all situations where this concept was introduced. The idea is called shared space, which entails that all participants in traffic are equal, and that they all have to watch out for each other. Nobody can assume priority over others.
I dare claim that the shared space principle also applies to software development practices. Rules on how code should be developed, how it should be tested, and how new versions are to be built and deployed, may not automatically lead to higher quality products. On the contrary, a documented test procedure that doesn’t take specific project characteristics into account can lead to false security among team members. And an official requirements specification process that is deliberately ignored by team members may actually help them to increase their risk perception, seeing problems more clearly because they know they have to watch out.
In most projects, existing rules have to be treated not as laws but as rules of thumb. They point people in a direction that is often a smart solution to a problem, but not always. Sometimes it is necessary to abolish rules precisely to prevent people from blindly following them. In some of the most successful projects I participated in, we ignored rules and made better decisions on the spot. By going around road blocks and ignoring traffic lights we were able to reach the other side of our timeboxes timely and safely.
I am usually a bit reserved when an unpleasant incident has occurred in a project and someone is calling out that new rules are necessary to prevent similar problems in the future. When I would do as they asked, I would be no different than the average bureaucrat planting new road signs at intersections for every potential danger that somebody has encountered earlier. Some call this approach the Precautionary Principle and it is an official policy in many governments, including the European Union. Basically it says that, when something might go wrong someday, simply make a new law to prevent it from happening, just in case. And I really don’t like that approach.
Some methodologies and frameworks, like the CMMI, seem to be based on the Precautionary Principle. They suggest adding process descriptions for all kinds of potential problems. Unfortunately, I never saw them suggesting that some processes may have to be removed to make things run better. This is quite understandable, of course: It is unlikely that you will hear politicians and traffic controllers admit that their rulemaking efforts are often in vain, and sometimes even counterproductive.
Fortunately, software development experts seem to be smarter nowadays. They are increasingly aware that no single methodology is appropriate. Ivar Jacobson, one of the founding fathers of the Unified Process, has admitted the same in a three-part article titled “Enough of Processes: Let’s do Practices”. No one should rely on rules devised by others who know nothing of the situation that you find yourself faced with in your own project. In general, you achieve the best results if you create your own rules on the spot, appropriate to the situation of the day. Three researchers who have studied agile software methods came to the same conclusion, claiming that the best way to implement agile processes is to do it your own way.
I have participated in Dutch traffic for almost 20 years, and I’ve never been involved in an accident with other people. That’s because I constantly watch all vehicles, cyclists and pedestrians around me, preferring my own judgment over what the traffic signals are saying. My spouse, on the other hand, failed his first driving test when he trusted a green traffic light and almost drove into a pedestrian who crossed the street while ignoring a red light. Since then he has learned to trust his own senses first, and the official rules second (if time permits).
(image by Ted Percival)
This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.
Twitter - 
Subscribe - 
Newsletter - 
LinkedIn - 
SlideShare
| Latest, greatest and favoritest posts: Scientific Case for Bottom-Up Rulemaking Managers Are Not Game Designers! The Three Phases of Creativity |
