Agile methodology emphasizes collocation of Agile team members, because they can meet face-to-face daily to discuss status across the entire project, show one another the exact steps required to reproduce a bug, understand at first hand why the business analyst feels that the acceptance tests are not validating the business logic, etc. Splitting an Agile workgroup into two or more groups, whether they are within the same building or on opposite sides of the globe, therefore seems “anti-Agile”, and we might expect them therefore to fail. However, we have seen “distributed Agile” work, where Agile guidelines are adjusted so that its other advantages, e.g. continuous integration, short cycles, guaranteed delivery of working code, etc., are realized despite the loss of high bandwidth in communication. This paper will describe models of distributed Agile that have worked, and some that did not, and proposes that success depends upon the manipulation of a few underlying dynamics in Agile methodology. The author also presents some guidelines for adapting the Agile approach to specific project requirements.