As SCM professionals, we want to not only work on software construction and release engineering; we want to help software organizations iterate, release, and work as efficiently as possible. A true SCM professional will not only work on Build and Release Engineering, but also try to remove all roadblocks to software development and software engineering. So instead of focusing on a tool in particular, I'm going to discuss how the SCM professional can introduce a tool into a development environment.
We Are Service Providers
First things first: an SCM professional is a service provider. We service our customers. While application developers (traditionally) service external customers, SCM professionals are infrastructure developers and provisioners; our customers are "in the building", part of the same office, they can even be our friends. This service based, customer focused approach defines our approach to introducing tools to an organization. First, we have to understand our customer.
Understand the customer
In order to introduce any tool, or approach any problem, we need to understand our internal customer. Where are they coming from? How do they like to work? Will the customer pay for an external tool? Can we provide their infrastructure needs with custom software development? Are tracking, logging, and access control important features?
Internal customers have the same wants and needs as customers paying for software. Internal customers are paying for our time, and we have to provide value every day to these customers. Learning about them, and understanding their goals can help you think one, two, even three steps ahead.
Realize that you have many internal customers. Even if you work only on the revision control system, you have multiple customer types: developers, development management, product management, even senior management. At the end of the day these stakeholders all need the same problem fixed, but from different vantage points. The developer might want easier merging, while the development manager might want to restrict commits. Product management wants the minimum time between code committed and a testable product, while senior management might be concerned with overall profitability. By focusing on identifying who are the customers, you can better focus on the solution you need to provide by understanding who the tool will impact and how.
Talk to people! Never underestimate the power a simple conversation can have. I always find I get more feedback when I go asking for it, than when I poll people informally over e-mail. Have you ever joined a development team meeting? What can we learn from them?
Identify the Problem
Fine, you understand your customer; now what? Examine your customer's pain points and problems. Understand what daily workflows are holding up your customer's deliverables. Learn exactly where the current infrastructure or workflow is tripping up your customer. What workflows can we improve? What problems can we solve? What is at the core of the problem?
When we identify the problem, we might better identify what our customer need is. An SCM professional who frequently engages development will move beyond just build and installation services, and help to solve software engineering issues.
By software engineering I mean literally, how do we engineer software? What are the processes involved to check code into the repository? What are the minimum tools our developers need to better do their jobs? What tools are on the horizon, or worth developing? An SCM professional will always be "ahead of the curve", sharing articles on technology, and even training with development teams.
But the first thing any engineer needs to do is understand the problem. Until we understand the problem, and our users' vantage points, we can't move down the path to providing a solution. But let's jump ahead to sharing our solution...
Champion the Solution
Part of sharing and championing a solution within an organization involves identifying the Internal Customer. Given that we understand that customer, we should have a pretty idea of "who" they are within the organization; these are the people you'll approach for helping with your Beta Programme and feedback. An internal beta is the easiest way to get customers on board, and at the same time gain meaningful feedback.
If you're writing a custom tool for the organization this becomes even more important. Understanding the customer mindset and approach can drive meaningful feature development; much like with the Scrum Development Paradigm, your goal is to bring the customer as close as possible to the development, again gaining meaningful feedback. Soliciting and incorporation feedback as part of feature development is a great example of relationship building that will drive tool acceptance. Users like nothing more than to see their suggestions are considered; at the very least provide feedback on every suggestion you receive from your internal users. Developing a rapport with these internal customers means a much higher likelihood of a tool's acceptance into overall process, regardless of whether it is written or acquired from an external source.
But most importantly, if you're going to champion a solution, you have to live it and love it. Find a way to integrate the tool (or even a portion) into your process, your daily life. Share your passion and enthusiasm for it, find others that will need your tool, or that might just want to play around. Every development organization was people who like toys, and custom tools; those people are the target of your enthusiasm. Your enthusiasm, and your passion are the keys to championing your solution with customers. Approach and attitude are just as important as audience.
Provide Training and Guidance
The easiest way to close the loop, and encourage tool use involves training. Write documentation, run a class or two, post an internal video! By providing ongoing training, and acting as a resource, you help the organization absorb the tool. Unless users know what tools are available, and where to find them, they'll never use them. Once a tool has been "in the field" (or in our case, deployed internally) for a period of time, run a refresher class. Reintroduce users to the tool, and introduce new users to the tool. If applicable, show off some advanced features.
More importantly, revisit your users use of the tool over time. Just like during the initial phases, ask about pain points, try to understand rough areas, and see what you can do to smooth out the lines. By being the champion we've discussed, you can help provide constructive feedback to the tool developers (even your own team). This can only help improve the tool's use experience, and acceptance.
Wrapping it Up
Changing a workflow and having a tool accepted in an organization isn't an easy task. But, with perseverance, engagement, and your eye trained firmly on the customer, it's relatively easy to achieve. The key, is to remember that the customer comes first, that as SCM professionals our focus is on our customer, and improving their environment.
Remember to keep your focus on the customer. Understand the customer, focus on their needs. Developer or procure a tool the improves their environment. Finally, develop the internal customer, with the goal of improving their workflow. At the end of the day, we need to make our customers a happier group of people!
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] .
