Yahoo! Distributed Agile: Notes from the World Over
In an ideal world, everyone on an Agile team is collocated in one place, fostering cooperation and collaboration throughout the team’s growth. Unfortunately, the real world isn’t that simple. The current trend to fund teams split over multiple locations is inherently anti-Agile. Does this mean that we cannot do Agile with distributed teams? Distributed teams are a reality at Yahoo! In the past three years of coaching, we have seen creative solutions that that have allowed distributed teams to uphold the Agile Manifesto principle of people over process.
(above is for program)
The Agile Manifesto values people and interactions over processes and tools. However, the complexities of today’s business environments have led to the rise of development teams that span multiple continents and time zones. Under these conditions, it is easy to fall into the trap of establishing more controls and more process to handle the resulting loss of fidelity in communication brought about by the increased distance between team members. How can we uphold these values in such an environment?
Distributed teams are a reality at Yahoo! In the past two and a half years coaching various Agile teams at Yahoo!, we’ve seen some creative solutions that teams have come up with that allow them to still live up to the Agile Manifesto principles, in spite of the geographic and chronological distances.
The key principles that underscore the successful distributed Agile teams include: • Keep an even stronger focus on the people aspect of the teams. • Help the human dynamics succeed and use technology as an aid rather than a replacement • Minimize the pain, and if it’s not possible, distribute the pain evenly.
In this experience report, we will compare and contrast three very different distributed projects, outlining both the tactical practices used as well as their strategies for humanizing work.
Case #1: Podcast Distributed between Sunnyvale, CA and Bangalore, India 12.5 hour difference Each quarter, fly one team to another team’s location - one quarter, Bangalore folks flew to Sunnyvale - Next quarter, Sunnyvale folks flew to Banglore Review (of previous sprint and/or release) - Release planning - Two week sprint at location Local stands ups and planning rest of the time - Don’t force people to meet just for the sake of the stand up Key touch points between senior members of the team on a regular basis (e.g., Program Manager in India and Product Manager in Sunnyvale) - 3x a week during regular sprint cycles - Daily when closer to customer release Alternating pain: - Sunnyvale AM, India PM one day - Sunnyvale PM, India AM another day Human Dynamics: - Full team each quarter at locale to build relationships - Share in pain of flying, time difference for phone call meetings
Case #2: News Search Distributed between Santa Monica, CA and Trondheim, Norway 9 hour time difference, with Norway’s work day ending at 5:00 p.m., 6 at the latest Sprint planning meeting every two weeks: - 4:00 to 6:00 pm Norway, 7:00 to 9:00 for Santa Monica - 1 hour for review of previous sprint - 1 hour for Norway team and Santa Monica Product Owner to chat about upcoming Sprint backlog - get details of user stories, acceptance criteria. Discussion limited to getting as much info from Product Owner Next day: Norway team breaks down tasks for Sprint, comes up with sprint plan - One hour sync-up meeting (4-5 Norway, 7-8 Santa Monica) to convey Sprint commitment and have any lingering questions answered. - Scrum Master in Norway and Product Owner in Santa Monica have sync-ups at least 3 times a week - Pre-sprint backlog grooming - State of the sprint feedback (risks, trends) - Scrum Master asks as local representative of Product Owner Human Dynamics: - Minimize pain as much as possible by limiting time exposure - Increase communication based on the guiding principles behind the practice (e.g., collaboration on planning)
Case #3: Answers Team distributed between Santa Clara CA and London UK. 8 hour time difference - Each location has cross functional teams, which include Scrum Masters, Product Owners, Development and QA - Use of Scrum of Scrums twice weekly to cross communicate issues between locations - Use of wiki with digital photos uploaded daily of each teams’ information radiators (story board, burndown charts) - Shared demos using collaborative tools to display work - Use of video conferencing for key meetings like process retrospectives Human Dynamics - Make sure everyone has access to the same information, post everything to a shared collaborative workspace. - Use common times for meetings, even if it may be slightly uncomfortable for all involved - Reinforce the building of relationships by simplifying means of communication (instant messenger, telephone, video) and increasing frequency.
About the authors: JF and I are both coaches at Yahoo! and have worked with the teams directly to aid them in making their initial choices and in their processes to inspect and adapt. We selected these three projects because despite some obvious differences with locations, products and team sizes, we wanted to show some of the “universals” which occurred as a result of distributed agile. Going deep into one or even two may not fully reveal how practices needed to be adapted in keeping with agile values.