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 ﬂexibility 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 ﬁgh0ng the good ﬁght 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 ﬂexibility 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 – ﬁrst harvest completed 82,7% Example: 1.3% drop is deemed 04 -‐ Tutorial – ﬁrst 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%

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 ﬁt 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 ﬁxed 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 ﬁnish 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 ﬁt into one itera0on (minimum viable product) n  No up-‐front in detail es0ma0on before itera0on -‐> Kick-‐oﬀ 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 diﬀerent 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-‐oﬀ 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-‐oﬀ progress (test on branch) on trunk) Product Graphic Frontend Technical + Backend 31

32. Real Board w/ diﬀerent 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-‐Oﬀ (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 Oﬀ Mee0ngs n  Per task n  Shortly before start of development n  Final eﬀort 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 ﬁts 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 ﬂexibility and stability Plan Act Adapt 40

41. 41 Thank you for your axen0on Sönke Bullerdiek soenke.bullerdiek@wooga.com wooga.com/jobs

Scrum & Kanban for Social Games

Scrum & Kanban for Social Games

Recommended

More Related Content

Viewers also liked

Viewers also liked(20)

Similar to Scrum & Kanban for Social Games

Similar to Scrum & Kanban for Social Games(20)

More from Wooga

More from Wooga(20)

Recently uploaded

Recently uploaded(20)

Scrum & Kanban for Social Games