Scrum & Kanban for Social Games

  • 15,970 views
Uploaded on

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 …

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
15,970
On Slideshare
0
From Embeds
0
Number of Embeds
9

Actions

Shares
Downloads
586
Comments
4
Likes
61

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. + Scrum & Kanban For Social Games Sönke Bullerdiek Senior Project Manager May 27th 2011
  • 2. 2Agenda  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  
  • 9. Techcrunch:    “wooga  is  figh0ng  the  good  fight  for  Europe”  
  • 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  
  • 12. Weekly  itera0ons  based  on  analy0cs   12  
  • 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 minReached  lvl  3   5 min 0%   10%   20%   30%   40%   50%   60%  
  • 15. DAU  August  2010  1.200.000  1.100.000  1.000.000   900.000   800.000   700.000   600.000   500.000   400.000   300.000   300.000   200.000   100.000   0   May-­‐10   Jun-­‐10   Jul-­‐10   Aug-­‐10   Sep-­‐10   Oct-­‐10   Nov-­‐10   Dec-­‐10   15  
  • 16. Weekly  itera0ons  and  always  adapt  your  product  and  process  to  changing  circumstances  leads  to:   16  
  • 17. DAU  end  of  2010  1.200.000  1.100.000  1.000.000   900.000   800.000   700.000   600.000   500.000   400.000   300.000   200.000   100.000   0   May-­‐10   Jun-­‐10   Jul-­‐10   Aug-­‐10   Sep-­‐10   Oct-­‐10   Nov-­‐10   Dec-­‐10   17  
  • 18. How  did  we  start?   18  
  • 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  
  • 20. How  did  the  team  start?   20  
  • 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. 41Thank  you  for  your  axen0on   Sönke  Bullerdiek   soenke.bullerdiek@wooga.com   wooga.com/jobs