scrum & kanban for social games
TRANSCRIPT
+ Scrum & Kanban For Social Games
Sönke Bullerdiek Senior Project Manager May 27th 2011
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
2
wooga – world of gaming
3
Key stats
5 games on Facebook; Over 30m ac0ve users
Biggest European social game developer
Only 5% of users from adver0sing
70% of users are female (age 20-‐60)
About wooga
Founded January 2009
Funding: Founders, Balderton Capital, Holtzbrinck Ventures (total of €5m+)
Interna0onal team of 85 from 20 countries in Berlin
Sönke Bullerdiek Senior Project Manager
About Monster World
Launched May 2010
Biggest seller of magic wands in the world
Total team size is 12
Key stats
Hosted at Facebook
Flash client
Ruby on Rails backend
MySQL + Redis DB
§ Launched July 2009 § Biggest brain training
game on Facebook
#1
§ Launched February 2010 § Top 20 Facebook game § Pop colourful bubbles and
explore the secrets of a mysterious island.
#2
§ Launched May 2010 § Top 20 Facebook game § Grow crazy plants and build your
own unique Monster Garden.
#3
§ Launched: December 2010 § Cure cute pets of funny diseases
while building your own pet hospital.
#4
§ Launched: March 15 § Click as many gems as possible in 60s § Already a top 20 Facebook game § Fastest growing Facebook app today
#5
Techcrunch: “wooga is figh0ng the good fight for Europe”
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
n This presenta0on is about the product layer
10
Company Layer Product Layer
long term 10 years 3 months
short term 3 months 1 week
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
Weekly itera0ons based on analy0cs
12
Analy0cs: We provide a great user experience by obsessing on metrics
13
Example: 1.3% drop is deemed unacceptable and game is op0mized accordingly
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% 04 -‐ Tutorial – first plan0ng completed 82,5% 05 -‐ Tutorial – Mr T’s magic applied 81,1% 06 -‐ Tutorial – second harvest compl. 79,8% 07 -‐ Level 2 reached 79,6% 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%
0% 10% 20% 30% 40% 50% 60%
Reached lvl 3
Reached lvl 4
1 day ret
3 day ret
7 day ret
A/B test: Growth 0me of lemonade bushes
5 min => 3 min
3 min 5 min
DAU August 2010
15
0
100.000
200.000
300.000
400.000
500.000
600.000
700.000
800.000
900.000
1.000.000
1.100.000
1.200.000
May-‐10 Jun-‐10 Jul-‐10 Aug-‐10 Sep-‐10 Oct-‐10 Nov-‐10 Dec-‐10
300.000
Weekly itera0ons and always adapt your product and process to changing circumstances leads to:
16
DAU end of 2010
17
0
100.000
200.000
300.000
400.000
500.000
600.000
700.000
800.000
900.000
1.000.000
1.100.000
1.200.000
May-‐10 Jun-‐10 Jul-‐10 Aug-‐10 Sep-‐10 Oct-‐10 Nov-‐10 Dec-‐10
How did we start?
18
Current team structure
n 3 Product Manager
n 1 Project Manager
n 2 Backend Developer
n 2 Flash Developer
n 1 QA
n 3 Graphic Designer
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
DEV FE
DEVBE
DEV FE
QA
DEV BE
Proj M.
PM
PM
PM
GFX
GFX
GFX
How did the team start?
20
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
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
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
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
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
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
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
27
Scrum Kanban
Do not change the sprint log during an itera0on
Do not change a feature if it is already in development
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
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
Kanban Board
30
Concept in progress
Development Backlog waiFng for Kick-‐off
Development in progress
IntegraFon test in progress (test on trunk)
Staging test in progress (test on branch)
Ready for Release
Done
Product Graphic
Frontend Technical
Backend
Kanban Board – next itera0on
31
Concept in progress
Development Backlog waiFng for Kick-‐off
Development in progress
IntegraFon test in progress (test on trunk)
Staging test in progress (test on branch)
Ready for Release
Done
Product Graphic
Frontend +
Backend Technical
Real Board w/ different colors and personal magne0c s0ckers
32
Monster World Process
33
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
Monday Tuesday Wednesday Thursday Friday
QA Release Code Freeze + Planning
Development Development Development Development Development
Process Diagram
34
Idea
Concept
Kick-‐Off (dev+prod)
Backend Frontend Graphic
Int. Test
Ready to Release
Release
Stag. Test
Weekly Progress Mee0ng
n Current version + next version overview
n KPI overview
n Whole company can axend
n Limited to 15 minutes
35
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
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
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
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
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
40
Plan
Adapt
Act