Taming the Chaos: Lessons in Project Management

[Music] hello this session is called taming the chaos uh it's about creating sustainable pace of development without sacrificing innovation and creativity it's a little bit of introduction here uh this session was uh helped along by a friend of mine called grant chunkweiler who's also the co-author of a book called gear up which is a collected set of over 100 practices that we put together from our experiences and experiences of a number of game developers around the industry and applying agile to game development i also mentioned the second edition of my book agile game development should be out by the time you see this all right so let's dive in here let's talk about uh this session so we're talking about chaos and chaos is really just disorder and confusion not necessarily complete but it's kind of the the the chaotic things that

we go through in in game development now the thing is that chaos is often necessary in game development where we're exploring finding the fun and discovering new things that might disrupt our plan of developing a game so what we want to do is tame that is that make it less powerful and easier to to control and there's some reasons for that and some of the the some of the primary reasons is that we want to avoid uh the crunch the death marches that commonly occur in game development uh when chaos comes at the end of development we're trying to get something out for a critical ship date also to reduce and eliminate the waste a lot of times we're in a rush we make content we make characters long before we really know what we want to do inside of those levels or with those characters and i've been on games where we've thrown away probably about 50 percent of the content we created because we

created it far too soon to avoid making bad games and there's plenty of examples where chaos at the end of the game makes us compromise or drop key features just to get something out the door uh that uh is not fun something that we're not proud of or that uh we just released something that just doesn't need to meet its business schools i mean we are a business we want to release games that you know allow us to sustain that business to make a little bit of profit so we can continue doing what we love but speaking of what we love i think one of the the major problems that i see and i personally experienced is just burnout really as a project manager after three months of crunch uh it turned me into from being an enthusiastic game developer and as a risk avoider you know someone that i didn't want to take chances by trying something that potentially could be fun

i started managing based on hitting a goal hitting a ship date uh meeting uh the specifications of a plan or or cost limitations and what it turned me into was really just someone who looked for a cookbook something that allowed game development to be something we could control and something that would be simple and there really is no cookbook um but it turned it turned me and many other project managers into some someone to focus on the project itself as i mentioned the goals of the project rather than the game rather than what the game is telling us and it also turned me into a seagull manager and if you're not familiar with the term a seagull manager is someone who flies in craps over everything and flies away and i was doing that to you know kind of keep people into in keep things into control say hey don't try that that's not part of the plan i don't care how fun you might think it is we're not

going to get paid for that uh and so i want to talk about i want to talk about avoiding that um and focusing really on on on things to avoid that that uncontrollable chaos so one of the things i want to mention getting into this is some or maybe all of this might not be possible for your culture and in 2003 i read this book that had just come out about scrum and i took this two-day course from one of the authors one of the creators of scrum and i left that kind of infected with some ideas about things that i wanted to try but some of those things weren't possible for my studios so i tried a few things but i kind of kept that that infection in my head in terms of things that when i moved to a different studio or moved to a different uh part of my career i could try out in a new organization and so there's some ideas in here i want to potentially infect you with probably not

a great term these days to use uh but just to implant some ideas that that you can you can kind of create your own practices by applying some of this so an inspiration for this talk came from this book called anti-fragile and very popular book that came out a few years back and in this book he describes three different types of systems and the first type of system is called a fragile system it's a system that breaks under stress and many of us you know we made games when we were kids we kind of hacked games and we didn't really pay attention to fixing the bugs or things like that because that wasn't the exciting part and then we found out over time that the game became more unstable and and broke much more easier uh the second system is called a robust system it's a system that bears the stress but and doesn't break but it's very fixed and this is the system i was describing

as a project manager that i got into to say hey you know we're going to go according to plan we're not going to we're not going to experiment as much and it was a robust system but it didn't it didn't respond to change very well and then and so like risk adverse waterfall is how i describe it and then describes a third system which is the title of the book called anti-fragile and it's a system which not only survives stress but it actually gets stronger under stress and improves under stress and what we're going to talk about are these these things we call them stressors things that stress the system but i want to look at some of the things that are beneficial stressors which actually make the system stronger so diving into that analogy he uses in the book which is a great analogy is working out so the idea where you go to a gym is you want to stress out your body to

the point where it gets stronger and there's a range of stress that you're aiming for so for example if you don't go to the gym it's not like your body stays the same it's not a stable system it actually gets weaker over time if you don't go to the gym then the opposite of that is you see this at gyms on the in every january second is a lot of people come in make their new year's resolution to go back to the gym but then they come in and they load up too much weight and they don't realize that they've gotten weaker by not going to the gym and they injure themselves but there's a range of stress that we're aiming for going to the gym regularly where you put up enough weight where you can barely maybe do you know eight to ten repetitions and you're actually damaging your body a little bit and you give it a day or two off your body gets grows new muscle to get stronger and then as those weights become easier you actually load up a little bit more you add a

little bit more stress uh so if you apply this to various areas of game development like dealing with bugs um we could ignore bugs like we did when we were hacking and let them pile up and of course the quality goes down over time and the the game gets less fun with more bugs or we can overdo it like we usually do post alpha and we basically say all right we have ten thousand bugs in our bug database let's solve them all and we go into a death march crunch and so this beneficial stressor range we're looking at you kind of call it continuous improvement not only fix those problems but find the root cause you know what are what are why did that bug get into our game and how can we prevent that type of bug from getting into our game in the future really because the best way of solving bugs is just not to make them in the first place so these beneficial stressors actually googled this and found this a word called eustress uh which means a beneficial stress

so the rest of stock is going into four different areas and talk you know exploring what are the beneficial stresses these use stresses that we can apply to game development so we're going to be uh building into this anti-fragility into four areas as i mentioned focusing on outcomes over output iterating on fun and course correcting rather than following a plan embracing risk rather than avoiding it being proactive about it managing debt and we talked about bugs and things like that not only fixing them but hardening our process against the reoccurrence of bugs in the future or defects and then building a culture where developers thrive where they take more accountability they're more creative more engaged in their work all right so let's dive in so focusing on outcomes over output and the example i use is my experience working in the game

industry at the beginning working with nintendo of japan and the idea uh with working nintendo with miyamoto directly was that he would come in he would discuss an idea for a game and he would give us three months of money and tell us to go find the fun he didn't want to read any documents anything else like that he said go find the fun i'll be back in three months and so this kept going on and on and the game we produced with him if i think about it if i think about hey when did we find the fun over time and you look at this graph time is on the horizontal axis how much fun we knew we had found was on the vertical axis and their focus was on finding the fun first which is that phrase they used and after three months if we didn't find the fun cancel it and so that led to a lot of this chaos at the beginning which is exploring throwing things out trying different things and then discovering hey that worked that didn't work and

the benefit of that in and miyamoto had his three c's he said hey make sure we get the camera control and character down before we move forward with levels and more characters based on those things is that we would explore the game we'd explore what was fun sometimes he'd come in and say hey that driving game you worked on wasn't that fun uh we didn't find the fun so let's go do a fantasy golf game and uh so a lot of exploration a lot of chaos and then things would emerge we build up the basics of camera control and character and then build upon those things with various things you can do in the environments and build up a vocabulary and then exploit those things over the course of the game so example of exploitation was a different game a game called smuggler's run which was a launch title for the playstation 2. it's a open world racing game you're smuggling something it was a rock star game and towards the end of it uh we tried something we said hey let's make

this outdoor environment more living let's throw deer into it and so we put deer just that we're running around very simple but it turned out people like that more than racing they liked chasing down the deer and running over them or hitting them and basically the deer had perfect elasticity and they ragged all then they'd go over the horizon so people were making up games and scoring how many deer they hit and things like that might be one of the most popular features in the game that didn't require us to you know throw out a bunch of things just take advantage of what we already had inside of the game uh so a traditional game development waterfall based development you know we have these different phases of design we write a bunch of documents we go into pre-production we go into content production it's all scheduled out and then we make the game fun at the end through integration and fixing the bugs and making it run an acceptable frame rate and then the chaos comes at the end and the problem with that obviously we're running out of time

we're chopping out key features example of that would be a game called midtown madness where there was a lot of ideas that came in in the end that would have made that game twice as fun but we're just trying to fix the bugs we're given a fixed ship date uh so we had to choose one over the other now this this kind of pattern occurs again and again in game development and one example of that would be like with midtown madness is you know the game was kind of rigged against us in terms of the development game the publishing game is that marketing would ignore us they're just not used to seeing anything that's a value of the first ninety percent of the game and then the entire marketing department post alpha would suddenly pay attention to you and we call this the eye of sauron and all of a sudden the eye turns on you and it's blinding light with a bunch of requests from marketing to do this oh can you do that and a lot of times you say we say no that's a great idea but we just don't have the time we're trying to make the game work and get it out the door

uh even worse examples of this in the game industry is when you know marketing or the stakeholders finally see the cinematics of the game uh towards the end and then they say no that's that's the wrong framing of the cinematics or we want a different format of cinematics go off and redo all those dozens and dozens of hours of cinematics that you've spent the last two years working on and those examples in this particular game the team working crunch working overtime for six months to to do those things those late late requests when they could have just seen a simple test animation early on and given their feedback early in development push that chaos sooner so at the end of every area i want to just describe things that you can try in your own environment for this area of outcome finding the fun over output following a plan plans are necessary but fun is a risk i'm also going to give you a link at the

end of this session to a pdf that contains all these takeaways of things to try and things that might get in your way so things like establishing transparency with your stakeholders getting them involved earlier on avoiding that eye of sauron and saying look at this give us some feedback even if you have to drag them in create a collaborative culture but give and take on scope don't just accept all their changes to say hey we're going to add something we've got to drop something else and grow trust that's one of the hardest areas we're going to talk later about creating a shippable build every three months we call it a magazine demo something that could show us the challenge of getting something out the door a year or two ahead of time and not all late changes are bad you know we want to exploit opportunities that the game gives us now the gear up book uh talks about various things like tracer bullets you know things that we can we can experiment with do it a test version of a level to see if your game runs well in those levels

plenty of barriers to implementing some of these things current contracting patterns don't allow for change a lot of middle management that might say hey write the 300 page document and uh where it's like hey the stakeholders like mia motor might not care about the document the developers understand that the documents kind of lie sometimes but there's always a middle management layer that demands that level of detail and some stage gate approaches request or require you to prove a lot of these mechanics in concept and documentation form ahead of time i mentioned to you stressors these beneficial stressors like says getting iterative stakeholder collaboration uh on the working game say bring them in talk to talk to have them talk to you about what they're seeing on the screen a lot of stakeholders don't understand that that this is a benefit or getting their attention is a challenge all right so the second area i want to talk about is embracing risk

we talk about risk you got to kind of categorize risk there's different levels of risk and identify four different areas based on things that we know and things that we don't know and things that we know that we know for certain and things that we've done in the past things that have no risk whatsoever and have a lot of certainty these are things that we can document away we can plan away and i want to take the imper you know the pure agile approach of saying don't plan on anything don't document anything yeah there's things we can plan for things we can document things that we can be certain about let's not fool ourselves about things that we know that that we might not know for example we're making there's a that we have to launch our game on a new platform there's new playstation coming out there's a new xbox if your game is coming out on the platform then there's you know that there's things you don't know and so there's big question marks about

that it's like well you know microsoft or sony tells us that you know our platform is going to behave a certain way and they're going to be really easy and super powerful but we really don't know until we get our game running on it so what are some of the things we can do ahead of time to reduce that risk but that's not the worst of it you know in terms of uncertainty and risk there's things we don't know that we know which can kind of sound weird but i kind of think of this as you know that that han solo moment when he sees this big moon in the in the first star wars movie where he's like you know i got a bad feeling about this this is more intuition these are things that if you go through a number of game development efforts there's like things that's like hey i'm not sure what's wrong with this but i gotta i got a bad feeling about this and we should do something about that to understand how to reduce that risk again with tracer bullets doing experiments before it's time before you depend on something we'll talk about that but unfortunately there's something worse than that

there's things that we don't know that we don't know example for this was we're doing a a born gay based game based on the bourne movies and uh unknown to us matt damon's mom was an anti-video game crusader and so matt dropped out of the project late in development and when he left all the other actors left and we had to scramble to find new actors to take their places and so we missed the movie and it uh it had an impact on the game quality as well and doing these things late in development so the idea is to embrace risk as i mentioned early on and that there's a couple of books i'll give you reference to in that pdf later on waltzing with bears and uh and risk up front which talk about not avoiding risk not planning away risk but embracing it and doing something about it being proactive about it and so the process i kind of derive from that is is to i first identify risk and we start at the beginning of the game and say all

right let's talk about what could go wrong we actually make a game out of it called a pre-mortem it's like future postmortem and talk about all the things that could go wrong and so for example it's like hey we have a critical launch date we're a movie based game or we're a sports based game or a launch title we have to hit a specific date so our next step is to go into find a root cause let's let's dive into this a little bit further and find out what could cause us to miss the critical launch date well one thing that happened to us was a key middleware piece of middleware was not ported to the platform in time and so we take that further and say when will we know whether this risk is true or not whether we're missing this middleware date and so we derive some key performance indicators like to say hey by october first if this piece of middleware isn't running our game on this particular platform we're shipping on this risk has come true and then we say

what are we going to do about it what's our mitigation strategy and we can say well not going to be cheap but we're going to buy the source code license and port it ourselves to avoid missing this critical launch date and then we continue on a regular basis every maybe a month to three months we come back and evaluate these these not only evaluate these triggers but identify is there any new risks emerge that we didn't identify earlier on and keep adding to our database and uh and then you know if a october first comes around is the kpi met if not well then we have to mitigate we have to do something about that and going through this you know about 20 percent of our risks actually came through and we were able to to mitigate many of those risks that we could spot ahead of time all right some things you can try on this obviously go through this process which i'll document in the pdf

uh things to try risk mitigation strategy i talked about this there's various practices in the gear up book the pre-mortem embracing risk which describes this flow risk matrix things like that uh plenty of barriers cultural barriers to this a lot of stakeholders don't like hearing about things that could go wrong they just want all the good news they want a plan about how that's not going to happen well risk means uncertainty you can't plan away risk and so part of this is selling selling this uh and the key part of selling this is the mitigation plan be proactive about it don't just say hey we're scared about this to say hey this is something we don't know this is how we're going to identify it and this is how we're going to solve it so it's not just a cover your ass document this is something that that says we're taking charge of what's potentially going to sink us so the eustress is you know doing this

on a regular basis embracing this overcoming the cultural barriers to saying hey let's pay attention to risk all right third one managing debt all right so debt and like financial debt it's something that's whose cost grows over time you have an interest rate on financial debt the longer you take to pay off a loan uh the more it's going to cost you to pay off that loan and so for debt for game development bugs you know longer you push off fixing a bug the harder is it going to be fine to find it the harder it's going to be it is going to be to fix it because it's not fresh on the mind of the programmer that created the bug or somebody else has to find it and fix it but that extends to other things like design and content production and i kind of sum all these up in terms of the debt it takes to ship the game that we usually postpone to post alpha

to get the first version out the door and uh so a lot of a lot of agile practices deal with this like defining a definition of done knowing when a feature is done and asking that question uh are we there yet have is this is this shippable or does this reach a level of definition of done and a lot of teams they evolve that definition over time so it could be definition does like hey it doesn't crash to all right passes all internal tests and play tests that builds up over time with things like test automation and things like that so to look at it you look at this graph you know the horizontal is time development time and this could be the entire development timeline and uh to measure debt i mean you can measure debt in terms of the number of bugs in your bug database uh which in many cases i've been on games where it's like hey we have tens of thousands of bugs uh by the time we get to alpha and i call that the shipping debt there's content technical debt design debt all sorts of

different type of debt but this is the stuff we have to fix before we get the game out the door and unfortunately this is where the chaos occurs this is where the death march occurs uh late in the game to really you know get the game out the door and get it to that point where we can ship it now not only is bad on the developers is bad for the game we make compromises many times to get the game out the door because we're simply out of time example this is a game called midnight club and in this game i was a launch title for playstation 2 and we found out that we fought in these big huge open city racing environments that we could stream in all of our textures for the city and turns out we had to we couldn't do that we had to fit all the textures into into memory at one point for the entire city and so late in development we figured this out and we asked all the artists to trim trim down their their textures they weren't able to do

it in time and so about a week before we submitted the game our technical director got frustrated and he went in and he decimated all the textures by 75 percent and they didn't tell any of the artists and they didn't find this out until they got the retail copies of the game and they were a little upset at how how fuzzy their textures were in the game and it compromised the quality of the game so a different approach i mentioned you know getting that magazine demo every every few months and the idea is every every three months we take a week off polish the game we would make it look like something we could put in a magazine we would disable certain features maybe online wasn't ready so we'd gray out that that menu selection and we polish it a little bit get to that magazine demo so one week every three months and by continuing to do this you know we still had data accrue but by the time we got to this alpha date we had much less shipping debt left over

and so we had the choice of saying well we can get it out a little bit earlier uh or we could actually spend a little bit more time polishing uh so you know this kind of approach actually improves quality and or could save time over the course of the project by not just accumulating all this debt over time and you wouldn't stop there you know you would you would continuously improve the practice so maybe we do a day every iteration if we have a two or three week iteration let's spend a day polishing it and getting it to this definition of done save that week every three months and then maybe do something on a day-to-day basis before we go home for the day to continue that's the idea of continuous improvement so various things you could do uh like i said this doesn't happen overnight garrett book describes various ways that we can automate testing or we can have we even have the game play itself we would have a racing game where we'd say

let's just have all the ai cars race each other we do all 20 races have it run overnight various configurations and we'd occasionally find where something like an artist would have moved a mailbox a couple of feet over a car would hit the mailbox when it's cutting the curve that mailbox would bounce off a street lamp post lamppost would call it fall across the street the physics and physics engine couldn't handle it and i would find a big pile of of cars all wrecked together in the middle of a race and so finding that kind of problem manually would take tons of time but through automation you know you would find that very quickly now also a culture of cultural things try to keep the game as close to shipping as as reasonably possible again with a magazine demo every three months we improved automation things like that to continuous integration unit testing we could always keep it a little bit closer than you know six months away of post alpha crunch debugging

and you know come up with silly little practices like yeah with continuous integration and unit testing if you check something in it would find out in five minutes whether you've created a problem or not it would tell you it's like oh the changes you just checked in broke the release build on this on the playstation and we had a practice word give you 20 minutes to fix this problem and if you didn't fix it in 20 minutes then it would display the muppet of the day on every single screen around the studio and that muppet would start singing their theme song and i discovered this one day by checking in a change running off to a meeting and then 20 minutes later hearing the swedish chef singing his theme song on uh slightly asynchronous on a hundred different workstations around the studio which people love because siegel manager implemented this practice just a little bit of warning is that this is not meant to humiliate people as you have a sense of fun about this stuff people make mistakes you have to have a culture where it's like hey you know we all make mistakes

failure is is is part of the process all right so things to try again this will be in the document at the end uh you know don't separate debt from other work one of the best things we did was get rid of a bug database uh because that allowed us to say hey fixing the problem with a feature is part of the same database either jira or whatever and so we're able to measure the cost of implementing the features which included making those features work because problem with a bug database is that it's part of the cost but it's unpredictable because it grows over time so integrating those two helped us measure progress much much better slowly introduced debt reduction practices establishing definitions to done things like that lots of barriers to this uh fixing the bugs makes the cost of features appear more expensive uh but like i said it's just it gives you a better metric uh and it and it does improve

productivity by fixing bugs sooner over time but stakeholders can push back on this it's like i want you to implement a new feature rather than fixing bugs and polishing and refactoring uh stakeholders could be like kids in a candy shop they want they want fun new features they don't want to worry about bugs until the end and we developers are sometimes the problem it's like i like implementing a feature i don't like fixing it as the bugs associated with it as much so it's part of the discipline of the development culture too so the eustress raising that quality bar is like working out just throw a little bit of weight on it it's going to be painful you're expecting people to change the way they work don't throw too much change cause that injury uh but when the the quality bar rises and people become comfortable with you know those new practices and push it a little bit further all right so finally talk about uh taming chaos number four which is build a culture where developers thrive and this is probably one of the most productive important parts is

you want to create a culture where where people behave based on the benefit of of the work being done the benefit the quality of the game to focus on that and even measure that now there's lots of bad metrics out there and this is one of the big lessons i learned which harmed company culture for example our one of the studios i worked for was owned by a japanese corporation and from their point of view the commitment the engagement of their developers was measured by how many hours they spent in the building regardless of whether they're working or not and that didn't match our culture at all in california but what we found out later on what they were doing is they had an office in los angeles about a hundred miles away every so often they would ask somebody to drive past our studio at two o'clock in the morning and count the cars in our parking lot and uh they were very disappointed at first because they didn't see very many cars in the parking lot uh but when we found out about this what

we did was we made a deal with uh this newspaper distributor on the next and the next building over you know who'd normally have people working there at two o'clock in the morning getting ready to distribute newspapers for the next morning we made a little deal with them to park their cars in our parking lot to get our our uh our uh owners off of our back and that's that's that fixed the problem but it really doesn't didn't help development as a metric and i found this out personally as that seagull manager uh when we first started doing iterations start first started measuring uh scope added to the game rather than the number of hours people are sitting in their seats in the building uh but that was a late learner to that so when we were when we were behind schedule and getting all the scope that we hoped to get into the game as a single manager i said all right we're going to do crunch we're going to do overtime because that's that's my practice for the past decade as the project manager

and but i felt i was a good project manager because i would be there with the team working all these seven day a week 10 hour a day uh hours uh but we had a different metric how much debug scope was getting into the game now at first hey scope went up our velocity went up but we noticed that it slowly declined so that by the fourth week of crunch we saw that we're getting less scope in the game than we were during the five day a week uh pace and i realized you know this people are getting tired they're typing more slowly they're making more making more mistakes they're tired as well as i the last time seeing this metric which not only created transparency and development but transparency with me as a manager that was the last time i ever called for crunch with the team so the idea is to find these metrics which are not vanity metrics which don't you know make you feel good that people are sitting at their desk at 10 o'clock at night but actually add to creating value in

the game a lot of times when we were forcing people to be late in the studio it represents a lack of trust now you think about this from a system's point of view or from a team building point of view if anyone's read the five dysfunctions of a team they know that an absence of trust is the fundamental thing that that breaks team performance if the team doesn't trust each other or management doesn't trust the team then they behave in a certain way so from lack of trust what happens a lot of times is that the stakeholders say we don't trust you we're going to leave you on your own you're just going to be lazy and waste our money we're going to have you create a big huge document with lots of details and we're going to task you down to the hour because we just simply don't trust you and the problem is that that creates a system where you know it doesn't doesn't allow for emergence as i mentioned earlier very little slack because we're trying to push as much as we can to make those untrustworthy

developers work and that leads to people optimizing their behavior based on their discipline it creates silos as a programmer i'm given a ton of tasks i'm just going to write the code to fulfill them when i was in the defense industry i was measured on the number of lines of code so i wrote very fluffy code if i can write something in 10 lines of code rather than one i got a bigger raise so it leads to all sorts of problems like developers protecting themselves if you're an animator and you come to me as a programmer and ask for help i'm going to tell you to go away because i got to get my stuff done that's how i'm being measured by this silly silly metric rather than getting things in the game it's how you know whether my stuff compiles and i can move on to more tasks it avoids emergent work it leads to padding estimates uh which you know rarely works work expands to fill the pad very very often uh and we ignore our dependencies it's like hey throw you know bugs throw it into a bug database i can get my stuff

done so i look good as an individual not as a member of the team and we get poor results as nothing's working we can't demonstrate anything i can say hey these these tasks are done but you can't see any of that in the game we're postponing uh the emergence of value and that just drives that cycle it's like you have poor results that means that we didn't write enough documentation so let's ask for more documentation so to reverse that cycle we have to extend trust this is where leadership comes in what can we do to grow trust and yeah it takes a little bit of extension from the stakeholders and the developers themselves so to give them a little bit more freedom let's form across cross-discipline teams let's let you start to create your own plan to break down the individual tasks to own your estimates eventually and focus on the results this is where your practices like sprints come in where it's like all right this is what we want to see in the game

you tell us whether you can do it you manage the individual tasks we're not going to micromanage you but we want to see the game improved in two weeks in the in the way that we all agree agree on and so that results in more accountability at the team level focusing on what's in the game rather than how many lines of code that i've written uh taking advantage of emergent work if something's fun and it wasn't part of the plan well let's talk to some of the stakeholders during during this iteration talk about hey can we ditch this thing because we found that this thing works uh and it's a team result you get people behaving as as a team and they don't want to let their team members down so you get improved results which kind of drives a better game better forecasting it drives better behavior and it drives elevating levels of trust so one of the last things i want to talk about is this sense of flow now as a game developer there is occasional games that i worked on and i wish it was more frequent where

i just thoroughly enjoyed the development of the game i would i would be brushing my teeth in the morning and think of this great idea and rush in to find people implementing their own ideas aligned with the overall goals or you know you start i'm sure everyone's experiences where you start working on something and you look up at the clock and you think it's it's lunch time it's three o'clock in the afternoon it's like oh that's why my stomach hurts you're so engaged with the work and this is called flow and and as developers we love being in this state of flow and there's this book that came out i kind of described it kind of summed up what i felt as during these rare situations where i'll just completely engage creatively with my work and this is based on a lot of studies that show you know there's a there's a correlation there's levels of skill that developers have and there's levels of challenge from low to high that they encounter and what we want to do is find that

range where those two things match because if you have a certain level of skill and you're given too low of a challenge for your skill level you get bored get bored with the work you're not engaged you're not doing your best work but if you're if you're given too much of a challenge for your existing skill level you get stressed out you don't do your best work you get frustrated uh you don't want to hang around you don't get engaged with your work and so what we're trying to do is find that middle ground where our we're challenged at our skill level uh with a particular tasks that we're trying to accomplish this feature we're trying to implement and what we're trying to do as leaders again using this workout analogy is we're trying to push that we're trying to say it's like hey your skill level is going to grow over time let's just push you a little bit let's give you a little bit more challenge than you're used to not too much we don't want to get into that injury range but let's get into that strengthening range so that

your skill grows to meet that challenge level and continuously find ways of pushing raising that weight limit raising that uh that challenge level so people's skill level grows and this is one of the things that motivates the developers the most and they do their best work and when they do their best work it it directly benefits to the game all right so things to try uh keep developers focused on those shorter cycles give them more give them more challenges come up with metrics that mean something people behave based on how they feel of being measured and so what's the best measure is just improving the quality of the game if you can measure that based on what the scope is we're putting into the game discover those things grow trust give the team more autonomy over time not all at once just give them little challenges of of autonomy and and self-management and build the flow like we like what we discussed you know give them more and more challenges that

that uh meet their their skill level so plenty of barriers to this as well this is a cultural thing and trust is a two-way street it's hard to build easy to destroy and sometimes it's as a leader you can extend trust but maybe because of your past the culture you're a seagull manager as well people just don't trust you as much it takes time for them to kind of say hey this is this a trick or what um i said hard hard to build easy to destroy like myself i was very easily tempted to go back to say all right let's go back to crunch uh and put it on the developer's shoulder to meet the schedule that i predicted for them so some use stresses again it's slowly empower the teams slowly back off it's going to be painful for the teams to take more ownership it's going to be even more painful as managers to give it to them and not give up at the first sign of problem

there's always going to be problems and raising the raising the challenge bar for developers okay that's it i want to thank you for taking the time and as i mentioned there's a pdf at this website called tamingthechaos.com a single link there to the pdf which summarizes all those all those things to try and all the barriers and all practices that you can try in gear up thank you [Applause]