The Distributed Agile Game
Download session PDF
Add to calendarWhen it is achieved together, the combined benefits of both Agile and Offshore software development, can be multiples greater than either approach alone. During this interactive session, we will simulate a distributed project with some participants being onsite and the others offshore. With 4 teams of upto 8 people each, this game will draw out learning around the challenges of Distributed Agile and different methods to communicate successfully on such projects. The rules of the game help illustrate how to deal with travel, different timezones, delayed communication and other such hurdles.
This session has been presented with success at the Agile 2009 conference. This is a paired talk between Chirag Doshi and Sumeet Moghe. The game is meant to be played by people who will be involved in a distributed development environment. The participants may have prior experience in distributed development, but this is not required. In fact, prior software development experience is not even required. The game is played with small teams. Each team consists of Analysts and Developers, with one Customer located ‘onsite’.
Each team is divided into two parts. Team A and Team B. Team A is ‘onsite’, meaning the customer is present. Team B does not have the Customer present at the same location and can only communicate with the Customer and onsite Developers via email and telephone (talking through a partition).
| Activity | Elapsed Time |
|---|---|
| Set context of distributed development: Facilitators will explain here, what distributed development means and what the constraints usually tend to be. We will also talk about the possible benefits of distributing work and indicators of success/ failure. | 0:10 |
| Break into teams and explain exercise | 0:20 |
| Release Planning / I1 Acceptance Criteria: The project teams will now discuss the pre-written User Stories to draw up a Release Plan for the Product. This time will also be used to plan out Iteration 1 and decide on Acceptance Criteria for the Iteration 1 stories. | 0:30 |
| First Iteration: The game is played in fifteen minute iterations with standard limitations placed to indicate difference in timezones, travel constraints and client/ team communication issues. The Customer has final say in accepting the product that is delivered. The teams have to deliver the product to the client site in order to consider a successful delivery. The teams much accommodate the travel time required in order to deliver the developed product to the customer. If at the end of the allocated time the developed prototype is not shown to the customer at site, it is considered a failed deployment. | 0:45 |
| Showcase: At the end of each fifteen minute iteration, a showcase of functionality will occur. It will be led by either the onsite or offsite team depending on what team’s agree, but should show a ‘flow’ of the screens created, and a discussion of whether each screen meets the acceptance criteria. If the screens meet the criteria, the customer will ‘pass’ the card. If they don’t, the card must be played in the next iteration. If new requirements are found, new cards must be created and prioritised in the release plan. | 0:50 |
| Retrospective: At the end of each showcase, all Team A’s and all Team B’s will gather separately for a retrospective. Team A’s and Team B’s are responsible for communicating retrospective results to their opposite site team members after the fact. Customers will be honest about how they felt things went during the iteration, and it is expected that the next iteration will have learned from the previous retrospective. | 1:00 |
| Second Iteration: | 1:15 |
| Showcase | 1:20 |
| Retrospective | 1:30 |
| Third Iteration | 1:45 |
| Showcase | 1:50 |
Project Retrospective: The teams will discuss their learning and dynamics during the exercise. Things to look out for -
|
2:10 |
| Game Conclusion & Summary of Learning: At the end of the game, the Customer subjectively grades the team for how much the final product conforms to the Customer’s requirements. The customers and coaches will share feedback on the patterns and antipatterns that they observed during the development process. | 2:40 |
Close:
|
3:00 |
Venue Requirements: A partitionable room, whiteboard and enthusiastic participants! In the absence of a partitionable rooms, we can try false partitions using whiteboards, etc. We’ve tried in the past to separate people by having some teams sit outside the room (in such cases a noise free environment usually helps). We’ve also tried to have people sit back to back (though it isn’t my favorite method!).
- By the end of this session, the participants should be able to:
- Explain some of the logic that goes into deciding how to distribute work across locations
- Explain how it is often easier to work at the ‘onsite’ location
- Explain how increasing the distance between team members impedes opportunities for communication
- Explain how lack of visual contact can be detrimental to relationship building
- Explain how and why it is important to share information across team boundaries
- Explain why it is important to continually build a good relationship with the customer
- Explain why it is important to continually build a good relationship with other team(s)
- Explain the different methods of communication that can be used in distributed projects and how to use them successfully
- Explain different ways you can build relationships with customers and other teams that are not at your site