Originally Monster World was developed with Scrum. The scrum process resulted in some inefficiencies and missing flexibility. Hence, some elements of Kanban were introduced. In this talk, we present the experience of this Scrum/Kanban mix which has been used for 6 months.
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Scrum & Kanban for Social Games
1. +
Scrum & Kanban
For Social Games
Sönke Bullerdiek
Senior Project Manager
May 27th 2011
2. 2
Agenda
n 1.
Introduc0on
n 2.
Con0nuous
improvement
needs
flexibility
n 3.
How
did
we
start?
n 4.
Problems
n 5.
Quick
Kanban
introduc0on
n 6.
How
do
we
work
now?
n 7.
Conclusion
31.05.11
3. wooga
–
world
of
gaming
Sönke
Bullerdiek
Senior
Project
Manager
About
wooga
Key
stats
Founded
January
2009
5
games
on
Facebook;
Over
30m
ac0ve
users
Funding:
Founders,
Balderton
Capital,
Biggest
European
social
game
developer
Holtzbrinck
Ventures
(total
of
€5m+)
Only
5%
of
users
from
adver0sing
Interna0onal
team
of
85
70%
of
users
are
female
(age
20-‐60)
from
20
countries
in
Berlin
About
Monster
World
Key
stats
Launched
May
2010
Hosted
at
Facebook
Biggest
seller
of
magic
wands
in
the
Flash
client
world
Ruby
on
Rails
backend
Total
team
size
is
12
MySQL
+
Redis
DB
3
4. #1
§ Launched
July
2009
§ Biggest
brain
training
game
on
Facebook
5. #2
§ Launched
February
2010
§ Top
20
Facebook
game
§ Pop
colourful
bubbles
and
explore
the
secrets
of
a
mysterious
island.
6. #3
§ Launched
May
2010
§ Top
20
Facebook
game
§ Grow
crazy
plants
and
build
your
own
unique
Monster
Garden.
7. #4
§ Launched:
December
2010
§ Cure
cute
pets
of
funny
diseases
while
building
your
own
pet
hospital.
8. #5
§ Launched:
March
15
§ Click
as
many
gems
as
possible
in
60s
§ Already
a
top
20
Facebook
game
§ Fastest
growing
Facebook
app
today
10. Overview:
n Our
goal
as
a
company:
n Be
one
of
the
largest
gaming
company
in
10
years
n No
long
term
planning
n We
plan
as
a
company
usually
12
weeks
(posters
show
the
goal)
n Product
vision
is
planned
roughly
for
3
weeks
n We
break
this
down
to
weekly
itera0ons
n These
layers
(company
–
strategic
&
product
–
agile
team)
are
deeply
linked
Company
Layer
Product
Layer
long
term
10
years
3
months
short
term
3
months
1
week
n This
presenta0on
is
about
the
product
layer
10
11. Con0nuous
improvement
needs
flexibility
n Everybody
keeps
an
eye
on
the
metrics
n Improvement
with
con0nuous
tes0ng
and
a/b
tes0ng
n Flexible
and
agile
teams
11
13. Analy0cs:
We
provide
a
great
user
experience
by
obsessing
on
metrics
Step
New
users
(last
24h)
38.863
01
-‐
Flash
begin
(0%)
93,0%
02
-‐
Flash
complete
(100%)
86,5%
03
-‐
Tutorial
–
first
harvest
completed
82,7%
Example:
1.3%
drop
is
deemed
04
-‐
Tutorial
–
first
plan0ng
completed
82,5%
unacceptable
05
-‐
Tutorial
–
Mr
T’s
magic
applied
81,1%
and
game
is
06
-‐
Tutorial
–
second
harvest
compl.
79,8%
op0mized
07
-‐
Level
2
reached
79,6%
accordingly
08
-‐
Tutorial
completed
(plowing)
79,4%
09
-‐
Level
3
reached
78,8%
10
-‐
Level
4
reached
77,5%
11
–
Level
5
(or
higher)
reached
77,2%
13
14. A/B
test:
Growth
0me
of
lemonade
bushes
5
min
=>
3
min
7
day
ret
3
day
ret
1
day
ret
Reached
lvl
4
3 min
Reached
lvl
3
5 min
0%
10%
20%
30%
40%
50%
60%
19. Current
team
structure
DEV DEV
PM
GFX
n 3
Product
Manager
BE
BE
n 1
Project
Manager
n 2
Backend
Developer
DEV
QA
PM
GFX
FE
n 2
Flash
Developer
n 1
QA
DEV
Proj
n 3
Graphic
Designer
PM
GFX
FE
M.
n ALL
in
one
room
and
close
to
each
other
to
ensure
communicaFon
and
transparence
n Independent
team
structure
with
dedicated
resources
for
every
game
19
21. Small
process
improvement
over
0me
1. Get
rid
of
Jira
and
use
Google
Spreadsheet
as
planning
tool
2. No
huge
technical
specifica0ons
–
all
is
done
within
the
sprint
kick-‐off
(max
some
PPT
slides)
3. We
build
up
an
complete
internal
team
4. We
started
color
coding
for
different
features
in
the
spreadsheet
5. Skype
chat
for
asynchronous
communica0on
also
inside
the
room
6. No
task
should
be
larger
than
2
days
7. SCRUM
board
only
for
backend
(since
there
were
all
members
in
the
room
–
half
of
FE
team
was
external
at
that
0me)
21
22. But
this
was
not
enough…
n Since
we
worked
in
a
very
good
way
with
SCRUM
the
last
months,
we
realized
that
there
are
challenges
which
do
not
fit
to
SCRUM
n A
very
good
example
are
daily
opera0onal
issues
or
n major
bugs
that
came
up
n they
need
to
be
done
as
priority
number
one
and
usually
the
whole
fixed
sprint
plan
is
mixed
up.
n This
is
why
we
started
to
introduce
KANBAN
elements
22
23. Problems
with
SCRUM?
n SCRUM
is
very
strict
from
a
mindset/process
n End
of
itera0on
is
a
gap
since
there
is
nothing
in
a
backlog
before
next
planning.
Kanban
has
always
issues
in
the
pipe
n No
ongoing
development
everyday
of
the
week
(e.g.
planning
day)
n No
re-‐priori0za0on
during
a
sprint
(Kanban
allows
ongoing
re-‐
priori0za0on)
23
24. KANBAN
-‐
a
quick
introduc0on
n “Kanban
is
part
of
an
approach
of
receiving
the
"pull"
from
the
demand.
Therefore,
the
supply
or
produc0on
is
determined
according
to
the
actual
demand
of
the
customers.“
n Original
idea:
block
of
paper,
on
the
second
last
it
says
“you
have
to
order
paper”
n All
rules
are
very
intui0ve
n Change
a
requirement/priority
un0l
a
feature
is
not
in
development
n Easy
rules
like
pull
to
the
right
n Focus
is
to
finish
issues
n If
there
is
a
boxle
neck
more
developers
go
to
a
feature
n Pull
leads
to
ongoing
priori0za0on
and
changes
of
requirements
/
backlog
during
a
sprint
as
long
a
card
is
not
in
development
n Solu0on
for
us:
integrate
Kanban
elements
in
Scrum
24
25. Integra0on
of
KANBAN
into
SCRUM
n Management
+
product
owner
sees
process
like
SCRUM
internally
its
Kanban
n We
will
keep
our
weekly
itera0on
for
major
product
features
because:
n this
is
the
heartbeat
of
our
development
n this
gives
the
team
and
the
company
planning
reliability
n We
keep
our
exis0ng
mee0ngs
since
they
were
very
posi0ve
and
helpful
in
the
past
(e.g.
daily
stand-‐up
–
more
later)
n This
leads
to
the
current
process
elements
on
the
next
slides
25
26. Scope
n Include
tasks
that
can
not
be
scheduled
in
SCRUM
like
all
opera0onal
emergencies
and
emergency
bugs
n No
task
should
be
larger
than
2
days
and
a
feature
should
fit
into
one
itera0on
(minimum
viable
product)
n No
up-‐front
in
detail
es0ma0on
before
itera0on
-‐>
Kick-‐off
at
Kanban
during
itera0on
n to
handle
general
features
n to
handle
opera0onal
issues
in
a
later
phase
of
the
game
n to
handle
spontaneous
changes
from
usability
or
a/b
tests
n we
s0ll
need
to
do
this
for
large
tasks
roughly
to
break
them
down
into
our
weekly
itera0on
26
27. Higher
flexibility
n Release
a
feature
whenever
it
is
ready
n Most
important
tasks
are
started
as
soon
as
possible
n Since
we
no
longer
NEED
to
do
itera0on,
we
do
not
have
to
wait
for
the
next
itera0on
in
order
to
re-‐shuffle
priori0es
before
star0ng
development.
n more
freedom
for
changing
priori0es
by
product
managers
and
most
important
items
can
be
finished
sooner
Scrum
Kanban
Do
not
change
the
sprint
log
Do
not
change
a
feature
if
it
is
during
an
itera0on
already
in
development
27
28. Progress
Visibility
n The
whole
development
status
and
planning
is
visible
on
a
board
for
all
team
members
n Integra0on
of
progress
updated
in
daily
standup:
n Much
easier
to
track
and
update
progress
on
board
(every
team
member
will
change
the
status
of
their
own
task)
than
in
Excel.
n We
have
magnets
with
pictures
of
all
team
members.
n Lower
barrier
to
visualize
tasks
by
wri0ng
a
card
(before
more
tasks
stayed
"invisible")
28
29. Transparence
n Visualize
whole
value
chain
at
the
board
and
n not
only
development
(including
emergency
tasks
and
bugs)
n so
more
transparency
for
tasks
then
in
Google
spreadsheet
n Flow
related
problems
(boxlenecks)
become
more
easy
to
grasp/
visible
using
a
board
than
a
list
only
n We
see
what
different
tasks
(technical
vs.
product)
we
do
29
30. Kanban
Board
Concept
in
Development
Development
in
IntegraFon
Staging
test
in
Ready
for
Done
progress
Backlog
waiFng
progress
test
in
progress
(test
Release
for
Kick-‐off
progress
(test
on
branch)
on
trunk)
Product
Graphic
Frontend
Technical
Backend
30
31. Kanban
Board
–
next
itera0on
Concept
in
Development
Development
in
IntegraFon
Staging
test
in
Ready
for
Done
progress
Backlog
waiFng
progress
test
in
progress
(test
Release
for
Kick-‐off
progress
(test
on
branch)
on
trunk)
Product
Graphic
Frontend
Technical
+
Backend
31
32. Real
Board
w/
different
colors
and
personal
magne0c
s0ckers
32
33. Monster
World
Process
Monday
Tuesday
Wednesday
Thursday
Friday
QA
Release
Code
Freeze
+
Planning
Development
Development
Development
Development
Development
n Weekly
Sprints
n Code
freeze
every
Friday
evening
n 1
day
QA
on
Monday
n Major
release
every
Tuesday
n Daily
minor
releases
/
patches
n Now
we
have
development
on
all
days
33
34. Process
Diagram
Idea
Concept
Kick-‐Off
(dev+prod)
Backend
Frontend
Graphic
Int.
Test
Stag.
Test
Ready
to
Release
Release
34
35. Weekly
Progress
Mee0ng
n Current
version
+
next
version
overview
n KPI
overview
n Whole
company
can
axend
n Limited
to
15
minutes
35
36. Daily
Scrum
Stand-‐Up
Mee0ng
n Track
progress
and
status
at
the
Kanban
board
n Whole
Monster
World
Team
n What
was
done
yesterday
/
What
is
in
Progress
/
Any
issues
n 5-‐10
minutes
36
37. Product
Backlog
and
Priori0za0on
n Weekly
before
Development
Backlog
Presenta0on
n Decide
major
product
roadmap
and
product
priori0es
n MW
Product
Team
+
Management
+
2
Developer
n 1
hour
37
38. Kick
Off
Mee0ngs
n Per
task
n Shortly
before
start
of
development
n Final
effort
es0ma0on
n All
team
members
who
can
support
the
task
n 5-‐30
minutes
38
39. Conclusions
n Have
independent
team
structure
with
dedicated
resources,
all
located
in
one
room
n Agile
is
all
about
self
organiza0on
–
this
needs
people
who
can
self
organize
and
are
moFvated
39
40. Conclusions
n Check
azer
launch
of
a
game/sozware
with
Scrum,
if
the
methodology
s0ll
fits
if
something
changes
(e.g.
opera0on),
otherwise
change
your
methodology
n Always
check
and
ask
yourself
if
it
is
the
op0mal
way
how
it
works
and
have
the
courage
to
do
changes
in
all
processes
n Have
a
good
balance
in
your
processes
between
flexibility
and
stability
Plan
Act
Adapt
40
41. 41
Thank
you
for
your
axen0on
Sönke
Bullerdiek
soenke.bullerdiek@wooga.com
wooga.com/jobs