This tutorial focuses on the detailed specifics that will make distributed agile meetings effective. We will demonstrate several key agile meetings, run in a distributed fashion, so teams can immediately improve their projects. To do so, I will highlight specific tools available in the market place to facilitate each of these different kinds of discussions (retrospectives, planning meetings, stand ups). I’ll demonstrate the processes to enable more effective communication between remote locations and describe the key roles required on a project to encourage the best exchange of information.

Can my large, geographically distributed, systems program benefit from agile development methods? Absolutely. This talk presents real-world experiences applying agile practices to large, systems projects with a high degree of governance. The practices discussed are technical (continuous integration, test-driven development, user stories) and non-technical (communication, welcome changing requirements, frequent collaboration). And it presents several challenges we experienced while scaling agile practices and changes we hope to make on future programs.

Is it possible to SCRUM the development of a large software system with contributing teams spread out over three cities, five partners, six sites, and a six hour time difference? It started with vague and ambitious objectives and was built on bleeding edge technologies (grails, flex). By all rights we should have fallen flat on our faces. But a year after its dubious beginning, our project continues. Join us as we present the good, the bad and the ugly of distributed team projects.

Tim and Tim discuss tools and techniques and observations for remotely pair-programming. Various remote desktop-sharing applications and services are discussed, dissed, and recommended along with pointers and practices for logistics. Learn the downside of distant partners. How do you have a flash architecture meeting? How do you collaborate with the team? When do you take breaks? Is it really just like being there, without the smells?

This is a journey starting in 2005 when establishing a new software company in Bangladesh 7000 km away from Denmark. Hiring 20 people in one week in Bangladesh and start using CMMI processes to integrate development in Denmark and Bangladesh. After some challenging time aborting the CMMI project and switching back to agile and lean techniques to make it work. Experience from implementing global big bang Scrum and building a kaizen culture. From long running projects, technical dept and integration nightmares to small batches, continuous integration and faster delivery of business value.

This tutorial focuses on lessons learned from our experiences in implementing Agile in teams across different time zones in large companies. We will share the pleasure and the pain, ideas that worked as well as ideas that didn’t. We will share what we feel are the critical success factors in making program level implementations successful and sustaining. This is more than an experience report - we share templates, pictures, lessons learned for leveraging technology, managing multiple time zones, recommendations for metrics and reporting, and ideas for future program level success.

Participants will discuss the use of virtual worlds with agile teams. Examples will be interjected from an agile project at State Farm where a virtual world was used to collaborate with team members in multiple locations. The session will end with a brief demo.

The discussion will include:
1. Necessary qualities for collaboration to occur 2. Obstacles to achieving this on a distributed agile team 3. Using a virtual world on an agile project 4. Best practices for leveraging a virtual world 5. State Farm’s use of virtual world environments with agile teams

The authors previously showed Scrum teams using XP practices achieved distributed velocity equal to local velocity with multiple distributed teams. Local velocity equaled distributed velocity and production increased linearly as teams scaled up to over 50 developers. Here we show a similar pattern for extreme time zone differences between San Francisco and India. Local velocity was established at five times industry average waterfall velocity. When team members were added in india, production scaled linearly.

One of the core values of the Agile Manifesto is favoring “Customer collaboration over contract negotiation”. Unfortuntely, product companies with thousands (to millions!) of customers can find collaborating with their customers nearly impossible, as few tools exist to explicitly support meaningful customer collaboration. This workshop explores the advantages of including your customers as part of your distributed team and some of the tools that are emerging to enable agilists to better collaborate with their customers. Bring your laptop, as we may be trying out some of these tools.

As individuals we work in transient isolation to reduce the impact of work in progress on each other. Organizations isolate WIP by using only official versions of 3pty sources and by producing official releases for customers.

Multi-stage continuous integration (MSCI) scales CI to large distributed environments by isolating work in progress at the team level. Changes move from individual to team to mainline as fast as CI allows, but stop on failure.

MSCI is particularly important in a distributed environment where fixes to problems exposed by CI can be delayed by a full day.