The Carrot Works Better than the Stick

Are your policies really that bad? Possibly, but most often the real problem is good old human nature.  People don’t like change and don’t like to be told what to do. In most software development situations, the person designated as the SCM coordinator is also the person who is responsible for enforcement of SCM policy. You can’t always count on management for support, and there are heavy consequences for murder. Effective people skills were probably not a key requirement to get your current job, and they are certainly not a part of most computer science curriculums. Believe it or not, these kinds of skills aren’t just for the sales and marketing folks. This article gives some practical advice on how to get your team on the SCM policy bandwagon without having to carry a sidearm.

Calling in Heavy Artillery

The easiest way to get your team members to honor your software configuration management procedures is to have strong management support that stands behind you every inch of the way. That way, when people decide to ignore your procedures, you just make a quick phone call and instantaneously a threatening man in a dark overcoat pays a visit to the offending user and your problem is solved!  If this is your situation, you can stop reading right here. If not, you might want to read on. Let’s face it, management is too busy to do your dirty work, and many times project managers can be offenders themselves (at least concerning procedures that involve them). So when it comes to SCM policy enforcement, you’re usually on your own. This can be a lonely place.

Involve the Users from the Start

One of the best ways to get users to follow your procedures is to include them in the design of your process. When they have ownership of procedures they have to use, they will be much more willing to go along with them, not to mention simply remembering what they are. Remember that they are the ones who are going to be following the process in their day to day operations. It’s very important to understand how they do their work and what their preferences are, especially if you have never performed their jobs or tasks. They probably have some excellent ideas that would improve your procedures in ways you never considered.

In addition, it’s important to remember the goals of the procedures. If a user doesn’t follow them precisely, are the overall benefits of the policy being met?  Don’t get too tied up in detail if the end results are being accomplished. No one likes to be henpecked, and ownership once again plays an important role here.  If the user understands the why and has their own how, then leave them alone if the job is getting done as intended. This could also be an opportunity for the procedure to be improved. Maybe their method is truly better.

Be the Good Cop, the One that Helps Children Cross the Street

You will attract more bees with honey than you will with vinegar. Cliché?Perhaps, but it’s true.You can yell, threaten and generally try to bend people to your will, but this is not the best way to get things done. People might do what you want, but the results will be less than desirable, and you might find yourself having to repeatedly beat people up to keep them in line.

Engineers like to understand how things work.  I have found that if you explain why a procedure is formed the way it is they are generally much more willing to follow it. They need to know that it was not designed just to make their lives miserable. It is also important to point out how the process will benefit them, hopefully directly. If it does not benefit them at least indirectly, your policy needs an overhaul. A benefit could be as simple as reminding the user that the project success will reflect well on their contribution as individuals. If they can see how the procedure will truly benefit the project and ultimately their own success, they will be more willing to comply. As an example of this, I had a user that did not want to use our SCM tool to perform merges of branched file versions. He did not trust the tool and wanted to do the merges manually, a process that would have undoubtedly wasted a lot of time. I pointed out that mastering how to use the tool to perform merges would make him much more valuable for future employment. He agreed with that point and quickly learned how to use the tool.

Listen to the user’s concerns. It is easy to think that people do not want to follow the rules because they are spiteful, lazy, or just want to be difficult. In most cases it is not about you or your procedures, it’s about them. Maybe they had a bad experience in the past with another SCM person or a failed process improvement campaign. Possibly they are having problems outside of work or are simply overwhelmed with their workload. The best way to get to the bottom of their issues is to simply ask them what the problem is. If their concerns are centered on your procedures, make note of what they are and consider using them for improvement. If you disagree with what they have to say, bite your tongue. Never condemn their opinion or tell them that they are wrong. Instead, let them know that their input is important. If their concerns are not about your procedures, practice your best listening skills and pay attention to what they have to say without giving advice. Sometimes people just need to vent, and if you hear them out, they will be much more willing to see things from your side of the fence.

When All Else Fails

Even after you have truly employed some of the suggestions above, you might have a few rogue participants who just don’t want to cooperate. It is times like these where you might have to enlist the help of others in dealing with the issue.  Before you go to management, write down all of all the things that you have tried to handle the situation yourself. Make sure they understand what your concerns are and how it effects the project. Hopefully you have management that will give you the support you need in those situations. If not, document it, report it, and go home and fix yourself a drink. You did what you could – don’t let it bring you down.

One last-ditch measure that we use to deal with recurring problems with specific individuals is to announce the issue to the entire group. For example, we have a build procedure that requires all code be checked into the repository before a designated release time. If a developer can not meet this deadline, they must inform the software lead and the builder as soon as possible. If they don't check their code in without a valid reason and fail to inform anyone, an email will go out to the entire group stating that they held up the build and why. There’s nothing like a little public humiliation to get people to follow critical procedures.  No one wants to be the singled out for failure.

For more advice on general applications of how to use a positive approach, I suggest reading the books How to Win Friends and Influence People by Dale Carnegie and The Seven Habits of Highly Effective People by Stephen R. Covey.  Even if you have read these books or attended related seminars, I suggest revisiting the texts for review. They both offer timeless advice that will assist you with getting people to follow your process and make your job easier.  In the meantime, try to see things through other people’s eyes and change your approach. You might find that your heavy hand will lose a little weight from lack of use.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment