Overcoming Resistance to Change

Throughout most of my career I have been applying techniques from Industrial Psychology to help large software development teams improve their productivity and, more importantly, stop making serious mistakes. I am usually called in when there have been a few disasters and the project is in risk of failing. Sometimes it does fail and there is nothing that I, nor anyone else, can do about it. Fortunately, there are also times when process improvement can play a vital role in helping to bring a project to success. Overcoming resistance to change is the first skill that anyone in the process improvement field must understand and learn to use as an effective tool. Read on if the coming year is your time to help bring about effective change, for the better, in your organization.

Please keep those process guys away from me...
I admit that I have really learned to dislike many of my colleagues who are in the profession of applying software process improvement in business settings. Too often I find these folks have no clue as to what really works in the real world. They are too preoccupied with their metrics (used to sell their methodologies) and often have rather light technical backgrounds. In my career I have been happiest when no one wants to listen to my expertise on process improvement and I get to sit in the back, as a systems engineer or SA and tweek Unix kernels (what fun!). But then somebody really screws up a software release and I am back to being in charge of CM and Release Management.

A good rule of thumb, is that the bigger the disaster, the more that the organization will be ready for change. This is not an accident. Kurt Lewin proposed one of the classic models for change back in 1951 which consisted of three simple stages: Unfreeze - Move -Refreeze. Watts Humphrey, among others, talks about this model and most of us have a very hard time applying it in practice. Most of us feel frustrated in organizations that have problems and we may even start to believe that nothing will ever change for the better. That may be true and some organizations, just like in biology, some organisms will die from their own organizational diseases. Yet many more will find the catalyst for making things better. Are you up for being the Change Agent in your company?

The first step is in realizing that everything around you is part of an ecosystem (this is a classic Organizational Development model for understanding what is happening). There are ecosystems in nature that are very complex and also seem destined for extinction. When I am working in a group, I often listen to the "rhythm" around me. I sometimes see managers using intimidation to silence others around them and workers withholding important information because they've learned that knowledge is power. My colleagues will start complaining about how awful an organization is and how impossible it is to get anything done. To me the "rhythm" is my best weapon in understanding how I can add value and bring about lasting change. I view these times as my opportunity to understand the ecosystem and get creative in developing just enough process to help avoid making mistakes.

Engineering the process
As a process engineer it is my job to define the tasks, roles and responsibilities and a set of tests to confirm compliance with the agreed upon process that is implemented to improve efficiency and/or avoid mistakes. Frederick Taylor did this with his time and motion studies in developing his Scientific Management. This work and the many subsequent studies have inspired me throughout my career as a "process guy" working in software engineering. Instead of looking at the efficiency of handling a shovel, I look for ways to avoid mistakes when a release of complex software is about to be deployed that will potentially move millions of dollars around the world. In one of my jobs I got to use these skills to help get the software into production that was used on the floor of the New York Stock Exchange. In one incident, the wrong version of a shell script literally stopped the world economy for one hour when the New York Stock Exchange crashed. Our source code management process was so strong that we found the source of the error in five minutes flat (the bug was still online) and prevented another disaster from occurring. We had a good process with excellent forensics. We knew exactly what was supposed to be online and when an SA accidentally overwrote the wrong scripts we were able to quickly respond and resolve the situation. We had a solid and repeatable process in place.

Don't be fooled by the labels...
Whether you are plowing through the SEI's CMMi, ISO 9000-3 or getting your green belt in six sigma, all of these methodologies have a lot of extra steps that are not always practical in the real world. The Agile folks, with their XP evangelists, are no better in that they take a "one size fits all" approach to many of their practices. My view is to develop "just enough process to get the job done and avoid mistakes." I will study all of the process models and, shamelessly steal their best practices, and apply the best of them to each of my unique situations. I will often not recommend that the same practices be used across an entire organization. Some groups have problems and need more structures in areas where others do not. Too much process seems silly to those who have to follow the steps day in and day out and frankly I can't blame them. A good process model addresses issues that are relevant to the organization and seem fair. Over the coming year we will be working to discuss more aspects of overcoming resistance to change and I hope that you will write to me to share your best practices and greatest challenges. It's the beginning of the calendar year and a perfect time to start improving your own software development process.

Where do you begin?
The first step is in identifying your goals and objectives. Solving problems that your company does not really have is frankly a waste of time. Creating consensus and realizing that understanding your own quirky corporate "ecosystem" is absolutely a key part of your job. Listening for the "rhythm" of your organization will provide you with some excellent tools as you define just enough process to help your organization avoid mistakes and become more efficient. Welcome to "just in time process improvement"!

Bob Aiello is a Senior Editor for CM Crossroads and an Associate Director at a major financial services firm in NYC, where he has company wide responsibility for Software Configuration and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra University.