Workflow and development in globally distributed mobile teams 海外で働く 東京 2018.02.16 Pawel Rusin 

Agenda ● Introduction ● Cookpad Global iOS project history ● Distributed teams - problems ● Distributed teams - solutions 

Introduction ● Pawel Rusin (twitter: @rusinpaw github: pauchan) ● Double majored in Robotics and Japanese studies in Cracow, Poland ● Came to Japan in February 2013 ● Bounced between iOS and Android projects ● Ads department till Sept 2016 ● Global iOS team since - team iOS ● Recently became technical product manager on Data Analysis squad 

Cookpad global iOS app highlights ● Existing project (started as 100% Objective-C) ● Converted to Swift in February 2015 ● Supports 14 different languages ● released in 148 countries 

No content

Communication 

Communication problems ● Physical disconnection ● Timezone differences ● Language barrier - 7 different countries (4 non-native English speakers) ● Structural boundries - while the same iOS team, different supervisors and different responsibilities 

Communication ● “It was a comunication problem” ● “I had no idea about this” ● “There was a language barrier” ● “I have no idea what you are talking about” ● “You should have told me earlier” ● “I don’t know who to ask” ● “I’ve misunderstood you” 

1. Solutions ● Hiring ● Flex / remote ● Squads ● Github ● RFC’s ● 1-2-3’s ● Automation ● Architecture 

1. Hiring ● “Hire good people and rest will follow” ● Right fit for the job ● good communicators ○ OSS community ○ strong peer review cultures ● structured interview 

2. Flex / remote ● No 9 - 5 ● Resolving timezone problem by adjusting your work schedule 

3. Squad based team structure 

3. Squad based team structure ● Two main benefits ○ Reduces timezone and location issues ○ Reduces task division issues 

4. GitHub as the main source of communication ● PR based workflow ○ PR’s and issues are basic place for tech discussion ○ PR’s are specs 

4. GitHub as the main source of communication 

4. GitHub as the main source of communication ● PR based workflow ○ PR’s and issues are basic place for tech discussion ○ PR’s are specs ● Code review as a way of knowledge sharing ● Github for onboarding / docs 

4. GitHub as the main source of communication ● [1/4] - Very light suggestion - "You don't have to change this. I'm just mentioning it." ● [2/4] - Light suggestion - "Please consider changing this, especially if someone else feels similarly." ● [3/4] - Suggestion - "Please change this, or provide some additional reasoning behind the decision not to. However, if you feel strongly about it and we can't come to an agreement, I'm still okay with it being merged as is." ● [4/4] - Serious suggestion - "Please change this. I feel very very strongly about it. I will not approve this PR until we have come to a compromise." 

4. GitHub as the main source of communication 

5. RFC's ● PR with: ○ outline - what problem are you trying to solve? ○ technical highlights ○ drawbacks ○ alternatives 

5. RFC's 

5. RFC's ● Communicate upfront ● Forces to consider alternatives ● Prepare for discusison ● History / documentation ● Tap the team knowledge pool 

6. 1-2-3’s 1. What will you work on today? 2. What’s the next thing on your pipeline? 3. What are you filling the gaps with? 

6. 1-2-3’s 

7. Automation 

7. Automation ● Fastlane ○ supporting release cycle, submissions ○ beta releases and prototyping ○ translations ○ gathering productivity metrics 

7. Automation 

7. Automation 

8. Architecture ● Moved from MVC to Clean Architecture ● Input - Output protocols ( https://github.com/kickstarter/ios-oss ) ● Coordinators ● Unit testing 

Why bother? ● Diversity FTW! ● Use the globalisation for our advantage ● Because we can