The lessons learned: quickly growing multiple distributed scrum teams.

1. Think business ● Build Software

2. Rapid growth &
Distributed scrum.
Experience of quickly growing multiple distributed scrum teams and
the lessons learned
David Sampimon, Project Manager

3. ABOUT ME
● Project manager for GlobalOrange for the last 3 years
● Before GlobalOrange I worked as a videogame producer (mobile and browser based)
● Now mostly working on SaaS applications for various clients (real estate, health, events,
local government)
● Over the past 1,5 years working on a distributed scrum project where we had to
quickly scale the team

4. Smart sourcing.

5. Case.
● Formed a partnership with GlobalOrange for IT development in 2012
● Back then a single scrum team
● Landed an investment in 2014
● Over the period we grew from 6 to 20 people on our end (and the client themselves
also grew the IT team with about 15 people)
● distributed scrum

6. ● Product team
● DevOps team
● QA team
● 2 scrum teams
● Scrum Masters
● Team leads
● Scrum teams and team
QA
● Scrum teams and team
QA

7. Model in numbers.
● Four scrum teams
● Four Product Owners working in NL (client)
● One lead developer in NL per team
● Half scrum master in NL per team
● Five dev’s per team in EE
● One QA per team in EE

8. WITH RAPID GROWTH
YOU WILL GET GROWTH
PAINS.
(but we know this already)

9. Risks.
● Talent management
● New hires
● On boarding
● (team) Motivation
● Communication
● Tooling
● Vision Sharing
● Bureaucracy
● Cost control
● Company culture
● Architecture
● Quality
● Maturity
(process)
● Management
feedback
● and more...

10. OFTEN UPFRONT
MANAGING OF ALL RISKS
RESULTS IN
MICROMANAGEMENT.

11. ….OR DON'T FIX IT IF IT
AIN’T BROKEN (YET).

12. So which pain points did
we experience?
● New hires
● Cost of communication
● Onboarding
● Friction between POs and team
● Spoon fed teams
○ Loss of bottom up innovation

13. New hires.
● Amsterdam, Romanian and Ukrainian IT labor market very competitive
● Aligned HR departments for a continuous talent acquisition, we were always
searching for new talent and never replacements
● Invested in standardized CV format and assessments
● Introduced the same hiring process everywhere:
○ Local HR interview => local tech assessment => interview with PM and same role
team member

14. Cost of communication.
● n(n − 1) / 2
○ Team of 6 = 15 lines of communication
○ Team of 40 = 780 lines of communication
● The team spread out over four locations wasn’t helping.
● Downsized distributed operations in Ukraine in favor of Romania

15. Onboarding.
● Good onboarding process is crucial for maintaining motivated and performing team
members or “You only get one chance to make a first impression”
● Standardize onboarding procedure with clear documentation into business case,
workflow, company values, who is who, first day exercises and personal
introduction

16. Friction between POs
and dev team.
● Normal scrum process creates friction between POs and Dev, which is good.
However, distributed scrum can push this friction too far
● Roadmap becomes crucial as an internal communications tool for alignment
● As a PO, don’t underestimate your expert knowledge of the system (too afraid to ask)
○ Write business case articles in confluence (wiki)
○ Invest in regular team presentations about the inner workings of your business

18. Spoon fed teams.

19. Spoon fed teams.
● As a result of an unclear roadmap (internally) and the vision mostly living in the POs
head, we experienced spoon fed teams
● Spoon feeding is killing the team in many ways
● We needed to get a mindset of ownership in the distributed teams

20. Micro
Management
Macro
Management
Co
Ownership
Followship X

21. Ownership.
● Promoted a local developer to team lead, the Dutch team leads became more
(architecture) consultants
● Invested in more frequent visits (team leads to NL, quarterly presentations in
Romania)
● Introduced a more BDD approach and involved the team lead or QA in the user story
writing process (scenario’s)
● Promoted bottom up innovation

22. Bottom up innovation.
● One of the most valuable activities - for any tech project - is developer driven
innovation
● Difficult to balance with bigger teams, especially distributed teams. Real risk of spoon
feeding your team members
● Hackathons
● Allowance for refactoring on their own initiative

23. And also.
● Think about physical evidence amongst your outsourced team, it is cheap to just ship
some cool banners and create a dedicated team room in their office
● Be transparent with your team members, talk about personal ambitions and growth.
If you want over achieving outsourced teams you need to treat them as internal staff

24. What didn’t work.
● There is a trend to give the scrum master responsibilities to the team lead. In our case
this didn’t work (match of personality) and was causing frustration in the teams. We
now are back to having separate scrum master roles in the teams
● Scrum of scrum sessions worked great as a way of achievement sharing, but not so
much for spotting cross team dependancies

25. Conclusion.
● Rapid growth and the distributed model can put a lot of pressure on productivity and
motivation
● Pay special attention to whom you hire and how you onboard them
● Ownership with distributed teams makes everything better
● If you want super performance from your distributed team, be transparent and talk
about their ambitions as if it is your own staff

26. Questions?