Sunday, August 14, 2005

Ritual as the Basis for Project Harmony in a "Means" Vs "Ends" World "In rites at large, it is always better to be too simple rather than too lavish. In funeral rites, it is more important to have the real sentiment of sorrow than minute attention to observances." -- Confucius in the Analects I was struck recently by the similarity of the role of ritual in Confucian philosophy and the role of ritual in Agile projects. The system of thought put forth by Confucius tries to create a world where people can live together in harmony without resorting to uncivilized behaviour. You think I am stretching here? We'll see... Confucius was motivated by his times. He lived in what was called the Warring States Period. Battling warlords made life difficult for your average person. For simplicity, this era will play the waterfall methodology "big process up front" role in my analogy :-) Deeply concerned about creating a better world in which to live, Confucius proposed ritual as a key civilizing influence. So does Agile. What you say? We are programmers, we don't need no stinkin' rituals! Hold on now. Don't get your editor in undo mode. Let's consider just what ritual is: ritual can be thought of as respect for the the deepest sense of proper way of doing things. Isn't that a fine Agile principle? On a project you could could consider ritual the pattern of disciplined behavior which governs each moment in the life of a project. Now does that sound bad? Without the bonding of ritual there isn't order. Why? Because people learn proper relationships through ritual. Ritual promotes harmony by showing everyone how they should act and interact without using a heavy hand. He who governs best governs least. Using ritual everything just sort of happens and fits together. In a world where everyone is looking to kill each other you can see how you might want ritual to coordinate social situations. Modern software projects aren't so different at their base. Ritual is all around us. Shaking hands is a ritual. You know when it is done badly or done without enthusiasm. Shaking hands is automatic in social situations. Someone who doesn't shake hands would seem rude. Without the ritual of shaking hands however we would be confused about how to greet each other. It's not the shaking of hands that is important, what is important is we know how to greet each other in a harmonious way. Tipping is a ritual. Parking is a ritual. Driving in traffic is governed by ritual. Saying god bless you to a sneeze is part of ritual. Violating most of these rituals is not the same as breaking a law. You don't have to tip. You don't have to say god bless you when someone sneezes. You don't have to shake hands. You can sneak into a parking space even if someone was there before you. You can cut someone off in traffic. But when you violate these rituals you are making it harder for people to live and work together. Yet slavishly following an etiquette book would seem weird as well. Ritual is the wrapper on chaos. You can go cowboy in your process. You can go bondage and discipline too. Ritual provides a middle way by showing people how to act without having to have a centralized coordinator. This is Agile path as well. Ritual is not just the unthinking adherence to form we see on so many projects. Confucius is quite clear that for rituals to work they must come from genuine feeling and awareness. Only then will they work. Social engineers are the masters of inauthentic ritual. So are politicians. Both can cause enormous damage. Rituals are all over the place in Agile. Look at the many practices of XP. Scrum, for example, requires morning meetings that say how long they should be, who should attend, who can talk, and what questions are to be asked. And so on. I won't go into details, they are there for everyone to read. If a project adopted both Scrum and XP you would see how most of your working life would become governed by ritual. That's not a bad thing. To the contrary, it's the backbone and the strength of the approaches. The rituals of an Agile methodology tell everyone how all the parts of a project interact and relate, they define right relationships, they define right roles, they define right practice, and they define their harmonious interaction. Having interviewed hundreds of people I can say very few people have any idea at all of how to develop software in a team. Disaster is almost inevitable when you toss all these people together onto a project. Most people are lost without the well defined rituals of an Agile project. Ritual exists in waterfall projects too, but waterfall is mainly about ends and not means. An Agile project is mainly about means, not ends. What do I mean by that? Means versus ends has been a running theme through philosophy for thousands of years. Do the ends justify the means? As long as you attain your end goal do the means you use to get it really matter? Or should you never use immoral means, regardless of the ends? Both can be easy positions to take. The messy middle, however, is where most of us live. In software means vs ends is more a matter of methodology. We think of waterfall projects as heavy on process. A heavy process seems seems like means, but it's not. A waterfall project tries to guarantee an end, defined by a specification, by trying to define everything up front. It's the end that matters and the actual means of producing the software are secondary. The thought is if you are rigourous enough then you can think of everything and that guarantees attaining the end. If you've been on a project you know exactly how concentrating on ends happens. Countless times I've heard from a manager something very similar to the following: we need to deliver in 3 months. I want to know how we are going to get there. How many resources do we need? What can go wrong? How are we going to handle every contigency? We can't scew this up. The future of the company is resting on it. What's our plan? Fear drives the need to be certain about guaranteeing an end. The only way most people can think of to reach an end is by up front planning. Decades ago W. Edwards Deming, the Sage King of quality, had a different vision. Deming taught: * Quality is conformance to process rather than conformance to specification. * Cease dependence on quality control to achieve quality, instead focus on quality assurance throughout the lifecycle. This is the approach Agile follows. If you use the right means, then the result will be correct. You don't have to focus on the ends. Do the right things in the right way with the right people and the result will be what you want. You don't have to plan for every eventually up front. You can adapt and problem solve as you go. Confucius also thought like Deming. Confucius wanted a civilized society. He didn't advocate passing a law saying "be civilized." He knew that would not work. To reach his desired end he concentrated on means. Confucius advocated standardizing the means through which a society interacted, that is its rituals, knowing that would almost invisibly produce a civilized society. There would be no heavy hand forcing people to be civilized. It would naturally happen through the weight of tradition. Confucius was very agile, in his own way. comment[] 8:58:07 PM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 12:43:33 PM.