SQL Server Reference Guide

It’s becoming more common to work on a team of technical professionals that are not in the same office, building, or even the same country. While the entire team is affected when they are not co-located, this situation brings up an interesting set of considerations for the data professional. In this article I’ll cover some tips and tricks I’ve learned along the way when I’ve been both a worker and a manager of development teams and data professionals.

Working in a distributed team can be challenging, especially if it is a change in the way your team has worked before. You might have had a larger team that changed its footprint, and that might cause some stress on a personal level. Or perhaps you are the one that has been brought in to a current team. That can be stressful as well.

Or perhaps you’re the lead technical resource or manager of a team that is now distributed. You have to juggle not only the tasks at hand, but personalities and even schedules that span the globe.

The key for the entire team is to realize that the point is to work together to solve problems. If you can keep that as the primary focus, it can actually be a rewarding experience. If you make getting your way, or doing things in a certain manner the focus, you can end up quite frustrated no matter what your role. I try and learn from everyone I can, so no matter how I work, I gain professional experiences that help me.

I’ll explain a few of the common concepts to keep in mind regardless of how your distributed team is arranged. I’ll follow on with some specific information for certain team configurations.

Common Attributes

No matter how your distributed team is arranged, some functions are essential for success. The order actually matters here — as I’ve worked in multiple teams I’ve seen these attributes become pivotal in importance to make sure everyone gets the work in on time, on budget and produces a quality product.

Coordination

The first step in a distributed team is to clearly identify the responsibilities and handoffs each member or location has to the other. For instance, when the distributed team is arranged in a component fashion (more on that in a moment), the testing team might be in a different location than the data development team. I’ve worked in several companies where the testing team is on a 12-hour offset from the development teams, allowing testing to be done at night (or during the day, if you’re in the testing team) and the development to be done during the day. It’s important in that case to have all of your code checked in by a certain time, and that the testing team starts on the code at a certain time.

While that specific example might be obvious, it illustrates the need for coordination. I’ve actually had code tests run on the wrong set of code for just this reason — the lack of coordination.

So the first place to start, whether you’re the manager or the worker on a distributed team, is to have a clear line of sight as to the responsibilities each team has. The less clarity here, the more friction between the teams and the more errors you introduce into the application.

It all starts, as always, with clear specifications. From there, the planning and tasks document (sometimes a formal project plan) are more essential when the team is distributed, since everyone is not always available to answer questions. If each team is empowered to make decisions for their area because of the coordination you have in place, each function can be autonomous for their area of responsibility.

And that brings up the next critical component — communication.

Communication

You might think that communication is not only a given, but should go first in this list. But in fact, communication is not always a given, even when we think that we’re doing a good job with it. I heard an interesting comment when I mentioned this fact in some training I gave a team I was leading:

“Well, it goes without saying that we need good communications between our teams.”

In fact, it had gone without saying — which was why we had to have the training. I had to teach the team to over-communicate, meaning that they had to put more information on wiki’s, in project documents, specifications and the like. The more verbose and clear you are (with a focus on clear more than verbose) the better the code will be, and the better the team will get along.

You might be tempted to pick a single communication method and enforce it. I’ve been on teams that required all communication through the check-in and check-out code control system. I’ve been at others that used wiki’s, web sites and project documents. I’ve found that no single system works. When possible, pick up a phone or video-chat package, use a chat client, Facebook posts, whatever you can that fosters constant chatter.

In some cases the communications for a particular item may be important enough to use an e-mail or other formal, recordable method, especially if it involves a code change. But for questions, comments and clarifications it’s essential to let the team find whatever methods work for them.

As a team, decide on the templates, T-SQL and other coding standards that you will follow and communicate them often. I’ve seen pitched battles over teams that implemented even error handling code in different ways. Agree to those standards, and communicate them clearly.

Collaboration

That being said, you should establish some clear guidelines on that communication, and the processes and procedures that go with it. I’ve used everything from SharePoint to a simple file directory structure to ensure that the team has a central, authoritative place to go to provide the latest updates, schedules and the like. While communication tools shouldn’t be restricted, you should pick a single collaboration tool, train the team on it, and use it.

In the collaboration tool, make sure you re-use as much collateral as possible. For those T-SQL templates and standards, point to a single corporate resource rather than copying them into the tool. That way you won’t get “drift” between projects and you’ll make everything better when you update the core location of the resource.

Collaboration also includes inter-personal skills, cross-training and shared purpose. Once again, the key is to recall that the entire team should focus on solving the problems at hand. When that focus drifts, the team will not collaborate as well.

I’m often asked about meetings. They are inevitable from time to time, but it’s important to realize that the inconveniences because of them should be shared.

I once was in charge of a global DBA team across a large company. We had DBAs in Europe, China the USA and South America. No matter what time I scheduled a meeting, someone was up early in the morning or late at night. My solution was to hold the meetings at a different time each month, inconveniencing one group at a time. If it’s a more temporary arrangement, that may not make sense for you. The important thing is to keep the meetings to a minimum, make them valuable for every single person that attends, and keep them short.

It’s worth investing in inexpensive web-cams so that each member of the team can see the other person as they speak. Studies have shown there is a stronger team connection when visible contact is made. And a stronger connection means that your team will work better together — and that brings us back to focusing on that common goal.

Modalities

Along with those common elements of working in distributed teams, the makeup of the team can make a difference. As the data professional, you’ll often be pivotal to the development effort, so it’s important for you to know how the team is constructed, and to what end. Knowing how your team functions is critical for helping you work with them in the best way.

Component Functions

The team may be constructed along functional lines. That means there will be one location that houses the User Interface (UI) developers, another for the testing function, and another for the data function. One or more of these may actually be co-located.

In this situation, the coordination phase mentioned earlier is paramount. It’s very simple to start “bleeding over” in a team’s function, especially on the data layer. For instance, which team will create the initial data design, who will write the stored procedure code, or even decide when server-side code (like stored procedures) will be used over dynamic SQL statements being sent from the client code? It’s vital to wall these decisions off early when you’re using this distributed team arrangement.

Phase or Workload

Another method of arranging a distributed team is by the phase of the work or the workload. I’ve seen testing in a development organization be a shared resource, so when the testing is required for an application the testing team is grafted in to the product team in this case.

Important considerations for this type of distributed arrangement include really clean documentation, a form of communication. Consider the team that comes into the project — if they have to get the histories and status directly from others, there is a chance of miscommunication, vague information, or even worse, different team members getting different information.

So in this type of team you want to ensure that you are keeping the documentation up to date, readable, and as complete as possible.

Temporary Skill Purchase

This is one of the easiest distributed teams to work in. I’ve most commonly been involved in this arrangement when we need “creative” talent, such as artwork, design and so on.

Even though this is a simple type of distributed component, it is fraught with danger. The most important implement you can have on this type of team is a requirements document. It forms the basis of the work the other team will do — in effect and in actuality, you’re contracting work to be done. If the other team is professional (and you should only deal with that kind) they will have legal counsel, and the requirements forms the basis of the contract you write with that team. You’ll have to pay for the work, even if they “get it wrong”, if your requirements are unclear — and that’s only fair. So take extra time on your requirements, and make them as detailed as they need to be.

Another important factor in this type of arrangement is to have a good fall-back plan if things go wrong. Since you’re contracting out, your schedule is probably impacted heavily if the other team does not deliver on time, or has to re-do any work that isn’t acceptable. Don’t make your schedule so brittle that this would sink the project.

Even with all these complexities, working within a distributed team can be a rewarding experience and you can learn a lot from the process. Not only that, but this new way of working is inevitable, and you will most likely face it in your career. Learn the information you need to make it successful for you, and you’ll be able to show that skill as a value to your employers.