Think business ● Build Software

Rapid growth & Distributed scrum.Experience of quickly growing multiple distributed scrum teams and

the lessons learned

David Sampimon, Project Manager

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

Smart sourcing.

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

● Product team

● DevOps team

● QA team

● 2 scrum teams

● Scrum Masters

● Team leads

● Scrum teams and team

QA

● Scrum teams and team

QA

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

WITH RAPID GROWTH YOU WILL GET GROWTH PAINS.

(but we know this already)

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...

OFTEN UPFRONT MANAGING OF ALL RISKS RESULTS IN MICROMANAGEMENT.

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

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

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

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

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

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

Spoon fed teams.

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

MicroManagement

MacroManagement

CoOwnership

Followship X

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

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

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

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

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

Questions?