It's so easy to get comfortable in your everyday surroundings, but you should know by now that change is often right around the corner. In a larger sized organization, change can be difficult to implement with minimal disruptions, but it can be done, and to the benefit of everyone.
No one likes change. Regardless of what development organization I've been a part of, that statement continues to be true – no one likes change. Revision control systems were created for just this reason: users were clamouring, “if we need change, let's at least track it”. Entire frameworks like CMMI have been designed expressly to encourage systems administrators to track change. But how can we encourage change, knowing the resistance we'll start off with?
In my case, I wanted to introduce a code review tool (ReviewBoard), and process to the software development teams. Build engineering is about more than just compiling code and assembling installers, it's also about software engineering: helping developers improve their development practices. In my organization, much like many others, the issue was resistance to change.
No One Likes Change
The first thing to understand is our truism, no one likes change. Developers are comfortable in their routine, comfortable with their processes and their tools; even if things can be better, the key is comfort – people are already used to what they're used to. Introducing change means minimizing the fallout, minimizing the pain associated with a change in environment, in tools. We have to understand the user, and anticipate their pain points. We need to go out of our way to ensure our change is making people's lives better.
Fear of the unknown leads most people to avoid the unknown, and the same is true of developers. People fear extra work, different work, and the tracking of work, all things a code review process can highlight. In the case of my code review tool, what appeared to be a fear of extra work, due to code reviews, boiled down to a fear of reprisals for writing bad code. But in both worries, you can hear the same thing: how will this change affect me?
Preparing Your Environment for Change
Caterpillars morph into butterflies, but first they have a cocoon. The same is true when engineering change, you need a cocoon. Process and tool changes need to happen in a controlled environment, one we, as Build Engineers can control. In my case, I turned to my sympathetic user; you know the type: loves writing software, gung-ho about possibilities, and willing to be a guinea pig. I approached him in the hopes he'd help be my guinea pig, help me learn all about the tools I was proposing and its affect on my team.
The next key in preparing your environment involves understanding your customer's viewpoint. Application developers and their management represent our internal customers, those customers need us to minimize the associated cost of implementing our new tool. Cost can be measured in time, in impact, and even in perceived change; All this can be most easily understood by getting in the mind of our customer, the developer.
Whether you're proposing a new build system, revision control system, or a code-review tool, the key is to understand how it will affect your developers. How can developers utilize our new tools and processes with minimum interruption to their existing workflow? While introducing ReviewBoard, I tried to make the review process as seamless as possible, by attempting to have code reviews created on commit to the revision control system. This stems from my belief that developers spend the majority of their time with two tools: their editor/IDE of choice, and their revision control system client. By integrating ReviewBoard with Subversion, ensuring a review could be created as part of the commit process, I helped reduce the potential workflow change, something that helped gain the sympathy of developers towards the new tool.
Reproducing Success through Sales
The next step is the sales call; A good build engineer is also a salesperson, one with a captive internal audience. Taking a viral, as opposed to top-down approach for tool use, will help build a cadre of sympathetic users. Much like a virus, this group will reproduce and expand, especially as your users are moved between groups. In the case of ReviewBoard, my sympathetic user became the viral agent. He started to request all of his reviews using the tool - even to the point of using the tool when doing an in-person code review. Over time his team members took on the tool, which then spread the practice to another team. All of a sudden, most of the teams in my geography, were using the same tool!
While having an internal champion, or sympathetic user is important, a complete solution is even more important. Much like the applications we develop, our tool needs documentation, and training materials, especially when a process change is under foot. Hold a training session for your developers and fellow managers, patiently answer any questions, and most importantly try to remain dogma-free. By answering questions and providing training, you're helping provide context on your new tool, and helping to win over users. In the case of ReviewBoard, my internal champion and I led a real code review, allowing developers to see how I was using the same set of tools I was preaching.
As build engineers, we must “drink our own kool-aid”; we need to practice what we preach. Showing others that we too follow the policies and procedures, and use the tools being suggested helps go a long way to breaking down the walls of resistance.
Conclusion
When rolling out a new tool, your relationship with the development team is as important as your technical foundation. A build engineer who maintains a good relationship with the development team can lean on that relationship, allowing him or her to take a chance with new tools. Building up that relationship helps develop an internal champion, and an environment that encourages change.
While users may be resistant to change, it's definitely something that can be overcome to the benefit of all. But a key component is helping users overcome their own resistance by hearing their needs and meeting their concerns. At the end of the day a build engineer must focus on and serve those internal customers, helping them achieve change.
Chayim Kirshen is the Build Manager at PlateSpin ULC, a Division of Novell. As an experienced professional with over a decade of experience, his prior engagements have included the Telecommunications, Financial, Healthcare, and Education sectors. Chayim manages a combined build and release engineering team, planning and developing with a Scrum development process. He loves GNU Make, NAnt, and breathes python and revision control systems. Chayim can be contacted through his website, http://www.gnupower.net , or at [email protected] .
