Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Distributed SCM

Written by Randy Wagner

Monday, 14 February 2005 16:00

Offshoring and corporate mergers cause headaches for those of us expected to “quilt” with development teams in various cities and countries. But how do we perform great SCM in a distributed environment? What does it take to successfully establish an SCM presence that is capable of continental or global support? Does an SCM need to be “embedded” with the troops in the war on chaos? In this article, we’ll look at these issues and how we might resolve them.

As many of us are starting to experience, more and more development work is being done outside the company. And not just singular modules either. We’re talking ongoing production support and evolution. Parallel and concurrent developments are fully in the game from Bangalore and Beijing, Singapore and Germany, and everywhere a computer connects to the internet. In order to manage this successfully we need more software heros to do that twenty-third hour push and save the day. Just kidding. We will rarely get lucky enough to have a good SCM team in place at each location so we can just coordinate and sync processes with local reps to follow things through. To overcome this, we need to set some rules and identify some requirements.

First, middle, and last is management support. Particularly from upper management. You need the person with the power of the purse to at least agree in principle to, if not outright demand, compliance. From the get-go. SCM needs to be written into the contract in some way. Not being able to stroll over to someone’s desk means people need to meet expectations. Like runners in a relay, the baton needs to be in the right place for the next runner to take it the next stretch. Hat in hand is no way to make it work. We need individual areas to understand that we are a global team and that sacrifices at the team level produce net gains at the project/company level. That’s where senior management needs to work its magic. All of us are subject to political and interpersonal battles in the corporate world but this is a task to push upward. We want to come in as the saviors who will make process changes less painful for a functional area, rather than coming in with guns blazing.

Secondly, is our own house in order? Do we have our own processes appropriately documented? Are the procedures streamlined and effective? Do we have the communication tools in place to properly implement our strategies? Of course, they are. You’re a professional. Next topic.

Thirdly, we need a plan. What groups are the most critical to get into compliance? Who’s causing the most rework or difficulty and who is running a fairly stable shop? Then tackle them in a reasonable order. New military units often are thrown against easy targets first to establish an aura of success. It also allows you to work the kinks out of your implementation methodology before facing a more formidable group. Starting with the most intransigent team is likely to cause massive frustration and heartache on all sides, further building up barriers in the other teams you will need to bring into the fold. Remember that SCM begins before coding. Sponsor plans, requirements, and design documents are usually formal configuration items.

Fourth, we need to take the time to understand each area. We neither have the time or the political capital to take on everything at once. But many times our work is already being done for us. While the area under consideration may not be running an SCM team, they are using process somehow. We need to translate existing practice into a workable solution that incorporates other SDLC users’ needs. Speaking their language, at least from a process standpoint, will make our own efforts at least appear to be less intrusive and engender less resistance. We really need to communicate with them. Remember the only prism they have to view you through is your communication. Do more than just the bare minimums. Build the personal relationships that will help make SCM implementations successful.

Tools are also critical to consider in your rollout. By all means get groups without tools into something. Not all groups may be able to use the same tool. Mainframe software development lifecycles (SDLC) will behave vastly different than web content management systems. Once you understand each area’s systems, identify if this is an appropriate application for the tools in place. It would be swell and economical to use a singular set of tools for everywhere in the company but remember that every user that touches the system should be deriving a comparative cost benefit from it. If they take twice as long to use it, multiply that time by the dollar cost and then multiply by the number of users and see if you are really saving money by staying to one tool. Perhaps your issue tracking software will work across the board in the company but your version control tool will not. Development teams that I have worked with often said that everything outside of their current practice is pure cost and hassle. Take the time to work with them so you can separate the wheat from the chaff. Test groups usually get the short end of the stick and are happy to get some process that benefits them. Do your best to ensure the different environments have the appropriate read/write/execute access.

Often the company can not (or will not) pay to send you to all the sites you manage. Spend the time needed on documentation. Emailing the first, or even second, draft to a full project team is not going to cut it. Write and re-write them. Work with individuals on the teams affected so they can help you vet the procedures. It will give them ownership and ease the transition. It also sets the expectations. You need to see certain “switches” in specific settings so the next group can do their thing. While dumbed-down procedures are a pain, it will be a prime source of communication for them, particularly when they are in vastly different time zones. If you are compiling, do not allow long stretches of time to go between versions. Merge often. Regular iterations will significantly help everyone stay on track. That’s often not a decision SCM gets to make but push for it. Another option is to create a knowledgebase accessible by everyone. Those are only as good as they are maintained but it may be a solid choice for getting started.

Time is another factor for considering how to run SCM across a multi-hemispherical company. While much of this is a management issue in terms of turn around time, it may play into the SCM book if they are developing code that you need to compile. Or, you may need to coordinate your releases with the admins of the test environment. There is also the probability of coordinating production releases across time zones.

Change Control Boards (CCBs) may need to be multileveled. Clarify which decisions can be made at the various levels and we accelerate the speed of development without losing the necessary control. This will be a headache for the detail-oriented program or project manager, particularly in the various time zones but again it comes down to communication and how well information moves up and down the chain. Identify what we can do from a tools standpoint to disseminate that info.

Ultimately, you will need to answer the following statements for each activity in the SDLC, regardless of where they are located:

What is the action being performed?
Who is responsible for doing the action?
How does the doer know it’s ready to be done?
Who has access to the items being managed?
When does it need to be completed?
What needs to be done for the next doer to pick up the action?
Who needs to be notified of completion and how?
Who do people go to if the assignee is unavailable?
Can you measure the action for appropriate metrics? (Are we getting quality? Is it quick? Is it punctual?)
Who will do the reporting and Auditing? (Do you have visibility to their site or will they provide you with data?)

Effectively this is a service level agreement that everyone can use to understand the expectations through the lifecycle.

One of our other questions is this: do you need to have an SCM person in place with the teams? A good SCM should have a lot of contact in bringing new groups into the process fold. They should be available to understand new systems and help the company adapt to new structures. If your tools can provide reasonable security and your process is well communicated, you don’t need to be physically there to hold hands, even in a fairly manual environment. We may need to establish 24/7 SCM support with team members rotating through until groups are more comfortable with the processes. The number one difficulty companies that off shore have is communication. If you can manage that, you can succeed.

Many off shore vendors will declare they are certified by various organizations. Maybe they are that good or maybe they were. Ask for their in-house processes and procedures. See if they at least measure up to your own. You will probably not get the chance to audit them properly but you can at least see if they pass a sniff test. That may give you a sense of how sophisticated the SDLC group will be and how receptive they will be to coordinating work with you.

Finally, go ask your own groups what their pains were (are) in coordinating with SCM activities. Find out first hand from them the things you will need to convey to your constituent groups around the world. This will be invaluable to you. Repeated mistakes are the most expensive kind. Do your best to get honest feedback and accept it as such. Users will always have a different perspective. Good communication skills require us to learn how our customers perceive us. And make sure your team understands those perceptions too, lest they inadvertently reinforce them.

This article could easily be a 200 page book (the author says, “hmmmmmm”). Certainly I can’t do it justice in 1700 words. Distributed SCM is complex only by time and distance. The principles remain the same as any small shop. Taken a step at a time, it’s something that can be accomplished well. If we work hard at communication and get support from management, we’re certainly capable of it.

Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com.

Set as favorite

Bookmark

Email this