[Programming] [Photos] [About Me]


[Back to articles]

Crossing The Boundaries: Application Development In The Distributed Team Environment

This is an author's translation of the article that was originally published on http://www.citforum.ru/SE/project/distributed_team/
This article is based upon several years of working experience in global (less or more) software development teams starting with the case of one team distributed across two offices and ending with the case of three teams distributed across three countries (and two continents). How do such teams and projects appear? In small companies the particular expert value could be much more great than communication extra costs and the person actual residence is leaving out of account. To the contrary, major companies have a lot of tasks that are not too complex and the decision could be made to outsource them, including offshore outsourcing. The problems are still quite the same anyway, and the present-day communication means doesn’t answer all the questions.

In this article I will point out areas that seem to me to be the most important from the point of view of distributed team work organization and also will share the information which decisions were effective and which were not.

Introduction

The distance itself is not the only problem. Even in the case two programmers seat side by side in one office room working in the same project they can show no interest in each other’s work. You can think about two persons working in adjacent rooms in the same office as if they are living on two different planets connected with network only. But still they have an opportunity to meet each other in the dining-hall and this is already better than nothing. If they have meeting once a week – it is almost good, they probably know each other names. It's quite another matter that even such infrequent meetings for many teams could be the luxury. People often work in co-operation for years knowing one another by name, the messenger id and the email only. Thinking of the effectiveness of working in such conditions, the principal attention, in my opinion, should be devoted to the following aspects:

  1. Administrative information
  2. Means of communication
  3. Tools for collaboration
  4. Shared areas
  5. Typical problems

Main aspects of distributed teams interaction

Administrative information

In every project the most reliable communication channel will always be channel “Central management - subordinate units” (“Manager - Performers”). Whereas the absence of communication between team individual members is still imaginable, the absence of communication with the manager means that the project is more dead than alive. Along with administrative actions this channel can be used to distribute information, expecting that it will reach all team members.

It is known that any specialist will do his/her job much better if he/she will know definitely that should be done, what are the terms, and why should it be done exactly this way and not another. Hereby the following information should be publicly available in the project:

Requirements
Being fixed in any form, requirements allow each participant of the project clearly understand what should he/she do, which also means the ability to make estimations concerning the time needed to accomplish these tasks. In conditions of distributed team work, fixed requirements are the only valuable guarantee that any results will be achieved at all. In spite of banality of this statement this is being disregarded surprisingly often, and people are being assigned to implement something indeterminate.
Plans and business objectives
Here I'm talking about low-detailed general plans and high-level business objectives. They answer the questions “what is the date” and “what is the purpose”, respectively. General plans contain dates when the functionality availability becomes critical for the business. Business objectives provide an explanation what the work is being performed for. This knowledge is not so important for the technical specialist as requirements, but allow to implement the latter much more consciously and effectively.
Team organization chart
People need to know who occupies which position and who is responsible for what – to ask questions, to ask for some task execution or to inform about problems. All contact information should be available as well – phone numbers, email addresses, messenger nicks (numbers). Do not suppose everyone knows it all as it is – one day it will turn out that it isn't so.
Responsibility of teams
It is the logical consequence of the previous clause. If several teams are involved, it should be known which team is responsible for what and who is the contact person for each team.
Glossary
It seems to be a trifle. But once it happens that team members speak as if the different languages. On the one hand, this induces that situation when the different names for the same things appear in the the user interface, application code and the data scheme. On the other — it leads to variant readings of requirements and incorrect logic implementation. The presence of glossary becomes even more topical when team members actually speak different languages.

In every particular case this list can be extended. Here can be put, for example, project risks, reports of all kinds, policies, procedures, references, manuals and many many other things. All these documents can become a content of your corporate informational portal.

Means of communication

Unlike the preceding point which describes what one can know knowing where it can be found, this point has concern with the means of direct communication of two or more team members.

Skype, Icq and other instant messengers
I give this means of communication the leadnig role even in that projects that are being implemented by teams located in single office. By my experience, the most part of conversations in projects take place exactly by means of the messengers. This is not in each case as effective as a phone call, not so official as a mail message, but this is that means which is always in touch and which allows to communicate asynchronously, i.e. to ask when the question appears and to answer when a moment occurs.
When the telephone communications are too costly, this is always the device number one. I think the case as well is that this way to speak more than other is similar to the live conversation of two persons, more efficient of which can be a telepathy only.
Phone
For all the convenience of instant messengers, the moment comes at times when it's simplier to tell something in two words than type many phrases instead. The phone, of all the means of remote communication is also the best way to force another person to answer you (the phone call is the thing not too easy to ignore). It would seem that there is no reason to discuss advantages of the device that has turned century. But sometimes, in conditions of high costs of intercity and international calls the telephony can be considered excessive. Anyway, it is worth to think twice before reject such high-effective means.
Tasktracking, Bugtracking systems
When developing software, exactly the bugtracking (tasktracking) system becomes one of the major communication means. The significance of such system is often overlooked; however such system allows to keep all the information related to the bug (task) in a single place. Storing all the discussion history, all the related files together with the bug description gives a great opportunity to fix the bug without resort to any other sources. In addition, the decision sequence can be reviewed if needed. It should be taken into account that bugs are often being fixed by participants that join the project much later than where these bugs were registered. It happens that old bugs are being reopened again long after that moment they were closed first.
E-Mail
Many people believe this is the most preferable way to communicate. Yes, indeed, this means has several evident benefits: mail messages are rather official, they are stored on the server for the long period, manager can be put in the copy. E-mail message fits well to send the textual information of large size, to send any information to the group and to inform about final decisions. But frequently above-listed advantages become disadvantages: e-mail messages do not require immediate responce, so they are often postponed, after that they can be forgotten at all. Mail messages are often have large size, so they often just glanced over. Mail messages are rather official, so they do not contain any momentary minor details, it's hard to sense the spirit of the team and state of affairs. In this respect mail messages are much alike the project documentation, with the difference that the documentation is read as the need arises and mail messages arrive themselves.
Live contact
Still there is no substitute for the personal contact. I know by my own experience that you start to think different about the person you are in contact with after the face-to-face meeting. In conditions of distributed team environment you should try to find at least one opportunity to arrange the team live meeting. Even one business trip can give a powerful incentive to more effective collaboration of team members.
Videoconference
Videoconference is when several men are watching each other on the TV and that's about it, at least in conditions of lack of the wideband transmission channel for the video. I cannot say from my experience that the videoconference could help in solving any really serious problem. As the videconference is usually hold for many people chatting, some of them in such conditions prefer to remain silent, especially when they not gain anything by this discussion. Meanwhile, to be silent at the opposite side of the screen is far easier than at the opposite side of the table. For many people the videoconference is the unwonted way to chat, that because it can seem less practical to people than the e-mail correspondence or exchange of instant messages, in spite of apparent similarity to the face-to-face meeting.

Tools for collaboration

This point is devoted to decisions related to the selection and configuration of tools for the team development.

Version control system
I regard the presence of such system as a mandatory requirement for the professional development of software. I'm not going to talk about its advantages – this information is in abundance in other sources. I'm going just to say that the chosen configuration of the version control system has a essential influence on the development process in whole. On the one hand using the locally accessible version control system (each local team has its own repository) has certain advantages: there is no need to agree on the check-in time, there are no delays caused by the net failures when the control system is integrated with the development environment. On the other hand, the decision to use the local repository requires the modular application architecture and augments the integration risks.
Trackers
I'm talking about all the means for tracking tasks, requirements, bugs etc. As I said earlier, the bugtracking system is one of the most important means of communication for the project team. Thereafter the project team should possess such tool.
Document version control system
It provides a team access to the project documentation and allows to store document versions. Whereas the source code almost always is put into the version control system, documents are often stored simply in the common network folder. However using the version control system to store documentation not less beneficial than to store the source code. By the way, there is no reason why the same system could not be used to store as documents so the source code, so it is not obligatory to buy the additional software for this purpose.
Common network folder
The must have for the project team to share information somehow.
Planning system
Provides the common access to the project plan.
The simplest web site containing each team member photo, name and position
It seems to be a trifle, but it makes possible to create the sense community in the project team. Seeing their photos placed together people really start to believe that they work in the same project. The more particular details one man knows about the other the less abstract one seems to him, the easier for these people to communicate. After all, such site is the suitable place to specify the position, responcibilities and contact information of each team member.

Shared areas

Here we will discuss these areas in which the project participants interoperate with each other daily — their common field of activity and point of their efforts application.

Source code
This is an intermediate result of joint efforts and, in fact, the most important thing which these effords are needed for. However distant may team members be, they inevitably will meet each other here. That is why it is so important to plan and organize the team coding process. There are several approaches:
  1. Collective code ownership. This approach is describen well in sources devoted to the extreme programming (XP) and in theory has a whole number of advantages including the continuous knowledge exchange about the application, team participants interchangeability, uniformity of the resulting source code and its continuous refinement. But in practice to get all said advantages you need to have really united team of like-minded persons, or to confine yourself to the option when one lead developer gives particular tasks to sevetal subordinate programmers and defines the degree of their interference in each other's work himself/herself. As I see it, the collective code ownership fits well for rather small teams only — from 1 to 5 persons. Anyway you should be ready to that the collective code ownership can pretty soon turn into uncontrolled. In the worst scenario this can lead to the situation when one developer improves the code written by another without investigating it thoroughly or rolls back changes made by others, while they defend their own parts of code to the bitter end. Such situation causes irresponsibility and strained terms in the team.
  2. Everyone writes his/her own part of application source code. Separating programmers in their work we get such a plus as satisfied programmers that often prefer to work independently and personal responsibility for dedicated part of the functionality. However, disadvantages will be in numbers, too: every programmer often writes code in his/her own manner, poorly undestands somebody else's code, so when one programmer leaves the project sometimes it appears that his/her code cannot be supported by anyone else. In addition, the little attention is paid to the module interaction that are written by different programmers as they more worry about the module internal design than about the integration with other programmer's modules.
  3. It seems to me to be the worst combination of both approaches when one developer writes a code and another fixes bugs. In this case we get irresponsibility of the first developer and disappointment of the second. I need to notice that when fixing the bug in own code is the matter of honour for the developer, it is utterly unpleasant to complete someone else's unfinished work.
  4. It seems to me the most attractive combination of these approaches can be the different one that is possible when the component design is utilized: each component is developed by the single local team, inside of the team the collective code ownership is used. Interchangeability and knowledge exchange are ensured within each team, and team locality guarantees quick and trouble-free settling of disputable issues. Component boundaries prevent teams from direct interference in the work of other teams. At the same time the module design orientation assumes that questions of the component interaction (component interfaces) will definitely be taken into consideration.
The check-in procedure
When the code is being written in common check-in becomes a key point. It is necessary to clearly define all conditions that should be satisfied to allow the check-in (souce code must at least be compilable, unit test must pass, etc.).

If the time shift exists between teams it may be useful to fix such check-in schedule what permits each team to check in at the appointed time only, for instance, at some appointed hour, once a day. However this approach has a considerable disadvantage: changes accumulated in the course of day discontinue to be atomic, check-ins are put off regularly because sometimes it is difficult to fulfill check-in conditions at some appointed hour. It may be more felicitous decision to use the schedule that prohibits check-ins in a certain period and permits them the rest of the time.

Architecture
Whatever form of code ownership is applied, in any case, all the development should comply with some general concept, approach. It is possible to distinguish at least three approaches:
  1. Monolithic applicatoin. Each developer implements the part of application functionality that he/she is responsible for, agreeing with others about the interaction somehow in the course of development. This solution may be appropriate for the local team, but not for the distributed one. The great risk exists that there will be misunderstanding or disagreement between teams.
  2. The framework and framework-based development. This approach allows in natural manner distribute the responsibility amongst developers, but doesn't favour their relations to become closer at all. Quite the opposite, developers of the framework take more interest in general problems while developers on the framework — in more particular, their viewpoints on the same functionality can differ considerably. In addition, developers of the framework become in some way the «high caste», that can lead to a tension between groups.
  3. Component design. Teams are responsible each for their own components and define component interfaces together. If there are several teams in different parts of the world, the component application structure the most accurately matches the structure of the global team. The only complexity is that for the component design implementation you need to be quite familiar with this design approach.
Knowledge of the application being developed
This is that knowledge that team participants share between themselves. It is as the knowledge of the application architecture and source code so that concept which the architecture and code are being embodied from. The project documentation like specifications, manuals etc. is just partial, even if structured, representation of this knowledge. Unlike the administrative information such knowledge spreads more naturally in horizontal directions. In any event it is worth to think how to make it spread even more effective. Lets consider several possible approaches:
  1. Information exchange through the source code. Ie one did — others see when it meets their eye. Such approach indicates that there is no cooperation amongst team members at all. The most likely outcome is that the application will consist of heterogeneous parts that will hardly match each other.
  2. Informal information exchange. This option differs considerably from the preceding one as here we are talking right about the permanent communication inside the team. In such conditions the knowledge is being transmitted easily and quickly and excessive formalities only impede this process. To achieve such level of communication, however, it is not enough to seat team members in one room, though it is absolutely necessary (Of cource technical and non-technical specialists should be separated).
  3. Keeping project documentation actual. I wish it could be enough, but just the most important and general decisions come into the documentation definitely. If your documents are quite detailed they are most likely will soon become outdated because it takes too much time and efforts to keep them in actual state. This is the main reason why many do not attach great importance to documents. I must agree that personal contact cannot be substituted completely for documents. Meanwhile, certain documents can be extremely useful. Incidentally, the most necessary and helpful documents often appear per se, when people make notes for themselves and afterwards it turns out that this was necessary for all for the long time. I would prefer to create documents as the need arises only, always discussing this question with the development team.
  4. Sending information about made decisions by email. This is the one of the most common choices that suits well to inform about the major decisions, with all characteristic disadvantages of the email messages. In any case it cannot be substitute for the personal contact. In addition, the information being spread this way generally appears in documents as well. So it is just the mailing and thats all about it.
  5. Regular meetings. The question is how regular they are. In the team that meets once a week so many unsettled questions are being accumulated that it may be very difficult to keep the meeting within the bounds of agenda. Meetings with month periodicity will most probably be devoted to most common organizational issues only. In any event, many questions, especially technical ones, can be discussed much more easy incidentally than on specially arranged meetings. In addition, almost all technical decisions should be examined for their feasibility and efficiency, you will probably have to review and correct them many times.
  6. Informal information exchange within the team and regular meetings of team representatives. This approach looks attractive if the application that you develop has component design. Within the team the knowledge diffuses because of everyday discussions and collective code ownership, component interfaces are being designed and approved on general meeting of team representatives. Component boundaries can be defined in this case based on natural limitations on the information scope that every team can comprehend at the same time.
Methodology
This is one of these issues that people hardly probable come to an agreement about. While the extreme programming approach seems to be the best for one, another raises the issue about lack of documents and protests at the requirement changes. Everyone has his/her own personal experience and vision about it. Disputes might go on for ever. My opinion is that the right to make the final decision on this subject should be possessed by the only person. This person authority should be indisputable.
Current Build
Daily build is the process that gives the team the confidence, signaling about successfulness or unsuccessfulness of the modules integration. This is the development status indicator for the team. It is very important to get an actual application version every day and make sure it is still functional and passes tests. Of course, when application build fails because of any developer mistake this affects all other developers. It may seem scaring, but it allows to make every developer conscious of his/her participation in the final product elaboration, let him/her sense the team spirit and personal responsibility for work results.

Typical problems

Here I will enumerate those problems that I met more often when developing by global team.

Knowledge about the application being developed
However the information exchange is organized, there always is a risk that some aspects remain unseen, even when the closest cooperation within the team exists. It is clear that new team members will need some time to get plunged into the process. Some application parts/modules might be found too complex to make everybody wish to get plunged in details. Anyway, consequences of ignorance can be as follows:
  1. Delays and unproductive time being spent on clearing necessary details up
  2. Duplication of work that had been already accomplished by someone else
  3. Incorrect functionality implementation
  4. Architectural decisions that do not take into account all the project specificity
Distrust
People are not used to trust whom they poorly know. If two persons never met, they will be trying to guard each his/her own portion of works from mutual interference. Simply debugging the code, developer will assume that the bug is in the code of other developer. And if it will be there indeed, reaction will be far sorer than in the case this bug is made by person which the developer works in direct contact with. People working in the same room generally think milder of other’s mistakes and even their criticism becomes calmer, compared with working with colleagues who are employed in another cities or countries. That’s why it is so important to arrange at least one face-to-face meeting for your employees, too.
Impression that things are going better than they do in truth
It appears because team problems often remain their own internal problems and only good aspects and achievements are being carried out. You should immerse in the team everyday activities, spend some time inside of it to get aware of the actual state of things. In other words, you should gain confidence of the team. But when the development is being performed by several distributed teams, the chief doesn’t always have enough time to pay equal attention to each one. If the chief visits the distant office once a year and spends 3 days there it is difficult to say whether he/she will draw the right conclusion from his/her visit. Spending at least a week every 3-4 months you can learn a lot more.

Conclusions

  1. It is worth to think about the information that should be publicly available in the project and provide this information accessibility. Surely, requirements, goals, plans and the information about team organizational structure and responsibility should be available. The project internal website is a good place for all this information.
  2. You shouldn’t save on means of communication. Make use of all available communicative means to make all, even the most distant team members closer. People interact the most effective way when they talk one to another directly.
  3. Consider purchasing of existing tools increasing the cooperation efficiency, or create your own tools.
  4. Pay special attention to things that team members own collectively: application design, source code, knowledge, methodology. Organize this ownership taking all the project specificity into consideration.
  5. At last, collect and examine the most typical problems that occur in your work. They might not have any guaranteed solution, but it is still possible to minimize the risk and their undesirable effect.
© Artem Kondratyev 2008