Double Dog Dare
Let us consider two different paradoxes: the Montana Paradox and Cobb’s Paradox. First, the Montana Paradox. It is widely believed by traffic professionals, law enforcement agencies, and bodies of government that reducing speed and enforcing speed limits saves lives. However, is this really the reason behind the results, or are there more commercial aspects to this belief? After all, there is a whole industry built around enforcement of traffic laws. The National Highway Traffic Safety Administration has been promoting the notion that speed kills. But when the State of Montana removed speed limits, fatalities and overall automobile accidents went down. Later, when the federal government issued guidelines and financial incentives to reduce speed limits and enforce them, fatalities and overall automobile accidents doubled.
Now let us consider Cobb’s Paradox, my very favorite since I named it in our report “Unfinished Voyages,” published in 1996. At CHAOS University (1995), Martin Cobb, then Treasury Board of Canada Secretariat, Ottawa, Canada, said, "We know why projects fail, and we know how to prevent their failure – so why do they still fail?" Since the naming of Cobb’s Paradox, a whole industry has been built around this notion that we can prevent software projects from failing by slowing them down and enforcing process guidelines. Software firms selling costly enterprise project and portfolio management tools flourish by offering a panacea to success. But to this very day, success has been elusive. These tools have been no more effective than speed limits in Montana.
Hans Monderman, traffic engineer, dared the transportation planners in the Netherlands to reduce traffic lights and signs at busy intersections. He called his approach “shared space.” Shared space means everyone is responsible for the safety of everyone else. In other words, we all share the same space, so let’s be courteous to each other. His radical approach increased traffic flow and safety. Ken Schwaber and Jeff Sutherland also came up with the radical idea of shared space when they invented Scrum. With Scrum, the team is responsible for making the product work. The team self-manages without a lot of government and industry regulations.
Most agile and Scrum projects are small, which means they fit into shared space. Small software projects are the only area in which we have seen real improvement during the last 20 years that we have been studying project outcomes. In all other size segments project failures have increased or remained steady. More importantly, for all other segments the return on value has almost been eliminated.
There are very few systems or programs that cannot be broken down into small projects with usable deliverables. Let me be clear about this point: A deliverable is not a requirements document or a list of specifications. If the deliverable is not fully usable software that can be used at the end of a project, it is not a small project. We know why projects fail; it’s because they do not fit into shared space. We know how to prevent their failure by making sure they fit into shared space. If you do not know how to get your projects to fit into shared space, call us, because we do. I double dog dare you.