The previous post on distributed agile software development – which can be a result of offshoring, outsourcing, multiple sites or just separated rooms within a company – discussed the benefits, motivation and the new challenges which will arise in such an environment. The follow-up post in this series will cover proven practices which can help to face these new challenges and lead to a successful project execution.
You might also be interested in the other posts of this series:
Part 1: Motivation and Challenges
Part 2: Best Practices
Part 3: Case-Study on Eclipse
Part 4: Evaluation and Summary
The agile manifesto describes different practices which have to be followed to ensure that the software development really is agile. With agile software development in distributed teams there are some practices which can’t be fulfilled (e.g. face-to-face communication). This problem is also stated by Ade Miller:
Agile approaches […] rely on a set of mutually supporting practices. Choosing to
drop one practice will weaken the remaining ones. Therefore when the communication bandwidth is
reduced teams must supplement weakened practices or replace them. Simply abandoning them […] will reduce the team’s level of agility.[Mil08, 7]
To avoid the weakening of other practices Martin Fowler [Fow06] and Ade Miller [Mil08] are providing solutions which have been successfully used within their distributed agile development environment. In the following the core practices which allowed this transformation of the agile methologies to distributed teams are explained and their impact on the previously shown challenges will be pointed out. These practices are meant as addition to existing agile software development methologies so that these can be used within a distributed environment.
Provide Multiple Communication Channels
As previously shown there are several challenges which arise from the communication hindrances. Because the required face-to-face communication is not possible within distributed teams it is necessary to provide multiple alternatives for this kind of communication.
A Wiki is the perfect choice to contain information which should be written down like design documents, metrics or build processes. Because Wikis are usually unstructured it is possible for them to grow with the project in an agile manner and will thus hold the information in a way which fits the teams needs the best. Additionally, the version history of documents can represent the iterative change of the project (e.g. design documents). This version history of the documents can then later on be used to extract information why specific changes were made. Another benefit of a Wiki is the change notification mechanisms like RSS which can be used to keep every team member up-to-date. However, the agile growth of the Wiki might make it necessary to assign an employee to look over the Wiki to avoid needless posts.
Instant Messenger provide three positive aspects. The first is that it is easy to determine whether a developer is currently available for questioning or not because the messenger usually provide status information about the user. This can be a great advantage when the overlapping time between two sites is limited due to the different time zones. Secondly, communication through an instant messenger is fast (synchronous) and the overhead is limited due to the informal manner of this type of communication. As a result it serves well as a replacement for the informal communication between co-located developers in a classic agile environment. The last advantage of instant messengers is that today’s clients usually support group communication which can act as a replacement for osmotic communication because all involved developers will all receive the questions and answers and might decide to actively contribute to the communication if they are familiar with the topic. This can also be achieved by chat protocols like IRC.
E-mail can be used as an addition to the instant messenger as it provides an asynchronous way of communicating information to multiple receivers. Especially when combined with newsgroups the information published can be easily accessed later on and the wanted information can be extracted.
Voice and Video
Voice (including telephone) and video chats are an important form of communication for distributed teams. It must be ensured that it is easy for the developers to use these mechanisms by providing head sets and web cams and to tell the developers that they should not be concerned about costs for the communication because the impact of missing communication would be even worse than some expenses for a telephone call. With the help of voice and video communication it is possible to organize daily meetings by providing rooms which contain cameras, microphones and a beamer where the distributed teams then can exchange important information. Furthermore, it is also possible create video recordings of meetings where one developer team could not participate to share it with them later on. By this it will be easier to catch up and no additional documents have to be created which are documenting that meeting.
Telepresence systems are robots which are placed on a specific site and then can be controlled by an operator over the internet. These systems are often mobile and include features like microphones, speakers, a video camera and a display which shows the operators webcam picture. Using these systems an advanced version of a video conference can be achieved. Furthermore, it is possible for the operator to interact with the employees at the remote site e.g. by moving the robot to their desk. Currently, there are only few telepresence robots available but in the future more systems might be developed. [Sim11]
It is an urgent matter to make the presented communication mechanisms available directly from the beginning of the project to avoid misunderstandings. However, these mechanisms cannot fully replace the direct communication but they provide a trade-off. If possible the synchronous communication mechanisms should be used but as a result of the different time zones it might be necessary to fall back to the asynchronous communication techniques which will add delay to the development process when compared to co-located agile software development.
There are two types of visits which should be considered: co-location visits and long-term visits.
These visits should be executed within the first few iterations of a project. The characteristic of this kind of visit is that all team members are getting assembled within on location. During that time it is possible to build trust between the – under normal circumstances distributed – teams, create bonds and establish communication channels which can later be used to avoid misunderstandings. But not only the team members should be present it is also important that the project managers and an expert from the customer are present which will provide these co-location visits a working environment which is the same as it would be within a classic agile software development process. Especially for creating a release plan and the development within the first few iterations this can have a positive impact on the quality of the created software because many key design decisions are being made at the beginning of the project and it is better if the whole team and the customer can equally contribute to these decisions. It is also possible for every team member to reduce the vagueness concerning the requirement specification which can avoid later misunderstandings.
Every few months these visits should also be repeated periodically. It is sufficient for these periodic visits to take about one week but it is also recommended to plan longer visits if bigger changes within the software are being made or if some communication problems occurred. These visits can be used to refresh the bonds and trust which is fading over time within distributed teams. Furthermore, these periodic visits are a good place to reflect on the process, the achievements and the failures and to take appropriate actions like updating the process during a retrospective.
Additionally, such a visit should also be performed during the last few iterations before shipping a release to avoid delay in the development due to communication hindrances during that important time. If the whole team is assembled after the release is shipped this visit can then also be used to perform a retrospective.
To ensure the establishment of relationships during the visit some social events should be organized and the work pace should be relaxed. Additionally, gifts representing the different culture of the visitors will also help to break the ice and will help to initiate the communication. Martin Fowler emphasizes the importance of connections on a personal level:
Dinners and sightseeing can often be the most useful activity that the visitors do with the hosts. [Fow06, #UseContactVisitsToBuildTrust]
This will allow informal communication to take place during the visit which will later pay off because more communication links will be available after the visit is over.
Co-location visits are complex and could become very costly so it might not be possible to get all developers of the different sites together. If it is not possible at least the senior developers of the different sites should perform this type of visit at the beginning of the project to ensure profound design decisions.
The key aspect of this visit type is that on every site there is always a representative from all the other sites present. The duration of such a visit should be ranging from a few weeks up to a few months depending on the representative being exchanged. The selection of the potential representatives must take the personal needs into account because it might not be possible for some to stay abroad for a long period. The main function of the representatives is to act as a catalyst for communication. Because he is familiar with the fields of specialization of his fellow team members he can establish communication links between both sites. Furthermore, he has access to the local informal communication in that team and can extract important information which he can redirect to his site of origin. Besides the benefits of establishing communication links the representatives is also able to build up trust between the geographically dispersed team members. A long-term visit also provides the project managers a good opportunity to get to know the whole team which is important when making decisions and resolving conflicts.
Martin Fowlers team extended this approach by not just sending developers as representatives but also by exchanging analysts who can communicate the requirements between the distributed teams [Mil08, 11].
To avoid misunderstandings and a lack of trust these representatives should be always present directly after the kick-off of the project.
The presented visits should be part of the distributed agile software development to compensate the lack of face-to-face communication, provide trust between the team members, to avoid misunderstandings and to counter the as Ade Miller states ”‘Us vs. Them’ attitude“
Use Iterative Documentation
One of the new challenges lies within finding the correct amount and format of the formal documentation which is required within an agile distributed software development process. Because every development environment is different it is not possible to define these parameters for every case. As a result the process of determing the required formal documentation should be performed in an iterative way. A company should start with only little documentation and constantly request feedback from the distributed teams. This feedback can then be used to adjust the amount and the format of the formal documentation in a way that it is sufficient within their specific set up. To support this agile approach all documents should be kept in a repository to make it easier for every participant to access the latest version of a specific document. Furthermore, unstructured content management systems like the previously mentioned Wiki have proven to be useful.
Continuous Integration is a practice which originated from Extreme Programming and its main goal is to avoid problems when big separated work pieces are integrated back into the system by continuously integrating small changes every few hours. To ensure that the repository does not contain code which has unresolved problems every developer should first build the code within a sandbox and validate this build by running tests. If everything went smooth the changes can be integrated back into the main repository where a build server should perform an automated build followed by tests which validate that the integration did not break the system [SW07]. Of course integration problems also exists in a distributed environment but the impacts of failed builds are even worse because a failed build can prevent a team which is working in a different time zone from further developing until the team who broke the build is back at work. This can be avoided by using continuous integration. Additionally from avoiding such development dead locks, by always committing small changes it will be easier to detect misunderstandings within the requirement specification. This can be achieved because the repository will always contain a working version of the current development status which the customer can access and check if the requirements are implemented as desired. Thus the in the agile manifesto valued customer collaboration can be improved. Another benefit of continuous integration is that the new developed functions will always be well tested which results in a higher quality of the produced code.
That is why Continuous Integration should be used when applying agile software development to distributed teams.
Distribute the Work
When distributing work to several teams it often happens that specific components are always assigned to the same team. This might work for smaller projects and – according to Conway’s Law (Conway’s Law states that the architecture of a software will reflect the organizational structures within the company [Wik11]) – will have a positive impact on the software architecture because it will reduce the degree of coupling. This approach is suggested by Martin Fowler[Fow06]. Ade Miller on the other hand points out that this kind of distribution bears a big disadvantage for larger projects. As a result of the component-wise distribution islands of expertise will be created among the distributed teams. When new requirements arise it might be hard for a team which worked always on a specific component to quickly switch to a different component to develop a new feature within this component. He states:
The impact of this disadvantage is that agility within the software development is lost which should be avoided. So it is necessary to deliberate for every project about whether to use the component-wise distribution or not.
Another approach which is often used for distributed teams is the activity-wise distribution. For example this can mean that testing is done on a different site than the development. This might work well in a classic software development process but it should be avoided when agile methologies are applied to distributed teams because by first creating test cases for the requirements it is possible for the developers to deepen their knowledge and thus helps them to understand the requirements better and a lack of clarity of the specification will be detected early. Furthermore, each developer will gain a better understanding of the whole software project which will also lead to better results when developing new features.
The presented practices mainly try to replace the direct communication within the team and the customer involvement throught the whole project which are core practices used in the agile software development but which cannot be achieved within an distributed environment. Although, the practices are only a trade-off which cannot replace the original practices it is important to adapt to these new practices starting as early as possible in the project to avoid misunderstandings within the teams.
Because every team is different it is not clear if these practices will completely fit your needs. You should start of with the presented practices and evolve your own practices from them so that the practices optimally fit your teams needs.
The next post will focus on the agile practices used in the development process of eclipse which is not only developed as an open source project but also within distributed teams.