This paper discuss experiences and lessons learned in doing offshore agile development.

The author recounts experiences of applying XP to a large projects and how analysts participate in the XP team. This paper outlines a project which had multiple development teams using mulitple software development processes. The paper discusses how an XP team can be integrated with team using more formal methods using techniques such as Integration Pairs, Interface Story Cards and Interface Task Cards.

The generally accepted ideal of XP has an expert customer representative on the site with the programming. This paper presents strategies for working in less-than-ideal situations with either a remote customer or multiple customers.

This fairly detailed case study of an outsourced XP project describes the approach taken by the team and the modifications they made to standard XP.

For the last four years we have operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we've discovered that we can make it work, although the benefits are still open to debate.

In modern software development there are two trends that allow people to get more for less: agile development and offshore outsourcing. Agile processes are traditionally implemented in one site, where customers and developers can meet face-to-face and communicate easily. Offshore development projects, on the other hand, are traditionally implemented as fixed-bid consulting agreements, executed either using waterfall processes or at best in iterative way. However, it is possible to use agile software development process when working with offshore teams. Our successful projects have employed a mix of agile techniques and organizational models.

In modern software development there are two trends that allow people to get more for less: agile development and offshore outsourcing. Let’s look at how and when to successfully combine both to raise the competitiveness of your business

This article analyzes and recommends new best practices for globally
distributed Agile teams based on two real-life projects.

Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increases the problems, and makes even great demands on the requirements specification. The payoff for doing good requirements is greater, and the penalty for not doing them is more threatening.

I am going to argue that we need to make use of far more explicit background specification for each requirement, a page or more of specification for each requirement. I will argue that this is a necessary investment – because failure to do so will probably cost far more – sooner or later. I will argue that failure to be more detailed than normal will be counted in the clients disfavor in any legal proceedings trying to determine responsibility for failure of the project.

How do you manage the history of data in an open, decentralized system, like for example the Internet? CVS, Subversion, WebDAV or versioning file systems help you to remember old versions on one specific server. GIT, Mercurial and others let you do that in a decentralized, less dependent way, but the data needs to be managed in individual projects. In documentation systems, like Wiki servers, CMS systems, data history is seen as a key feature. These histories are managed centralized and scoped on one document only. In this article I'm going to analyze different aspects of the data history in a decentralized system and try to model a corresponding concept.