Challenges of distributed development: part 2

Previously, in part 1 of this article, we talked about how important it is to enable team communication and to get all your team members on the same page.

Today in part 2, we will be discussing creating processes in your distributed development projects. In order to be successful, you need to have well-defined and documented processes in place to ensure the entire team does the same things in the same way.

Establish processes for your teams

All team members should be following the same processes. If you have no documented processes, you cannot expect your remote development teams to be in step with your way of doing things.

Here is a sample checklist of things you need to document before you start working with remote teams:

• What do they need in order to access the shared repositories? If user names are required to access them, what are the steps to request those?
• Where are the source code and requirements repositories?
• Where do you get the latest version of the code?
• What is your source code change management process? (i.e.: What are the naming conventions of activity names, stream names? Who is responsible for code merges between different version streams?)
• What is your software development process?
• What is your defect management process?
• What are your change requests and requirements processes?
• What are the coding standards used by the team?
• What are the steps to perform in order for developers to compile the source code?
• What are the standards for automated unit test creation (i.e. JUnit test cases)?
• What is the official build process?
• What do you need to do to get the application up and running for the first time?

As you can see, the checklist is all about enabling people to go off and do what they need to do on a day-to-day basis while requiring as little help as possible. The first step is documenting your processes, and the next step is disseminating the information. One way to do this is to have a wiki or some other internal web page where team members can go to review the processes and have them at their fingertips.

Get your teams to adopt new processes

Defining your processes is great but they mean nothing if no one is following them. You want your leaders to continually reinforce these processes and take the initiative in communicating with the remote teams when the normal course of action is not being followed. Set the quality bar where you need it to be and ensure the teams are reaching that bar.

You will be as successful with your distributed development team as you are working with your own team. If you have no processes and your team lives in chaos, well guess what? Your distributed development efforts will be exactly as chaotic if not worse, because you have just added a bunch of people to your team.

I was in a situation once where I was part of a remote team, and the main team had little to no processes implemented. As our team was certified CMM level 5, we had the ability to define processes. So each time we encountered a situation without a process, we created one. When the main team ran into the same issues as us and learned we had processes, they adopted ours as their way of working.

When you start working with a new team, you need to schedule working sessions where some of their developers come to your location. During this time, they will be able to get some face time with your team members and learn about your processes. In order to be successful, these sessions need to be planned and organized. Determine how much time is required for the essentials, and prepare a standard training agenda. If less than a week is sufficient to go through the essentials, have them come down for a week and give them some tasks to allow them to interact with the team.

The challenge with training sessions is that you may not be able to spare resources to give training. In these cases, one solution is to pair them with some of your best people for a week and let them learn your processes by seeing them in action. Make the training part of your process.

If you really do not have time for new employee training, I strongly recommend you do not do it at all. There are costs attached to training. It can turn into a large investment of time and money, so make sure it is productive. Also, look at this as a chance for your team to make a good impression and start building a working relationship with remote team members.

Organize your reviews

In terms of processes, it is critical to perform formal requirements, design and code reviews. You can look at these as checkpoints for validating the work to be done as well as to confirm any initial estimates. Involve multiple teams in the reviews and work to avoid the “Big Brother” syndrome where one team tells others what to do without considering their feedback.

Reviews need to be organized as well with everyone having had sufficient time to review any artifacts before the review occurs. Have a moderator that keeps track of any issues that come out during the review and follows up with the people assigned to them until they are resolved.

You need to involve multiple people in reviews in order to have multiple points of view. For requirements and reviews, involve people from the product management, documentation, quality assurance and development teams. For code reviews, involve multiple developers as well as a quality assurance tester.

Conclusion

Distributed development is about enabling people and making them an extension of your team. You will see the good, the bad and the ugly of what you do. To be successful, you need to identify what does not work and find ways to make it work. You need published processes for all to follow.

The issues you face day to day with your local team are the same that you will face when working with remote teams. As much as a child is a reflection of his or her parents, distributed development is a reflection of your current development practices.

Finally, you need leaders on each team who care and who want to make it work. These leaders will help foster a supportive environment where people will feel part of a team.

This is the edited version of the first ever article published by Steffan. Dr. Dobbs Journal published a shorter version of the original in their August 2007 issue.