Scaling Agile and Working with a Distributed Team


Published on

The early agile literature was adamant about two things: stick with small teams and put everyone in one room. However, in the years since the Agile Manifesto, the increasing popularity of agile and the dramatic improvements it brings has pushed it onto larger and larger projects. Additionally, having an entire team--especially on a large project--in one room, or even one building is a luxury no longer enjoyed by many projects.

In this presentation, we will look at how agile can be scaled to work on any multi-team project. Even a project with two teams will benefit from learning how to proactively manage interteam dependencies, conduct iteration planning for multiple teams, cultivate communities of practice, and coordinating work. Because so many projects are spread across multiple sites we will also look at overcoming the unique challenges facing distributed teams. We will look at deciding how to distribute a team, how to create coherence among team members, the importance of getting together and when are the most important times to use the travel budget, changes to what the team documents, and how to handle meetings when spread across timezones. Whether your project is spread across two locations in the same city or spread around the globe, you will leave with practical advice to try tomorrow.

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Scaling Agile and Working with a Distributed Team

  1. 1. Scaling Agile with a Distributed Team Mike Cohn NDC London 6 December 2013 1 Scaling Issues Dependencies g Iteration planning meetin Coordinating teams ® © Copyright Mountain Goat Software 2
  2. 2. Proactively manage dependencies Use rolling lookahead planning Tasks Code the… Test the… Integrate with the… Code the… Design the… © Copyright Mountain Goat Software ® B Est. 8 16 8 12 8 Iteration 6 Iteration 5 Iteration 4 A 3 Share team members Feature team 1 Feature team 2 Feature team 3 • Be Component team ® cautious of sharing team members • There are drawbacks to the increased multitasking © Copyright Mountain Goat Software 4
  3. 3. Two types of interfaces to worry about Unattended interfaces At least one team is aware of the interface, but no one is doing anything about it Unidentified interfaces An interface that exists but that no one has discovered yet © Copyright Mountain Goat Software ® C 5 Use an integration team Takes on the unattended interfaces While on the look out for unidentified ones Can be a virtual team with part-time members Common up to perhaps a dozen teams Larger projects will have a full-time team Maybe more than one Not a dumping ground for poor performers ® © Copyright Mountain Goat Software 6
  4. 4. Scaling Issues Dependencies g Iteration planning meetin Coordinating teams © Copyright Mountain Goat Software ® 7 Scale up the iteration planning meeting Iteration planning meeting is the hardest to scale Other meetings require less coordination Two general approaches 1. Stagger by a day 2.The big room ® © Copyright Mountain Goat Software 8
  5. 5. The Big Room © Copyright Mountain Goat Software ® Nautical Meaning Our Meaning “I require medical assistance.” 9 “We need the product owner.” “We require assistance.” “We need the architect.” “We require a tug.” “We are dragging anchor.” ® “We require a pizza.” “We are on a break.” © Copyright Mountain Goat Software 10
  6. 6. Scaling Issues Dependencies g Iteration planning meetin Coordinating teams © Copyright Mountain Goat Software ® 11 Communities of practice Development team 1 Development team 2 Development team 3 Programming Community Test Community UI Community ScrumMaster Community ® A group of likeminded or likeskilled individuals © Copyright Mountain Goat Software 12
  7. 7. Characteristics of communities Self-organizing Organic Can span projects Not a full-time job There’s often a “community coordinator” Typically 5-20 hours/month © Copyright Mountain Goat Software ® 13 Five types of communities Unrecognized Invisible to the organization and possibly even to its members. Bootlegged Visible but only to a small, select group of insiders. Legitimized Officially sanctioned as a valuable entity. Supported Provided with resources (time, money, facilities, people). Institutionalized Given an official status and responsibilities in the organization. ® © Copyright Mountain Goat Software 14
  8. 8. Creating an environment for communities 1 Design for evolution. 5 Focus on value. 2 Open a dialogue between inside and outside participants 6 Combine familiarity with excitement. 3 Invite different levels of participation. 7 Create a rhythm for the community. 4 Have both public and private events. Scrum of Scrums 2–3 / week Scrum of Scrum of Scrums 15 1 / week © Copyright Mountain Goat Software ® Daily Scrums ® © Copyright Mountain Goat Software 16
  9. 9. Agenda Three questions (15 minutes at most) • • • What has my team done since we last met that might affect other teams? What will my team do before we meet again that might affect other teams? What problems are my team having that other teams might be able to help with? Discussion (as long as needed) • Discuss items kept on an Open Issues Backlog © Copyright Mountain Goat Software ® 17 Distributed teams •Decide how to distribute •Create coherence icate ® •Change how you commun © Copyright Mountain Goat Software 18
  10. 10. Collaborating collocated teams Each team has all needed skills Teams in different locations work independently but collaborate to coordinate their work Team 1 Team 2 © Copyright Mountain Goat Software ® 19 Deliberately distributed teams Each location has all needed skills We could form collaborating collocated teams But we choose not to Individuals in different cities work together as one team Team 1 Team 2 ® Team 1 Team 2 © Copyright Mountain Goat Software 20
  11. 11. Distributed teams •Decide how to distribute •Create coherence icate •Change how you commun ® © Copyright Mountain Goat Software 21 Creating coherence Coherent is from the Latin cohaerent “sticking together” We want a team that will stick together So we’ll Acknowledge big cultural differences Acknowledge small cultural differences Strengthen functional and team subcultures Build trust by emphasizing early progress ® © Copyright Mountain Goat Software 22
  12. 12. Create coherence ❶ Acknowledge cultural differences • Big cultural differences • Attitudes toward power, individualism, achievement, uncertainty, and long-term vs. short-term • Geert Hofstede found significant differences among IBM employees in these areas • Smaller cultural differences • Holidays • Working hours © Copyright Mountain Goat Software ® 23 More ways to create coherence ❷ Strengthen functional and team subcultures • Establish a shared vision • Establish working agreements ❸ Build trust by emphasizing early progress • Early emphasis on relationship building encourages subgroups to form around surface-level attributes† • Defer relationship building until team members have learned more significant things about each other †Gratton, Voigt, and Erickson. “Bridging Faultlines in Diverse Teams.” ® © Copyright Mountain Goat Software 24
  13. 13. Distributed teams •Decide how to distribute •Create coherence icate ® •Change how you commun © Copyright Mountain Goat Software 25 Get together in person Seeding visits Ideally, whole team meets in person at start Stay together an iteration or more when possible Contact visits Whole team, Quarterly, face-to-face Traveling Ambassadors Individuals who travel more frequently among locations to ensure good working relationships ® © Copyright Mountain Goat Software 26
  14. 14. Change how you communicate Add back some documentation Cannot rely as much on talking Add detail to the product backlog Encourage lateral communication © Copyright Mountain Goat Software ® 27 It’s not the distance, it’s the timezones 0 9,70 San Francisco London 300 miles 00 k m - 5 8,6 8 h o ur s km rs mile s mile hou - 10 , 20 0 00 - 60 10 km ur s 2 ho 16,4 00 s Cape Town ® © Copyright Mountain Goat Software 28
  15. 15. Useful advice for all meetings Include time for small talk Share the pain Make sure everyone knows who is talking © Copyright Mountain Goat Software ® 29 Iteration Planning—Approach #1 The Long Phone Call •Everyone on the phone at once Pros Cons • Can lead to good • People mentally • Planning is finished • Only feasible with discussion if people remain engaged in a day • Is consistent with approach used when collocated ® disengage during long calls significant overlap of workdays © Copyright Mountain Goat Software 30
  16. 16. Iteration Planning—Approach #2 Two Calls • First call: understand what the product owner wants built • Local subteams figure out what they can commit to • Second call the next day: Subteams share commitments Pros • Can be a more efficient use of time • Can be used whenever work hours can be made to overlap even a little Cons • Usefulness varies based on how widely distributed the team is • Not all knowledge is shared with everyone, leading to misunderstandings • Takes two days © Copyright Mountain Goat Software ® 31 Daily Standup—Approach #1 Single Call •Everyone on the phone at once Pros • Similar to what is done with collocated teams so there’s nothing new to learn • Discussions involve the whole team Cons • Can be extremely inconvenient for some • Not sustainable if people are forced to work outside of normal work hours • Everyone hears all issues, leading to greater commitment ® © Copyright Mountain Goat Software 32
  17. 17. Daily Standup—Approach #2 Writing the meeting • Everyone emails a written report or updates a wiki with status information • Variation: A local group meets and others email updates Pros • Sustainable over the long term • Helps overcome language problems Cons • No guarantee updates are read • Issues are not discussed and may lay dormant • Doesn’t take advantage of daily interaction to improve relationships and knowledge sharing • Reduced feeling of accountability to teammates © Copyright Mountain Goat Software ® 33 Daily Standup—Approach #3 Regional Meetings • Have separate regional phone calls, e.g., western hemisphere and eastern hemisphere • Follow these with a written summary shared between teams • Or have one person from each region also participate in the other calls Pros • Pain of off-hours calls is greatly reduced • Allows local subteams to share information most relevant to them Cons • Information relayed from one meeting to another may be incorrect or incomplete • Can lead to us/them feelings • Not everyone is involved in all discussions • Information may not be shared in timely manner ® © Copyright Mountain Goat Software 34
  18. 18. Mike Cohn twitter: mikewcohn (720) 890-6110 ® © Copyright Mountain Goat Software 35