Current Episode

Adam Weisbart: Welcome to Agile Answers. I’m Adam Weisbart your certified Scrum trainer and agile coach. Each week I get your questions about Scrum and agility and I answer them here on Agile Answers.

Hello, hello, hello. I am super excited about today’s episode. On today’s episode I have another guest. My guest today is Clinton Keith, the author Agile Game Development with Scrum. I met Clinton years and years ago before I was a Certified Scrum Trainer and I have been working with him ever since at places like Zynga. We have done engagements there together. He is the go-to guy for using Scrum, and Agile approaches for video game development because there’s some very special, particular things that have to happen in game development that don’t happen elsewhere.

While his book, Agile Game Development with Scrum, is fantastic and I recommend it to everybody building video games and even folks that are not building video games — because it’s a great way to look at Scrum and agile approaches, the reason I’m having him on the show today is that he’s come out with a brand new book and this new book is much like the podcast. It’s got actionable, functional things that you can put into practice within minutes of reading the book to help improve your Scrum team. And these practices, there’s 88 of them in his book, can be used in different part of the process, in your daily scrum, in your retrospectives, all different places. While the book is mainly geared towards video game development I think that a bunch of these practices, certainly not all 88 of them, but many of them can be used by anybody.

I wanted to chat with him about the book. We’re gonna give a couple examples of things that you can take away from this podcast and use with your team right away. You don’t have to get the book for that you’ll get it from the podcast, but if you’re interested in getting a copy of the book we’re going to have a little raffle. You can enter to win, from the show notes, one of five copies of the book. He’s about to release it on Amazon, so there’s gonna be some Kindle versions of which you can win, there’ll be five, again, that we’re raffling off of the Kindle versions. He was also number one for quite a while on Leanpub when the book came out a couple weeks ago.

Adam Weisbart: Hey, Clinton.

Clinton Keith: Hey, Adam.

Adam Weisbart: How’s it going?

Clinton Keith: It’s going great. Having a good time here in San Diego.

Adam Weisbart: Yeah, it is good to be here. We’re recording this at the Scrum Gathering. Well, the Scrum Gathering happens tomorrow, so you’re hearing it at some later date, probably a much later date. But nevertheless, we’re recording it. Clinton is the author of Agile Game Development with Scrum. And the reason I have him on the podcast today is that he has a new book coming out that is specifically built with a bunch of answers. And since you’re listening to Agile Answers, I thought it’d be good to give you a pointer to a bunch more answers that are tactical, that you can use day to day with your Scrum team. We’re going to talk about a few of those items now. So what’s the title of the new book?

Clinton Keith: Well, the working title is, because we’re not quite published yet at the time of the recording is Advanced Agile Practices for Game Development.

Adam Weisbart: Great. And so, folks that are listening, just so they don’t tune out, they might not be game developers, but there’s stuff in this book, that’s practical to any Scrum team, I suspect.

Clinton Keith: Yeah, it’s like my first book, it talks about applying agile to game development, and a lot of people out there play games. And so telling stories, I like to tell stories about making games, really connect to their experience about playing them. So they can see see/understand how what they see on the screen is getting to them.

Adam Weisbart: Yeah. And then they can transfer that to the work they do, whether it’s games or not.

Clinton Keith: Yeah, it’s easily connectible.

Adam Weisbart: Cool, so what sort of stuff… I really the format of this book. So since people can’t see the book that’s in front of us, maybe you can sort of walk us through the format of the book and how you have seen teams when you’ve sort of practiced with this so far, you’re beta testing it, use it, and maybe we can talk about some of the questions it answers.

Clinton Keith: Sure. Well, I made games for 20 years, and for the last 10 years have been coaching and training game teams on applying agile. And one of the things that lingers in the adoption of agile is this myth that there’s a set of best practices out there, that they simply have to follow, and if they follow those best practices, they’ll be able to produce great games like a factory. And it couldn’t be further from the truth. It’s all about trying practices, changing things, you know, maybe starting with the practices of Scrum, but then every two to three weeks, experimenting with what changes those practices that will get past some of that pain points that adopting agile makes transparent. And this ongoing experimentation will result in a good set of practices that are ever improving, that results in a method, methodology or process that’s custom to your particular studio.

So what I’ve been doing is I’ve been going around…I get a lot of questions about, for example, “Well, you know, our daily Scrum, answering three questions isn’t really working for us. What should we do? How do we fix that?” And my answer, which usually irritates them, is “What have you tried?” “But just tell us what to do. What’s the best practice?” And it’s, “Well, there is no best practice.” And so this book is basically a collection of ideas or experiments, things that I’ve seen teams try, for example, how to improve their daily standup or daily Scrum by asking a fourth question, “How do you feel about what’s going on?” Do a Roman vote, thumbs up or thumbs down, are we going to achieve our goal in the next week? That’s to get a feel from the team. That’s just one idea.

Adam Weisbart: How have you seen the adding the fourth question to the daily Scrum of like “How do you feel about your current work or about your sprint,” how have you seen that helping teams?

Clinton Keith: Well, it’s funny, because it’s like if you do the three questions, then you say, “What have you done?” Go around the room, “What have you done since we last met? What are you working on next? What are your impediments to your work?” A lot of people feel on the spot to being asked an individual question, and they won’t speak up. They don’t feel emboldened. But when you turn around and ask a fourth question of the entire group, it’s like, “Do you think we’re going to achieve our goal,” and then you do something like a Roman vote which everyone has to give thumbs up or thumbs down simultaneously, even though you haven’t heard of any impediments, that, all of a sudden, most of the team gives you a thumbs down, that’s something that really kind of wakes you up to the team dynamic that’s going on. You know what, people can be very effective on their day-to-day tasks, but all agree that we’re headed towards disaster.

Adam Weisbart: So the fourth question, of this collection of fourth questions, which I assume is a page here in the book, is for everybody, everybody at once. It’s a group thing, as opposed to adding a fourth question to the question everybody answers which is…

Clinton Keith: It could be. And one of the approaches of this book is to list the basic practice and then give you tips on variations of it. So it starts with hey, ask everyone in the group, maybe do a Roman vote, or try asking individually, or do this, variations of it, maybe talk to the board instead of asking individuals questions. Just look at the goal and ask general questions about the goal. Play the game before you have your daily Scrum, so people get a feel. And one of the problems you see in iterations is that you don’t have anything to play until the end of the iteration, when you’ve run out of time. So approaches like that, there’s so many variations of these things. And again, the idea that you should be constantly experimenting and inventing your own practices.

Adam Weisbart: Yeah, so the pages from this book, like for the daily Scrum, for example, help give you ways to sort of break out of calcified work habits of just answering the same rote questions and not really, frankly, interacting with your team much.

Clinton Keith: Right.

Adam Weisbart: I teach this in my class, and I’m sure many people are familiar with it, but just for the people who are listening who are like, “What’s Roman voting,” maybe you can just give a quick description of that, in case people are not clear.

Clinton Keith: Yeah, so Roman vote, it goes back to the gladiator days of Rome when one gladiator has defeated another and he’s standing over him with his sword, and so he looks to the emperor to see, “Should I finish this guy off or spare him?” And the emperor would give a thumbs up, which I recall was to let him live, hopefully they had that down so they weren’t confused about that.

Adam Weisbart: Yeah, you don’t want to miss that.

Clinton Keith: Yeah, that’d be tragic. Or thumbs down, which is finish him off. And so Roman voting, applied less violently to Scrum teams, is basically, it’s like you said, it’s a simultaneous vote, so you get a feel. Everyone has to vote, so everyone gets an equal voice, and one of the things it overcomes is just having the loud outspoken people get their opinion out.

Adam Weisbart: Or the people who don’t like speaking up, they will happily raise their thumb with everybody else.

Clinton Keith: Right, exactly. One of the things you want to avoid is having those people kind of wait for the other people…

Adam Weisbart: Yeah, for a half-second or so, yeah.

Clinton Keith: So yeah, just say, “On the count of 3, everyone votes, you have to vote. Thumbs up means yes to whatever question you’re asking, and thumbs down means no.” Like I said, there’s variations. And one of the tips is you can have a sideways thumb, and have three possible answers to it. And then you basically have everyone leave their thumb up or down or sideways for a second so you can count them up and just get a feel for what the group is thinking. And that leads to further discussions.

Adam Weisbart: Sure, you can have sidebars about those things after the daily Scrum.

Clinton Keith: Exactly, exactly. So a lot of what agile is is about collaborative teamwork, and this is one of those facilitation practices, and there’s many others, that can help your team collaborate more.

Adam Weisbart: Yeah. I love adding the thumbs sideways, I always have that in there, which is “I don’t necessarily think I’m super-stoked about this question, like I’m not going to give it a yes, but I’m not going to block anybody who does think yes.” A thumbs down might stop us from moving forward or make it important for us to have much deeper conversations, but a thumbs sideways is like if you’re all okay with it, I’m okay, like, letting my concerns lay. I trust you guys we can move forward.

Clinton Keith: I may have stolen that from you. I fortuitously steal [inaudible 00:08:53]

Adam Weisbart: I probably borrowed it from someone else as well. But yeah, that’s super useful. Great. So this book has a number of practices and suggestions. I don’t know what that number is though. Do you have a count off the top of your head here?

Clinton Keith: Well, at the moment, we’re close to a hundred, and the idea of this book is to continually grow. So we’re going to really sit, you know, in one of those places like Leanpub, CreateSpace, where you can basically buy it and then you keep coming back and updating it. A lot of these come from game developers themselves. We had a workshop at the game developer conference last month, and they came up with about 30 new practices that they’ve innovated or they’ve even created on the spot at the workshop. So I think we’re just brushing the top level here with practices that will emerge.

Adam Weisbart: So you really took an agile approach, really to creating this book.

Clinton Keith: Right. We created the book using Google Slides, and so anyone can edit, add, contribute, and you know, we freelanced all the proofreading and stuff, and so on a day-to-day basis, we even have a burn up chart that shows where we’re headed and it’s been a very collaborative approach to writing books. It’s very agile. We eat our own dog food here.

Adam Weisbart: One of the things I love about the book, so if I’m going in to do coaching or training with a game company, I always refer them to your fist book and I usually take them a copy, which they say they’re going to read, but often just ends up sitting on their desk with the other books they have not read yet. I keep encouraging them to read it and I direct them to certain chapters, because there’s tons of value in that fantastic book.

But this book, if you’re worried that you’re going to get this book and it’s going to sit on your desk like the rest of your books, because we all do that, is the items are so tactical and small, you can just flip open to a page and say, “Hey, this is the thing we’re going to try this sprint,” or have your team vote on them. A single page contains one of these practices that you can give a try and see if it resonates with your team, if it’s helpful to your team, or if you want to try another one. Super consumable.

Clinton Keith: Yeah. The inspiration was from these hiking books. My sons and I, we spend time hiking mountains in Colorado, and we have these books of trails. And you basically say, “Oh, I’m interested in hiking for half a day or backpacking for several days. We want to go to the mountains. It’s kind of a cold time of the year, let’s go to something lower altitude.” And you’d open up these books and it’d have several different indexes or indices into what are you particularly looking for? You’re looking based on the difficulty, on the area, on the duration, things like that. And then kind of hone in what kind of hike you want to do.

So with this book, we’re taking the same approach is that, “Well, I want to focus on team work and collaboration.” Or “We want to improve how we iterate.” Or “We want to look at scaling practices that we can kind of cross-reference it and look at it from a different point of view,” but all you need to do… The format of the book is laid out so that just, you know, open… Every page is self-contained. Every page has artwork on it and maybe some cross-references, other similar or related practices. And just read one page and experiment, over your next iteration, because really, the benefit of agile is finding ways to get that 1% or 2% improvement every couple of weeks, and that really adds up.

Adam Weisbart: So on the show, I like to have people leave with an actionable item. And so I think we’ve actually already uncovered one, which is general, could be used for any Scrum team, and then I’d like maybe for you to speak to a game-specific one, to close out the show. The one I believe we covered is adding a fourth item to your daily Scrum. So everybody answers the three questions that we’re all familiar with, and then, we have a question like “How do you feel this sprint is going? Are we going to be successful on our sprint goal?” Something like this, and you have other examples there in the book. Then have everyone Roman thumb-vote, as we’ve outlined on that item, and then have a sidebar directly after the daily Scrum if you got some thumbs down or it seems like it sparks som other conversations, all in the hope of breaking out of sort of calcified work habits. So any Scrum team could do that. So if you’re not currently doing that, and you’re struggling a bit with your daily Scrums, good thing to try, I suspect.

Do you have a specific example that the game developers out there might be excited about? And I suspect, this example would probably be able to link back to any sort of work a team is doing.

Clinton Keith: Right. A lot of what comes up in game development is quality assurance. And games are designed to be played for dozens of hours. And so a lot of times, what we do is just do deep quality assurance, re-contesting where we have some person just that plays the entire game with different difficulty levels, and that could take a hundred hours. And my sons used to think that that was just an amazing career path for them to do, but…

Adam Weisbart: Sure, for the first couple of hours.

Clinton Keith: Yeah, for the first… You play for a game for a couple hundred hours and you’re hating life, especially a buggy game. And so one of these things you want to do is find ways of automating deep testing like this. Or just regular testing that just takes a huge amount of time. So one practice in the book is called “Automate the game.” And this is something that came from my experience doing racing games, like Midtown Madness, Midnight Club, Smuggler’s Run, where we had dozens of races with dozens of cars and several different difficulty levels, it would just take forever to play through.

And so what we did was, because we had a replay mechanism, that we just make a modification to the game so that overnight, it would play every single race, every single difficulty level, and the player wouldn’t play it, we’ll just disable the player, and follow the AI cars, the artificial intelligence cars, that you’re competing with. And it would record the times that each car finished for every race, for every difficulty level, and if something changed or something when out of balance, we’d get a log printout in the morning that showed, for example, one time, none of the cars had finished a particular race. None of them had finished. After 10 minutes, it just gives up and goes to the next race.

So we fired up the replay of this and we found out, this is a city racing game, that one of the level artists had just moved a mailbox or a light post just a couple feet closer to the edge of the road on a corner. Now this particular corner, the AI cars were taking a shortcut, jumping up on the sidewalk a little bit, to cut the curve, which in our game was just fine, we weren’t killing people. And it knocked over the lamp post, which came down on top of another car, which caused them to careen out of control. And basically, long story short, when we did the replay, we found, just past this corner was this hill of quivering cars that were just piled on top of each other that… We wouldn’t have found that for weeks or months, even at all. And what would have happened is we probably would have shipped the game, and that race would have caused problems for a lot of players, because you’re talking about one race out of hundreds of variations.

And so it was very valuable in tracking things down like that. Yeah, just adding something like that, adding more automation to have an application run itself or send information through it, I think it’s applicable far beyond the game industry, but it’s just amazing how few game developers do something like this.

Adam Weisbart: Right, especially in that case, in that it seems like most of that has been written. You’ve got the AI cars anyway. You don’t have to go and build a ton of automated…like that automation is built into the game, right? You’re racing against them.

Clinton Keith: Yeah, this just took just, probably, an hour of somebody’s time to implement and get into place. But you also have to understand, like video games, a lot of times, we have a fixed ship date. You know, it’s Christmas or it’s a big marketing even or the start of the sport season. And so this type of work, even if it’s just a couple of hours, and buying a server to run thig thing, a dedicated PC, is considered a luxury. Even though it is, eventually, will save a lot o time and make the game that much better, it’s one of those things that easily gets chopped off the end of the list, because it’s the player… the player doesn’t see this game play itself. It’s not a feature on the box. Its second order benefit, a huge second order benefit, but slips through the cracks.

Adam Weisbart: Right, it’s a not a shiny, new, exciting feature the product owner gets super excited about.

Clinton Keith: Yeah, we ship a lot of new, shiny features that aren’t tested in video games, as anyone who’s played them can see.

Adam Weisbart: So that’s awesome. That example works brilliantly. And even, it seems, maybe even more easily in video game development, which I really say that phrase. It’s usually the other way around.

Clinton Keith: Yeah.

Adam Weisbart: But in traditional software development, that applies too. We often hold off on writing automated testing because we need to get new features off the door. People get excited about that. They’re not excited about the hard work of writing automation. So that is fantastic.

Thanks for coming on the podcast.

Clinton Keith: Thanks a lot, Adam.

Adam Weisbart: If you are building video games and you have not read Clinton’s book, Agile Game Development With Scrum, if it’s sitting there on your desk and you just haven’t opened it, open it now. Read that book. It is super helpful. If you don’t have that book, go and get it. I will put a link to it in the show notes. In my show notes I will also put a link to the contest, the raffle we’re having to give away five copies of his new book, which I recommend you grab whether or not you’re doing game development. It is useful to anybody. Especially useful to people doing game development, but many of those 88 things you could apply to your Scrum team whether or not they are building video games.

That contest is going to be open for the next two weeks, so jump in and submit your info. We’ll let you know if you’ve won one of the five copies, which the contest will end when the Amazon copies of this book goes live. Again, he was number one on Leanpub, so you can go grab the copy on Leanpub or you can grab it on Amazon in a couple of weeks or you’ll get one for free because you entered the contest and you won.

Anyway, thank you so much for listening to another episode of Agile Answers. If you have a question you’d like me to answer here on the show, it doesn’t have to be about video game development it could be about anything, it could do with agile in general, you can go submit that to getagileanswers.com, that’s getagileanswers.com and right there on the homepage you can submit your question. Either a recorded question or if you prefer an email question that stays anonymous. That’s up to you. I look forward to answering your questions next week. Until then, stay agile, never change.