Experience Report: Engineering Change in a Large Organization

[article]

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 ckirshen@gnupower.net .

About the author

Chayim Kirshen's picture Chayim Kirshen

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 ckirshen@gnupower.net.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!