Agile development application for live ops

[Music] okay agile LiveOps there's gonna be a couple of puns in here I apologize in advance for them so my name is dr. Koh's I'm CEO co-founder of Paladin Studios we're a company based in the Netherlands we are enjoying a lovely jungle in our office which is nice and green and open space there's four teams developing games we are a total of 50 people growing very fast even today and we work a lot with publishers so these are some of the publishers we are working with or have worked with in the past there's a couple more that are not yet disclosed but they're coming soon you may know us from a game called storm mound which is a tactical strategy board game card game hybrid Momonga primal adventure is an old pinball game 5 years

ago and some may know it and love it and Galaga Wars which is the remake of the classic arcade hit from under Namco we also did amazing Katamari Damacy with vonda Namco and my Tamagotchi forever there's a whole bunch more games that we created and stuff that we have cooking in kitchen but that's not what I'm gonna talk about today today I'm going to talk about agile agile yeah agile is a whole bunch of stuff and it's a very complicated set of philosophies and a little tools and methodologies there's a bunch of manifestos out there it can all be a bit confusing so what I'm going to try to do today in these 15 minutes that I have is basically give you a little bit of an overview share some of the high-level principles with you hopefully that will get you sort of inspired and intrigued to search for more and then

there's a bunch of stuff that you can of course find on Google and everything or ask me afterwards so all these manifestos I find them extremely complicated I wrote my own manifesto this is my manifesto for agile development and I say that the goal is to bring value to customers as fast as possible for as long as possible that's what it's all about and the presentation in this presentation I'll break that down a little bit more so of course bringing value to customers we're gonna need to figure out what they need we're gonna need to actually build that but we need to do it as fast as possible so there's you know if we're in a live operation situation we're gonna have you know bi-weekly or weekly updates maybe some daily updates of tweaks of varietals so that needs to get in their hands as soon as possible and then of course it's a really long journey we could have these games out there for years on end and

that needs to be sustainable so we need to do that as long as possible all right so first one bring value to customers let's figure out what they actually need and of course value is not the same as price but it usually means that if we provide something something of value then we can add a price tag to it so that's the that's the nice benefit of providing value but the question then is what do your customers value where did they put the emphasis right why did it play your game and of course how can you then increase that value how can you improve that experience I was talking to one of my producers about this and she said that she works with a Golden Triangle of data versus intuition which is sort of the experience the professional experience and the feedback so Cassie did a as Cassie's golden triangle of her product management philosophy and of course data is a critical component to it but how are we

going to use that data and that's that's a very important question and I want to take that'll take a little step back from data and look at the actual scientific method to uncover it is there's a bit of a overview of how we sort of do it if you look at the the scientific method you have the research question or in this case our goals then you construct your hypothesis you built the experiment you do the experiment and you draw conclusion that's it right and that that's the basis of all science as we know it from from space to two simple things like gravity etc and if we map that out that process if you map it out to the game development process then you can sort of say like okay we have this this vision for the product we want to create you know something we think that this might work and that's the functional design right and the functional design probably uses data as the input but also the

experience and and and reviews feedback so there's a lot of things going into that then we build it so we that's the actual development work and then of course we do the experience experiment in a live operation situation that means that you push the build live and you look at the the responses from the players then we draw a conclusion and we define the next steps was this a good thing or should we roll it back can we double down on it if it works so that's the scientific method in a nutshell it's as easy as that and I'd also as a small independent studio we're not gonna make it any more complicated than that because if we do then we're gonna burden ourselves with all kinds of stuff that that's just not necessarily useful then as fast as possible we're not gonna waste any time not in the presentation and not in the development team we have a bunch of agile methodologies I'm gonna highlight a handful here the first one is scrum and scrum basically is very short it's

basically an iterative development method where you work on fixed time-boxed sprints and then at the end of each sprint you have working software that you typically ship not always but usually that's the case in this case is princess 30 days I recommend a little bit shorter sprints and also faster releases but this is where what it comes down to the basic ingredients of scrum or did you have a product backlog this is basically the big rope map the big wish list of all the users prioritized in importance then at the start of each sprint let's say it's two weeks then the team sits down together with the product owner and they basically plan the sprint they pick the the top things from the product backlog and they're gonna say hey we can do this stuff in the two weeks that we have then you start the Sprint you have daily stand-ups to to sync everybody and at the end of the sprint there should in

theory be something that you can ship now the nice thing about scrum is that you have a steady rhythm of development that you can work with especially in a live operation situation so if you say we're going to ship something every two weeks that's a beautiful system to to sort of manage that speed as well then we have Kanban come on is a little bit like scrum in the sense that you also have for example a backlog perhaps and there's this review process and you could actually mix it with scrum I'll come back to that in a moment but come on basically means that you have a process you would define your process at the bottom there's step ABCDE and then there's certain tasks that go into your funnel of the process then the team picks up these tasks they work on it and then when it's done ready for the next step they move that task to the next step the nice thing about common command means signaling in Japanese and it signals that a

bottleneck occurs the common is actually structured in a way that every step in the process has a maximum number of tasks that you can allocate to it so for example there's in this sort of weirdly googled image of a process which is almost completely irrelevant but there's a couple of columns there that are filled to the brim and that means that that's a bottleneck at that point you have to signal like okay guys this is a bottleneck let's say QA the last step in the process QA that's the bottleneck we need to test everything we need to get it get it tested at that point the bottleneck determines the speed of your development so everything relies on the speed of getting the the tasks through that QA process and at that point it might be very useful to actually allocate people from other parts for example a programmer maybe temporarily to ease the bottleneck to

solve the the Quality Assurance issue so it's a very nice way to optimize a process flow then we have Lean Startup which is not necessarily a management methodology but more of a philosophy this basically talks about MVPs Minimum Viable products getting it out there as fast as possible building something anything that sort of meets the requirements of your target audience then getting it out into the market testing it and seeing what works if that sounds familiar it's typically what we do with soft launches so the earlier the better that's the the mantra of the Lean Startup and then you basically measure and and you start going through that loop of build measure learn which is again it's basically the scientific method I highly recommend to mix and match so there's this concept called scrum man which is sort of a Kanban board with scrum sprints and you do retrospectives and reviews and there's

all kinds of stuff going on but whatever you use right whatever you use a couple of principles that are just solid are focusing on the value for the customer working in those small chunks don't don't bite off more than you can handle at one time shipping early and keep talking keep reflecting on the way you work optimize those processes and and get better as you go then the third one is that we want to stay in business for as long as possible and it's not just a financial thing but it's also a sort of mental health thing anybody who's been involved in live operations knows that it's it's very stressful to be under continuous deadlines in a life environment a very good way to deal with that is DevOps some of the earlier speakers also talked about this you want to have as much automation as possible to minimize human errors to to allow the team to sort of sit back relax just push

the button and you know the build goes live that kind of stuff really helps with with you know your sanity you also want to have visibility so dashboards and things like select messages are very useful for that what we have for example is a server health dashboard that just shows us exactly what the server is doing so the engineering guys they basically use that they put it up on the screen that's inside the studio within the team put it up and everybody can see what's happening some points are gameplay related some points are server health related but all of these these metrics they just shows show us at a glance like ok hey we're doing good we're fine we also have the the automated actions for example if we need to go into maintenance we don't have to manually you know check boxes in the database or whatever it's just a a

pre-defined script of actions that's going to be triggered whenever we push that button then when we end the maintenance it's the same thing and everybody's you know players are notified sessions are stopped all these things are automatically occurring so that we don't have to think about it let me see there's also a couple of tests on the code base I won't go into that too much and then we also have automated scripts to push between environments so we have a pretty typical set up testing environments there's also a development environment which is local testing then staging then production and each of these environments has a roll back so we can easily roll back the code if something if we mess up somehow then we can roll it back and yeah sleep well we also have a visibility dashboard of which version which environment is running which version so this is a git chart basically shows us where we are in

terms of the the staging or server the production environments this helps a lot with QA because there's a lot of moving parts as you can see in this slide a lot of moving parts so we need that a health monitor to be to make sure that everything is just where expect it to be basically by the way one of the advantages because this surfer chart is a little bit daunting perhaps for me it is at least but one of the advantages is that you can have a lot of stuff on the servers so we can really manage the the game on the server so we can update the cards we can update the gameplay without having to push for for the declined updates so all the cards are just on the server and it's really really handy to have these dashboards in place I'm running out of time so I'm

gonna be quick about this the team typical team setup we like to have everything in one team in the same location multidisciplinary typical scrum team size between let's say six and ten people really rough outline is that you know we just need every discipline on the team and last but definitely not least is that in my opinion your company culture is way more important than all the processes that you implement so whatever methodology you use you know whatever mix you're gonna create for yourself make sure you understand that you have that those core values of the company the reason why you're in business in the first place your core mission and the things that you value as a team as a people right that you don't sacrifice it because that's the point where the sustainability will be damaged and the the other part of that is more practical that because when really hits the fan all that stands between you

and chaos is your culture right when everything breaks down then it's the people in the mindset of these people that matter the most so don't panic slow and steady wins the race it's a marathon right let's not rush things let's not you know sacrifice too much we need to celebrate those victories keep talking and the way I sort of approach that in terms of the organization is that I like to keep the teams as autonomous as possible giving them very clear authority and of course also accountability that goes with it and then making sure that I get out of the way but there's a lifeline so there's you know clear reporting structure and reporting is not something that has to be a bad thing right it's not a written TPS reports that everybody has to fill in or anything that was just a conversation on a weekly basis simple KPIs and then we can provide guidance and support and also create internal service teams to support these

development teams like QA engineering HR marketing that kind of stuff that's what I got thank you very much thank you very much Derrick that was super yeah we have some time for questions so great yeah feel free shoot here in the front one one one that one second we need to get a mic is it on high you're talking about scrum and agile did you ever work with a waterfall method and what have you compared the two so the question is that we ever work with a waterfall method and of course we work with publishers a lot so it means that we're sort of semi-fixed contracts so what we use is a sort of a mix we have a route map we outlined a high-level points of what we're trying to achieve but we keep negotiating and

adjusting along along the way scrum is never an excuse to not have a long term plan right so we need to have that roadmap in place Waterfall typically means that you sort of you know set months in advance and then it's carved in stone and you know that's not how we work no but it's a mix between yeah you want to have that product vision for sure any other questions yeah here we're good thanks for the great talk and I wanted to ask what were the like the biggest challenges on your road to the place where you are now because I believe there had to be process of transition so

what what did you do or what were where the challenges of changing people's mindset the agile mode yeah so the question is how what challenges that we come across to the place where we are now and whether there were any issues with changing people's mindset for agile I think from the start we were very agile so that helps but in that case agile basically meant that we didn't have any structure at all or very little and we're now with 50 people so that means that we need to sort of get into the habit of sort of formalizing process a little bit I'm very cautious with that I don't at all want to create a bre across bureaucracy but yeah we're gonna need to sort of set some rules so to speak but honestly what what I what works very well for us is that these teams are very autonomous so that also means that they define their own way of working so I don't care

whether they use scrum or Kanban or whatever bond and then they can just define it themselves some teams use physical whiteboards others use JIRA some use Trello doesn't matter that's it's their thing so they self organize in that way and I think that's a really good good yeah good way to do it you don't want to go top down like a everybody now and he needs to use JIRA all the time always that's not gonna fly [Music]