Mapping Out Your Development Processes

Time is a fickle thing. You have an hour to kill before a flight, and the time seems to crawl by at a snail’s pace. But the six hours you have left to complete what seems like a simple presentation for a meeting tomorrow morning is gone in a flash of light. So much of our technological advances have to do with our increasing need to control time and space, to automate, to streamline, to optimize. All for what? To spend more time with our friends and families? Then why is it that with all of our innovations, we are spending more time in front of the computer and away from our families than ever before?

Now take a look at the changes in international business. The globalization of business is due in large part to some of these same technological advances. In the last decade alone we’ve seen how the need to have an international presence impacts our product and marketing strategies, not to mention our chances at corporate longevity. But even with all of our advances, connecting teams across geographical boundaries remains one of the most difficult tasks to master. When customers are waiting and competitors are poised to strike, time is of the essence. How can you save time? There are conference calls, of course. Video conferencing and webcasts help. Instant Messaging and the various social computing tools, while increasing productivity, can at the same time be one of the biggest productivity drains. But none of this matters if you cannot keep your development organization in sync. All of your efficiency gains on the business side of things are irrelevant if communication, synchronization – and time – are killing your development efforts. What are you in business for anyway, if not to create products or services?

Multi-site development is a fact of software development, and at some point in your career, you are most likely going to run into the problem of connecting two or more locations – or at least managing teams across a great divide. With multi-site development come problems of complexity, communication, and integration. How do you coordinate activities? How do you manage build schedules? Which branch is the right version to push through QA for your next customer release?

One of the surest ways to illustrate the process of integrating your multi-site development efforts and get you running on the right track is through case study analysis. Software developed in multiple locations needs to be integrated into a single product that is tested and eventually shipped to the customer. Map out your development activities so that the handoffs are clear, and the roles and responsibilities clearly defined. As with any use case analysis, the first step is to know your actors:

• Software Developers generally work around the clock to develop, compile, and test their code before marking it ready to be integrated into the product.
• The Configuration Management (CM) team is primarily responsible for the source code integrity, making sure all the remote sites have the tools they need to accomplish their tasks. This includes source-code management, defect tracking, compilers, operating systems, reporting systems, and the tools that integrate these tools.
• When the software developers have marked their code to be integrated into the product, the Build and Release Management team takes control of the code. It is their nightly responsibility to run the builds and the automated engineering regression tests, and to coordinate with the software developers on any issues with the compilation and testing of the code after integration.
• The Product Validation (PV) or QA team quickly validates the builds that the Build and Release team produces, and approves a build when it is ready for customer consumption.

Developing in multiple locations will need more than just setting up your software configuration management (SCM) platform and setting up a project status rhythm. Communication channels need to be established, for sure, but the process must be clarified. And in my experience, you cannot discount the value of face time with your teams. No matter how advanced our technology becomes, you still need to make regular visits to your remote teams to develop relationships, and remind people (and yourself) that there are real people at work.