#120: Agile in Gaming with Clinton Keith

How does Agile fit into the fast-paced, high-stakes world of game development? Clinton Keith, author of Agile Game Development, spills the secrets from his time working with some of the top studios in the industry and explains why adapting Agile to gaming is both a challenge and a game-changer. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Clinton Keith dive into the unique dynamics of Agile in the gaming industry. Clinton shares stories from his decades-long career in game development, explaining how Agile methodologies have evolved in the industry and why traditional approaches often fail. They discuss the impact of deadlines, the influence of digital distribution, and how finding the "fun" in games is crucial for successful development. Clinton also provides valuable insights into modifying Agile practices to better fit the gaming world and the critical role leadership plays in fostering a productive Agile culture. References and resources mentioned in the show: Clinton Keith Agile Game Development: Build, Play, Repeat by Clinton Keith Mike Cohn’s Better User Stories Course Accurate Agile Planning Course Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Clinton Keith is a seasoned game industry veteran turned Agile coach and author of Agile Game Development, 2nd Edition. With 25 years of experience as a programmer, CTO, and production director, Clinton now helps creative teams and studio leaders build better games through effective Scrum, Lean, and Kanban. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. Glad to have you back. We're here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner. Today, have a very special guest. A very special guest was the word I was looking for, but somehow it came out wrong. A very special guest that I'm very excited about having with us, Mr. Clinton Keith is with us. Clinton Keith (00:17) You got it right the first time. Brian (00:23) Welcome in, Clinton. Clinton Keith (00:25) Hey Brian, thank you so much for the invitation. Brian (00:27) Yeah, very, very psyched, very excited to have Clinton on. Clinton is a CST, but more importantly, he's the author of a book called Agile Game Development. And he has been in the video game industry and working with different video game makers and production houses and things for a long, long time. And he told me he's been a video game maker since the seventies. So I said, well, that's great. Cause I've been a video game player since the seventies. So I'm sure we could cross. and have some overlapping stories here. Me from the consumer side. I wanted to have Clinton on because he's got this unique perspective of really how Agile has developed and how Agile is kind of implemented and works well in the gaming industry. So let me start with just asking you, Clinton, when you work with gaming companies and they are interested curious about Agile, what is sort of the main holdup or the main objection that they present to you when they first start working with you? Clinton Keith (01:37) Well, it's changed. mean, I've been an independent trainer CST since 2008. And back then it was like, this agile stuff doesn't, know, this won't work for us or it won't work for our role playing game or massively multiplayer online game. might work for these small games. But I think since then, what you've seen is there's just such a lot of bad implementations. We call cargo cult implementations of Agile, where we think that standing around in a circle and answering three questions a day is going to result in some productivity fairy flying over our heads and sprinkling this methodology dust on us and wonderful things will happen, where there's a discipline and a change in culture. And so people have seen a lot of poor agile implementations. But at the same time, continuing on with more traditional approaches as games get larger, teams get larger, projects get bigger, that they're saving the worst failures on not adopting a more iterative approach to game development. Brian (02:54) Yeah. Yeah. Yeah, I mentioned that there's probably a lot of objection. There's a lot of the companies that kind of take that fixed scope, fixed schedule kind of approach to doing work and kind of think maybe Agile doesn't align to what we do or our industry or how we do things. Hopefully I'm not putting you on the spot too much, but do have any interesting stories or examples of things like that where you've worked with a company that maybe was just very, very resistant that you kind of, that they kind of turned around in the time you worked with them? Clinton Keith (03:36) Well, think one of the more clear examples and, and, know, I, being a project manager and someone who's a, started as a programmer and ran studios, you know, and we ended up shipping successful titles on schedule, on budget. that, when I work with teams that have true deadlines, you know, these are teams that, especially sports titles where. You know, if, you know, Madden football misses the launch of their next title at the beginning of the NFL season, they're going to lose half their sales as opposed to, you know, being told it's so called, have a deadline, but you know, that just to put pressure on the team. so when you have that kind of deadline, a do or die deadline, then it gets them serious about doing things like prioritizing scope. Brian (04:11) Yeah. Yeah. Clinton Keith (04:30) We're saying, it's like, hey, we have this new engine to render crowds in the stadium and this is going to be beautiful. And, and it's going to look like these are real stadiums filled with people. They're less willing to take that risk if it has to come out on that specific date. And so we prioritize scope by saying, Hey, we have 32 teams, you know, it be baseball or NFL or whatever. have so many stadiums, we have rosters, we have uniforms that have changed from year to year. Those are things that we have to get in. The things that are like a new technology for mud on the uniforms, well, we can take a different approach to that and say, those would be nice to have, but we're not going to bet our schedule on that. So those were the teams on what we call AAA games. They're games that have large staffs, huge budgets, hundreds of millions of dollars. They kind of learned those lessons early on and it really became proof that an agile approach of saying, prioritizing scope and managing scope and delivering things that work and that show increased value in terms of player fun on iteration, iteration basis was really the best approach to hitting those targets. Which again is really difficult for teams that really have those so -called hard deadlines. but was still with a fixed scope, that they want all those things and at the last minute, end up compromising quality, get those all the, to hit all those goals. Brian (06:06) I'm kind of curious about kind of the teaming aspect within the gaming industry because it seems like, and maybe I'm wrong here, so correct me if I'm wrong, but it seems like more than some of the other industries in software development that it's a little more of the mercenary kind of attitude of, you know, kind of have the gun for hire that you bring in or guns for hire that you bring in to do some project or some game and then... then when the project wraps, they're gone. People float from place to place. Is it tough to generate, have teams go through stages of formation in that kind of environment? Clinton Keith (06:46) Right. Yeah, no, it's less so with now that we had mobile games, these mobile platforms come out where a lot of most of the effort actually is maintaining and building a live product and growing it over time, where it's like, instead of saying, you know, on traditional large games, we're going to spend two years with no customers, no feedback. We're going to build this huge game and then launch it all at once on a disc or on a cartridge. and then cross our fingers. And with that approach, usually with game development, the traditional approach is to have a documentation phase, a planning phase, a design phase, and then a pre -production phase where we build all the mechanics. And then a production phase where we create all the levels, build the storyline, something that people can play through 20, 30 hours. And then at the end of it, alpha beta phase where we fix all the bugs, make it run fast, find, know, make it fun and polish it and then get it out the door. and in terms of staffing, like what you described was very, yeah, it was the big challenge because in pre -production we, you know, we might want 50 people, 30 people. but then when we're building all this content and building the worlds, then we're growing to a couple hundred people and then you ship it on the disk. What do you do with those 200 people that are sitting around? And that's still on large games. You know, I work with some teams that are over a thousand people developing the game. And they're trying to address that problem by having, you know, large publishers or acquiring studios. And they'll have up to half a dozen studios in various locations around the world working on that, especially on building those worlds in that, that production phase. But then that introduces the problem of communication and overhead and time zones. And yeah, it's a very challenging problem that when I started in the game industry, know, a AAA game took less than 10 people, you know, sitting in a single room. Brian (08:53) Yeah, kind of, it's such a different paradigm now than it was. And the industry has changed so much, it seems like to me because, well, like for instance, my oldest daughter is a pretty avid gamer now as well. And when we were helping her get settled for her second year of college, we had to replace her monitor, know, so she had something to play on. And we walked in the Best Buy and I tried to explain to her that, Best Buy used to be a mecca for gamers. I remember going there regularly to stroll through the shelves of the boxes and kind of see what was on sale. Now, I can't remember the last time that I bought a physical media for a game. It's all downloaded. How has that changed just the process of developing games? I'm sure that's, previously when you had to have the gold disk version or whatever that was released. I'm sure there was much tighter timeframes, right? Is it much different now with being able to update over longer periods of time? Clinton Keith (10:03) Well, just from an Agile perspective, it's gotten much better. You know, we introduced Agile to our studio back 20 years ago, over 20 years ago. And, you know, back then, really, the retailers dominated the industry so much in terms of you had to sell Walmart on the game you were proposing to make, which meant that you had to write the 300 page document that they would approve. Brian (10:25) Yeah. Clinton Keith (10:32) before you even knew it was fun. It's even worse with some of the larger first party companies that own the consoles, that they would say, well, we have a slot for making this type of game, so you have to stay within that slot. And at the end of it, we will determine how many cartridges that we will manufacture for your first release. And so it's very restrictive in terms of how much change we could introduce into the game over the course of development and say, well, the game that we're making is kind of boring. But that's the agreement that we made with Target or Walmart. And so we have to kind of stick with that game. Whereas now you can get early versions, like in Steam, for example, early release. And you can start to get metrics or that if you're a a game that's already out on a platform like iPhone, you can introduce the idea of a new mechanic to a limited number of users to say, it's like, hey, let's release a version of this mechanic to people in the state of New York and see, observe how they're playing it, measure how they're playing it, how many times they come back to it, and then use that information to tweak the next two week iteration or release dozens of different versions of our game you know, to millions of people and see which version that's out there in the wild is getting more response. So we have the ability to, you know, be much more agile and actually measuring what our customers, our players are doing with our game. Brian (12:07) That's so interesting. You spoke earlier about kind of like the AAA games with like sports games and how they have much tighter deadlines and they're, they kind of, there's a big, big hit to them if they miss that deadline. What about the opposite? What about the teams that don't have those harsh deadlines? And I would imagine there's an entirely different problem for the product owners of just good enough. how do you... How do those product owners determine, yeah, we have enough or this is in good enough shape that we can release it and we can patch things later? Clinton Keith (12:44) think one of the biggest problems you see when you don't have a deadline is this. There's this famous quote, I forget the exact wording of it, is that really tight deadlines, know, kind of restricted, know, restricted, to call it use the word resources, but in terms of money and schedule and things like that, or how many people you have working on it, really focuses you on delivering. And this is something that is a problem for AAA games with no serious deadline is that to say it's the, get these incredibly vast ideas that take years to really show the benefit. And I had this big light bulb moment in my career. I was, I was, I did a lot of racing games really in my career and I was on a game. that had a racing mechanic is based on a movie like what some of the Bourne movies where you have like a 15 minute racing mechanic, know, chasing in the middle of the movie. So late in the development of the game, we had a little bit of extra time and our publisher said, hey, can you throw in like a very short 15 minute car chasing and with police chasing you through an open city. Now that mechanic, police chasing you through an open city, used to take us years to develop with artificial intelligence, know, with police chasing you through crowded traffic streets. And even after years of development, it didn't quite work right. The police would crash into everything and drive on walls and we couldn't get the physics right. You know, we're on a PlayStation or Xbox. You know, you couldn't spend a lot of AI effort, artificial intelligence, on getting that just right. So, but we only had like a month. And so we're sitting around thinking, what can we do? How can we get police chasing us? And so we started asking ourselves questions that we never did ask in the past. Like, why do we have police? You know, why do we have police chasing you? And the answer was that, well, it's to make you drive fast. You know, if you didn't have police chasing you, you know, it's a boring game. And so all we did was we just, instead we just had Brian (14:47) Mm. Right. Clinton Keith (15:02) We just monitored how fast the player was driving. And if he was driving a little bit too slow, we'd start playing a siren sound. They kept driving slow. started playing flashing lights off the geometry of the buildings around you, blue and red. And then if you continue driving slow, we just played a video of you being arrested. And that took like a couple of days instead of a couple of years. And when we focus tested it, pretty much, half of everyone thought they were really being chased by the police. The other half said, I thought I was being chased by police, but when I looked in the rear view mirror, I didn't see any police. And so we just took out the rear view mirror, tested it the next night. Everyone thought they were being chased by police. And we're like, I guess, and it was actually a better result in the two years of trying to get artificial intelligence right. And so the big light bulb moment was, just like having, Brian (15:53) Yeah. Clinton Keith (15:56) a short deadline on showing something of value led to people making better choices from the player's perspective, not this challenge of, what can I do with artificial intelligence over the next two years? So I think that's part of the big challenge with these big, huge games of saying it's like, if there's not a payoff, if you can't see value, and this was an early lesson I learned, Brian (16:11) Yeah. Clinton Keith (16:24) working with Nintendo Japan was the guy that made Mario and Donkey Kong. We worked with him directly, Miyamoto. He always had this thing. It's like, find the fun fast, show the value of it. And it always stuck with me. And so when you have these short deadlines, you want to encourage the teams and the product owners is judge the game, not what you see in Brian (16:40) Yeah. Clinton Keith (16:49) with the potential in two years. Judge your vision of the two years against what you're seeing every other week and adjust your expectations. Don't fall in love with your vision. Brian (16:59) That's so interesting. So I kind of want to dig into this. This is an agile podcast, obviously. And we have lots of people from different walks of life and that they're implementing agile in different ways. And it's always interesting, I think, for people to hear how things kind of fit in other realms, right? In other kind of industries and how that changes a little bit industry by industry. So I'm kind of curious when you are talking about agile and Scrum and in a gaming game development environment, what are some typical kind of modifications that you recommend or that you've seen that are needed or work well that are specific to the gaming industry? Clinton Keith (17:44) So as I mentioned, a lot of teams, even Agile teams that are truly Agile, like the sports titles, we still have that separation of discovering what new mechanics we want to put into the game and then building all that content, your stadium. So let's use sports titles for example. Let's say we do alter how we draw or render the stadiums. And we're making much more beautiful, more detailed stadiums because we have a new platform that can draw 10 times as much like a next generation PlayStation or Xbox. So we still want to come out with the new sports title at the start of the season. So we'll, we'll do more of our risky exploration of stadiums and what it's going to take to, to render these stadiums. and how many polygons, how many triangles we're going to use to build these stadiums and how much it's going to cost. Because we do have 32 stadiums. We do have a budget. We do have so many artists that can build these stadiums. So we have to figure that out ahead of time. And then, you know, once we figure that out and say, all right, we have, you know, we've built an example stadium. This is an example of what we want to ship at the start of the season. Now we have to build all the other 31 stadiums to that quality. And we've judged the risk and the cost and the schedule and how many people we have to the artists to build those things. And then we go into that production pipeline with those studios. And that's where, you know, it's like the scrum every two weeks model doesn't quite work. know, a stadium might take. 21 .2 days to build. And it's a pipeline of handoffs of things. Somebody doing the concept art for the stadium and then building the geometry for the stadium and then lighting it, you know, and all the audio effects. And so it becomes more of a production factory pipeline where practices like Kanban and lean come into play. That still have those underlying values of getting things through the pipeline as quickly as possible, continually looking at how we can improve that pipeline. And then judging instead of how much we can get done every fixed time box is judging how long that stadium takes from concept to in -game and trying to refine that to get improvements in the quality of the stadiums and the productivity of that entire pipeline. which leads to, you know, things that we see in Scrum is disciplines talking to each other and improving how they work together. Brian (20:32) Yeah. I would imagine the culture, like there's potential culture clash kind of things here with Agile in the gaming industry. Like one of the things I was thinking about is, you find it's a little tougher to get buy -in on a concept like working at a sustainable pace? Is that something that's in the gaming industry, people... Because I've seen a lot of... I've been around some small companies that are working on gaming, and they seem to work all the time. It's like late nights, weekends, it's just like it's non -stop. Is that kind of a difficult concept in the gaming industry? Clinton Keith (21:18) Well, mean, the gaming industries had quite a few scandals in terms of crunch time. And a lot of that has to do with not seeing that actual game until the end. As I mentioned, it's like we have these in pre -agile development, still goes on quite a bit, is that, we write this big, huge document up front. We get the buy -off on the stakeholders. We go off and the engineers go off over here, the artists go off over here. And then towards the end of the game, when we finally get all the elements of a story together, we can first start to play it. Then we start to get it so instead of it crashing every two minutes, we're starting to get the game playable and we're out of time. We have to ship this game in three to six months. It's not fun. It's a disaster. Brian (22:06) Yeah. Clinton Keith (22:13) and then what, unfortunately what happens is we've, we put that accountability on the developers and say, well, now you, and, know, as, as a studio director, pre -agile, I was guilty of this as well as to say, Hey, we got it. We, we, we have no choice, but to come in here seven days a week, 10 to 12 hours a day. And, and as it, yeah, as a team we'll, we'll, you know, we'll, we'll get this thing done. And it destroyed. destroyed marriages, harmed families. I mean, I went through that. didn't see my, one of my newborns for the first three months of his life, pretty much, except when he was sleeping, when I came home late. And it simply doesn't, I mean, it's harmful primarily to the working life and these people that leave the game industry, but it's also harmful to the game is that, you do whatever it takes to get this Brian (22:45) Ha Clinton Keith (23:12) terrible game across the deadline that you were very passionate about in this first couple years of development. And we've seen disasters, even in recent history of games being released that, you know, it's just unplayable, but they had to get out for a deadline and they've spent hundreds of millions of dollars. And they've just felt like, well, nowadays we can patch games, you know, and, and, and, you know, it, it, it, it kills them from a financial point of view. Brian (23:41) Yeah. Yeah. It's so interesting. you know, I think this, to me, this is where it kind of, it is so relatable to, to anyone who's, who's trying to do this kind of work. Because I think there that we've all had scenarios and situations where, know, as an agile coach or trainer that we've, we've, you know, we've been up against a constraint of some kind. We've been up against something that is not really the way we would. hope would be the way that the organization would operate or that the team would be run. And we've had to make those compromises in order to continue the work and continue trying to move that organization forward. So I'm kind of curious, I know there's probably lots of people listening who are in those situations and maybe even kind of some self -doubt there about, hey, am I really? Am I really doing this the right way? And am I kind of a sellout and that I'm giving in to the management and how they're making us do this? Would you have any advice or anything that you would say to people in that position that could maybe help them kind of navigate that? Clinton Keith (24:56) I mean, yeah, think, I mean, a lot of it is, is, it's a tough question to answer because, you know, a lot of it is, I mean, I, I've been in that position myself where, yeah, I was promoted to studio director and my first studio. It's like, okay, now you're responsible for all these games, seven games in development. And, you know, I committed, I said, all right, we're going to stop doing stupid things. Which means like going to a team that's working very well and saying, this other team, they're in a bad place. So I'm going to take half of your team and move them over there. You know, the old Fred Brooks thing is just like, you know, it's like, Hey, you know, it's like, you know, we're going to double their staff, you know, which is going to make it even worse for them, but it's also going to harm you. We're going to stop doing those things because now I'm in charge. I've been through that. I've run individual games and I know the impact. of what that does. And so I wasn't in the job more than two weeks before the CEO came in and said, hey, we don't have enough money to pay payroll this Friday. And I went into a panic because I was like, I just got promoted to a studio that's going out of business. I go half the people are going to leave if they don't get paid this Friday. And he goes, well, just calm down, relax. You know, what we're going to do is we're going to get a loan because Brian (26:10) Yeah. Clinton Keith (26:21) but we have to accelerate this milestone payment. I need you to, we need to start a new team, an eighth game. And I was like, well, we don't have the people for it to start an eighth game. It says, well, you need to go out to the teams and take people from their teams and populate a whole new team so we can get this payment from this publisher who wants to start a game. And it was such a bad idea to do, but I couldn't go to the teams and say, Brian (26:46) You Clinton Keith (26:49) Hey, I need to take some of your staff so we don't go out of business. I just said, you know, it's like, Hey, we have to take some people off your team. And they're like, you very publicly said you weren't going to do stupid things and here you are. You know, so I think, you know, as part of it is it's, it's, it's the culture, it's the leadership. You know, I started about five, six years ago, starting to do leadership training. Yeah. And because it's like, you know what? I keep seeing these. Brian (26:55) Yeah. Clinton Keith (27:19) You know, the team's adopting these practices, but the leadership not knowing what to do with this transparency, with what to do when your game isn't fun early on, and how it's so hard to build an agile culture, but so easy to destroy overnight from leadership doing things like I did. So I built a leadership course that was like, I wish this was the training I had got. 20 years ago when I was put into this position to help navigate some of these issues and help these teams. I there's, I mean, there's, mean, occasionally see cultures that just kind of like beyond, you know, their, ability to recover just too late, you know, to make some of these, make some of these changes, because like I said, we have to get this title. Brian (27:49) Right. Clinton Keith (28:15) Out the door in three months. In fact, these days I just refuse to, I used, I refuse to train a team that's within six months of shipping a, having a big title to ship because it's like, yeah, that sounds great. You know, we'd love to do it, but you know, we're just in the trenches for the next six months. Brian (28:35) Yeah, that kind of heads down and then can't, how do you learn a new process, you know, while you're in heads down mode, right? Well, this is fascinating. And I, you know, I'm tempted to take more of your time. I just don't want to, I want to be respectful of your time and in our listeners time. So it's probably a good place for us to stop. I want to just point out to people, again, your book, Agile Games Development, where you talk about a lot of this stuff. If I'm reading this correctly, it was originally out in 2020, right? Is that correct? Second edition, second edition was 2020. So you've added some new stories and some new elements to it in 2020, right? Clinton Keith (29:09) The second edition, Well, I mean, it was between 2008 when the first edition came out, we had mobile. You know, it's like the iPhone came out and mobile came out and the entire industry turned upside down. So, and I just, we've just learned so much from working with all these studios and what they have discovered is just incredible. it's, mean, it's, I mean, the industry was very agile early on. You know, the console, the arcade developers used to like sneak out prototype versions and Brian (29:22) Yeah. Clinton Keith (29:47) count quarters they collected. When then the 90s and early 2000s, things got so huge, we went away from Agile. And so it was a difficult sell. But in the last, yeah, the last dozen years, it's been fantastic with all these platforms, all these new opportunities, all these new markets. It's almost as if we're not using the word Agile anymore. It's just the way to develop. Brian (30:14) That's awesome. Yeah, that's what Mike said sometimes. Mike Cohn, when we talk about this, he's like, that was my goal initially was to not have Agile be something we even had to name. It just would be software development. And that's just the way that would be the default in doing things. So it's good to hear that at least in some places that is the case, right? It does feel like that's more of the default. That's great. Clinton Keith (30:38) Well, it's no coincidence. Mike was our first coach 20 years ago and my mentor. And I think that I stole that quote from him and glad to see that it's, it's, it's coming true. Brian (30:41) Yeah You That's awesome. That's awesome. Well, we'll put all these links in the show notes for everybody. But again, the book is called Agile Game Development. And Clinton, I really appreciate you coming on. Thanks for taking your time and chatting with us. Clinton Keith (31:02) Thanks for the invite, Brian. Enjoyed it a lot.