We are hearing more and more on Agile software development projects XP, Extreme Programming. Without being related to big projects, this methodology is used in significant-one that are mostly carried out internally, but in this post I will give you the keys to achieve a successful offshore Agile project.In the case of a classical V cycle-based project, drafting the functional requirements is done prior to the technical specifications. Then come the conception, unitary tests, coding, tests and finally the validation. All these phases unfold one after another. Even with intermediate deliveries, this cycle can last for several months.The objective of the Agile method is to reduce as much as possible phase compartmentalization, thus allowing to shorten the cycle drastically in order to have frequent and relevant deliveries. XP is governed by several rules that everybody can adapt to his own environment.One of the keys for a successful project is the closeness between functional and technical participants. But in an offshore project, this is contradictory. Communication tools are thereby fundamental to improve closeness because in this type of project, the exchange of information and its traceability become critical. The use of a wiki can effectively meet this type of demand for it avoids fixed structure constraints. Also,Web Conferencing tools are useful for daily meetings in order to assess the current situation of the project (problems encountered, etc). Dreaded events in fixed price projects (modifications, misunderstanding, etc) become recurrent and a token of good project dynamics. Still, the fundamental criterion for a successful project is the implication or availability of the functional participants (contracting owner); but it is not easy with the distance between the teams. When starting a project, wishful thinking and hopes are often faced with a reality that was forgotten in the euphoria of the beginning. One should not forget that the Agile method is an equivalent to just-in-time production management. A lack of information can result in a stuck team waiting for more specifications. With the Agile method, the technical requirements and specifications are not completely drafted at the beginning, but this effort will be spread along the project.As for all projects, the starting phase is critical. The users (or their representatives) must be carefully coached in order to guarantee the coherence of an homogeneous system: the expected solution. Indeed, to keep a common purpose, all the participants must refer to the same identical framework that will not be as precise as specification sheets would be. The coach must make sure that the successive demands are in accordance with the initial purpose. This is not a matter of scope because this type of organisation must allow an evolution of the scope of work thereby meeting the reactivity needs of the projects for which the time to market has to be as short as possible. The development team has to be familiar with this type of project. There are lots of developers and project managers dreaming of projects where changes and events would not exist. But Agile projects are made of changes only. Therefore, team members must have experience working on “classical” projects in order to adapt more easily. An Agile project cannot be based on a fixed price contract. Therefore managers will not have a complete view on the project. However, regular reporting (dimensions of the identified scope of project, to-do list, roadmap for the solution, …), using clear indicators for everyone, is very important. The budget cannot be a blank cheque. It is therefore essential that decision-makers interfere in major orientation changes and events that impact on the budget. So, the traditional steering committees are still necessary.As a conclusion, there is no big difference between an offshore and an onshore Agile project. Besides the financial matter, efficiency means enjoying good mutual understanding between the participants and using the right tools (knowledge sharing, Web Conferencing, …).