[MUSIC] Welcome back. So, I've already talked about well, at least for games, why Waterfall is probably not gonna work for us in terms of a project management technique. Well, a big reason for that is because of complexity and iteration, as you've already discovered. So what do I mean by that? So in this slide you can see process complexity. So on the one side you have chaotic projects, which are super difficult to manage at all. And then you have really structured projects, which are a bit more predictable. And in between you have agile projects, projects that lend themselves to some degree of planning, even though they are iterative, they do possess some of those chaotic elements. And so we begin to engage with what we call iterative design, right? Design, prototype, evaluate. We're learning throughout this process. We're learning throughout this process, and so one of the things that we think about when we look at agile methods is to talk about that iterative design process. Again, prototype, experience, revise. You're gonna learn every time, you're gonna learn something about the problem domain every time you iterate on your project. So this is a design philosophy, it's not a tried and tested method, right? It's guidelines. All right? And so the philosophy behind iterative design is to allow the nature of the medium to really have an impact on that design, right? So being open to serendipity, right? This really goes back to that idea of finding the fun. With your first goal really just being trying to get something working as soon as possible. Because once you have something tangible that you can iterate on, life gets a lot easier. And that also speaks to when we started this class. Why we wanted you to start with game development. Learning how to get your hands dirty with a tool. And then explore the design space. One of the important things about getting something working is that you can find problems early and address them, right? Those are key. And you need to kind of always have something ready to demo or test because that's going to provide you feedback. Going back to the design class, it's about prototyping, it's about testing, it's about getting an idea in front of people. And so in that iterative design process, the ability to play something frequently and often is really key. So this is another view of that process. So you start off with determining your objectives. So what you're seeing here is the beginning of what we're gonna start to refer to as a sprint. Where you're setting up some objectives, where you're explorifying and modifying and thinking about how you're gonna do it, you're gonna begin developing and testing, and you're gonna let that feedback in, and you gonna learn from what happened. This is a cyclical iterative process. So you can see at the top, right? We have this arrow of time moving forward. You're gonna move through these different phases. That way you can learn, and adjust, and come back. Iterative projects can deliver a product with about half the scrap and rework activities as the waterfall projects by re-factoring architecturally significant changes far earlier in the life cycle of a development project, right. So the idea behind this is you get a more robust and maintainable product because you're iterating rapidly on it. You're biting off small enough pieces that you can build them, test them, and learn from them, right? And then adjust course. It's all about navigating that process of development. Biting off the right kinds of pieces. The other piece of this that's important is that successfully delivering software projects in a predictable and profitable, ultimately. Because you would like to not spend forever and make some money off your projects, requires an involving mixture of discovery, production, assessment and steering. So that also requires leaders, right, it requires somebody who's responsible for a project. It requires vision, all right. Discovery, production and assessment, right, that's our iterative cycle. And so this idea, the word steering implies kind of an active management involvement and frequent course correction to produce better results. Right, the last thing you wanna do is let somebody go away, build a thing for weeks, and then come back and figure out how to integrate it into the system, right? It needs to be part of that process more significantly all the time, and it requires that management vision up top. So the iterative design philosophy has inspired a lot of different project management techniques. So you've probably heard of Agile Development, SCRUM, extreme programming, and Sigma Six, right? There's lots that have been inspired by this idea. And you should probably go read the Agile Manifesto, because it really does teach us things about developing games. As I said, I kind of quibble over whether games are software because there are a whole lot of things that go into game development that don't go in traditional software development. But the principles that we're really trying to grapple with are relatively straightforward, right. We want to satisfy the customer. We want to be open to change, right. We want our project to be flexible. We want to deliver frequently so that we can test and examing what we're doing. We want to work as a team. We want people to be even more motivated and excited about the projects they're working on. You want people to communicate face to face daily about what's getting worked on, who's doing what. You wanna be able to measure your game. See it progress. You want a consistent pace, right? You don't wanna see everything come together at the very end. You wanna see consistent, measurable improvement of a thing over time. That also lets you excel at quality, right? When people say polish, ultimately what they're talking about is iteration at the end, right? Like fine tuning. Making something beautiful. And so it's important throughout that process to really keep it simple, right? And let your designs evolve, right, let them emerge. And so these are principles that can be applied to software, but they speak really well to game development, which is why so many game developers turn to Agile methods, and in particular SCRUM. But also reflect regularly. Ask yourself what's working, what's not working in this process. How's your team looking? How are people doing, right? So those are all really important questions. So we haven't quite arrived at SCRUM yet, but we'll get there. I appreciate your time. See you on the next video. [MUSIC]
