How do you transform from a small company with just a few people to one that's 60+ people strong, developing and operating multiple online games at the same time? The preentation covers: - the pains of introducing Scrum to the company - how to get the right people in the company and how to keep them - our solutions for knowledge and technology sharing across the teams - the importance of automation of the build and release process

1. Scaling
Online Game Development
Maciej Mróz
CTO, Ganymede

2. 39 M.
Registered Users
3.1 M.
MAU
70 K
New Registrations Per Day

3. OUR GROWTH
We started small, just like
everyone else.
Took us a while to get to ~30 people.
Then in 2012 we almost doubled our
headcount.
Made quite a few mistakes in the
process :(

4. 4
THE
'STARTUP
DECEPTION'
Startups are agile by nature.
Any formalities and hierarchies are just
overhead.
Fast and loose on both engineering and
product development.
Everyone knows each other, the product,
the customer.
Communication is very informal.

5. ... AND THEN IT ALL BREAKS DOWN

6. ... AND THEN IT ALL BREAKS DOWN
Growing complexity
of technology,
products, operations.
Unclear
and changing
requirements.
Product quality
becomes harder
and harder to maintain.
Development slows
down, morale suffers.

7. New employees are the first affected,
but the last to voice their concerns.

8. 8
OUR
MISTAKES
What we missed:
Formal hierarchy and clear responsibilities.
Development process.
!
Documentation.
Communication channels.
Employee onboarding and training.

9. THE BIGGEST MISTAKE
Assuming that things will work the same way
at 2x size!

10. WELCOME TO HELL

11. SCRUM
as standard development framework.
CORE TECHNOLOGY TEAM
STANDARDIZED
collaboration tools (issue
tracker, source control, code
review, continuous integration).
AUTOMATE EVERYTHING
that's repeatable.
EDUCATE
our employees!
TAMING THE CHAOS
CHAOS

12. WHY SCRUM?
15

13. WHY SCRUM?
15
Extremely good
fit to online gaming where
iterative approach to
development is the norm.
Simple,
almost minimalistic
framework.
Most
developers
have at least vague idea
of how it works.
Training
and resources
are widely available.

14. SCRUM TRAINING
Sprint
RETROSPECTIVE
Story
points
PRODUCT
OWNER
Task
SUCCESS
charts
Backlog
GROWTH
SCRUM 
developers

15. SCRUM
TRAINING
Probably the most misunderstood
framework in software engineering.
Knowing Scrum Guide and understanding it
are two different things.
Reading a book on agile software
engineering is not enough!
Don't assume anything, train everyone!
Get external help, it is worth it.
SCRUM 

16. THE TRAPS
IT'S NOT FOR EVERYONE,
lone wolves may find it difficult to adjust.
THE SPRINT
must become the heart beat of the company, and it takes time.
BROKEN IMPLEMENTATIONS
can do more harm than good.
CHANGING THE ORGANIZATION
is going to meet resistance.

17. THE REAL CHALLENGE
It’s not the
development teams!
Job positions
and responsibilities must be changed.
(Not everyone is going to be happy about it).
Getting business
people to understand technology is hard.
So is getting tech people
to understand business.
Product people
require even more training than developers.

18. DO IT EARLY
If we were doing it again it would be a
lot earlier!
Introducing Scrum late is extremely painful.
Old habits die hard.
Prepare yourself for a marathon.

19. IN OUR CASE
it took ~18 months to see the benefits

20. INDEPENDENT
TEAMS
Keep decisions decentralized, track only high
level KPIs.
Product teams are cross functional.
• Programmers, designer, artist, tester,
analyst...
Product teams must really be in charge.
Our development teams are responsible for
product operations.

21. KNOWLEDGE/
TECHNOLOGY
SHARING
Core technology team (application server,
tools, standards).
SIGs/tribes (Spotify as an inspiration).
• QA, analytics, server side development.
• Can only be encouraged.
Central Wiki for storing documentation -
everyone sees (almost) everything.
GitHub-like development model (we use
GitLab) - everyone can see and use code from
other teams.
On the backend moving towards
microservices.

22. Automation
Builds
• Repeatable build straight from source
control is probably the most important
thing you can do!
Deployments, Rollbacks.
Setting up/tearing down servers.
Calculating common KPIs across all products.
AUTOMATION

23. EMPLOYEE EDUCATION
Mix of junior and senior people.
Employee onboarding and training becomes
full time job.
• Technical, process, business knowledge.
Recruitment becomes a constant process,
not ad-hoc activity.
Getting the right people in (and wrong people out)
is a challenge.
Better to stay small than grow unprepared.

24. GROWTH MUST BE PLANNED
Make changes in
advance
The solutions for
successful growth
span every aspect of
the company
The balance is hard to
keep
Do not overdo it,
some things do not
make sense at
small scale

25. SCALING IS NEVER
REALLY DONE
There's no silver bullet.
Many things affecting how we work:
• product portfolio, our users, keeping
employees happy.
Being more efficient vs having shorter cycle
time.
Cross functional teams vs silos - we are a
hybrid!
What works today, doesn't have to work for
you tomorrow.

26. THANK YOU
mmroz@ganymede.eu
@maciejmroz