Promoting Tools Within an Organization


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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.