Deploying Lightweight Processes First Position Statement Neil B. Harrison Avaya Communication 11900 N. Pecos st., room 30F-31 Denver, CO 80234 303-538-1541 nbharrison@avaya.com Suppose you have a bag of lightweight processes that you want to deploy in an organization. How do you do so? Let me present some ideas, which are partly based on experience, and partly based on study, but have less experience to back them up. First, it's important to understand that the processes of an organization are in most cases its ceremonies. In other words, every organization has a culture. The culture is deeply entwined with the values of the organization. The values tend to shape the roles in the organization, and the values and roles shape the processes. So the culture generally believes that the processes (ceremonies) will appease its Gods (fulfill the values). A quick example: An organization values software quality. They believe that design reviews improve software quality. Therefore, they do design reviews religiously. (Note that they might not understand what "software quality" means. That doesn't matter. They know it's good, and that they have to have design reviews to have good software.) So here's the problem: Any process change that eliminates the rituals of the organization will make people fear the wrath of their Gods. You are in effect, challenging their values. They will vigorously fight to preserve their processes, even in the face of logical arguments and real data. So significant process changes imply culture changes as well. How does one go about doing it? Here are some ways. 1. (Israel in the Wilderness) One can introduce processes to a small group, and let it spread gradually. After the old generation dies out (retires or moves on), the new generation will have new values and new processes. Remember the Israelites wandered in the Sinai desert for 40 years until the apostate generation died out. I don't recommend this approach. Besides, I'm not old enough to have tried it. But one can see instances of success in the industry. For example, it took twenty or so years for OO to become mainstream (yes, it was introduced in the late 60's and early 70's.) 2. A crisis can cause a culture to change. A crisis can cause people to look at their values, roles, and rituals critically. Note that a crisis is by definition, acute. The chronic so-called "software crisis" isn't a crisis at all. Nothing that lasts over 20 years is a crisis. Maybe this is the "Noah" approach. The Flood. Now THAT was a crisis. 2.a. You can take advantage of a real crisis that happens. People become open to listen when they are threatened by a crisis. You emerge as a leader proposing ways to do things differently, so we don't end up in this mess again... You have to be careful, though, since a crisis can also cause people to hunker down in their holes. Find people willing to try something new. 2.b. In the absence of a crisis, you can create one. The best way I know is to hold up a mirror to the organization so they can see themselves (The Emporer has no clothes.) Jim Coplien and I have had considerable success with organizational studies in which the participants identify the roles in the organization, and enact their processes. They gain considerable insight through the exercise, we provide feedback, and even compare them to other organizations. In several cases, organizations have made dramatic organizational and process changes. 3. (Martin Luther) One other approach is to set up a separate team with the new processes, and as they are successful, the main organization will see their success, and (hopefully) want to try it themselves. It is not guaranteed that the main organization will embrace the new processes, though. They can find reasons to explain away the success of the pioneer organization.