Speaker 1: The most asked question basically is how do we do our project management? How do we have like our Kanban board set up? Because I've talked about it before that you should have one, but I never talked exactly how we do it. I've included like some B-roll footage of our own Kanban boards, but I figured in this video, I'm just going to be walking you through how we do it. So this is not like copy everything exactly, but I want to give you an idea of how do we manage Songs of Evergade specifically. And I'll also talk a bit more about some general concepts for more of the day-to-day operational planning of making your game. I'm going to be making like a little series basically of project management related videos this month because I'm also planning one about more the high-level planning of how do I know when I'm going to release my game and how do I do like the monthly planning basically of sprints, which is something we use, we'll get to that. And then also the book club book of this month is also about lean game development, so a bit more of the project planning at the agile development. So I'm just going to jump right into with the core of what we use, which is GitLab. That's just because we come from a computer science background. We're used to GitLab and very importantly, we can actually self-host GitLab on one of our own servers. So we don't even have to really spend that much money from like a software as a service subscription or whatever. Things like plastic can cost quite a lot and GitHub has some issues with GitLFS like maximum size limits. So we figured, hey, let's use GitLab because it's both our code repository and it's also our issue tracker. And we used to do our CICD through there as well, but we've shifted that away from it now. But you don't have to use GitLab. You can use a mix of, for example, any version control software that is just based upon Git. If you have a smaller project that I think is underneath five gigabytes of size, you can just host it on GitHub and then you can use the GitHub board as well or you can host it somewhere else and then focus on using a Trello or a Notion board to manage all of your issues. The things I'm talking about in this video are what we use, but most of the things, like I said, they are transferable to whatever application you use. And then in that GitLab, we set up groups. So a group is basically one project we're working on. What you see right here is the group for the Songs of Ever Jade game where we have our main Unity game repository, which is the Songs of Ever Jade named one. Then we also have one where we store all of our assets. So this is just a repository where we host like our 2D sprites or our promotional material or our Steam banners or whatever. We don't put that in our Unity project because then Unity is going to take like half an hour to start up and our repository is going to be like 100 gigabytes in size. We don't want that. We keep it all clean in a separate repository just for our files basically. And then only the things we want, like the final sprite sheets or the final model exports, those we take from the assets repository and put it in our game. And then lastly, we have a separate repository just for the configuration of our pipeline files because we use something called TeamCity. We're actually planning a video on that one as well, where it's like a custom language. This is all Jamie's domain, to be honest. It's just version control so we can easily roll back, easily see changes, general good practice. So for most of this video, I'm going to stick to the Songs of Ever Jade repository because it's the one we use the most. This is where we actually use like merge requests where we do all of the stuff that you're supposed to be doing and this contains our Unity solution. As you can see, we have things like, oh, I can see that William just did a merge for our rooms into our master branch like a few hours ago. And now the question is, of course, where do we know what is a priority? How does William know he should be working on rooms? Is it because I'm like, hey, William, work on rooms now? No, that's a horrible approach. What we use is we use a board and this is our current GitLab board. We have a whole bunch of columns. I'll go into them one by one. But if you've ever heard of a Kanban board, we're pretty much sticking to that with a little bit of extra tweaks we did because we're a team. That's also something important that I want to note. Even if you're solo, that does not mean you don't need these boards. These boards are not just for when you're working in teams. We do some stuff that is more specific if you're working in teams, but generally you have these kinds of things. So what we have first is a to-do column. This is our backlog. This is everything we still need to do. And like whenever we think of, oh, we should implement this feature as well. Like, oh, we need to update some spreadsheets or we need to add a health bar for a boss. We put issues of that in our to-do list, but this is not high priority. This is just everything basically that if we want to release the game, this is our checklist. This column should be pretty much empty to count as a finished game. I've quickly hopped over to our Forge industry board here. And as you can see, it's much shorter. We have like three to-dos only and we're probably not going to be doing them anytime soon. But this is when you find out, okay, my game is done. Your to-do list should be pretty much empty. And then once we have that giant list, the issue is of course, what is most priority for us? Because of course we can like implement some items or whatever, but is that really what we should be focusing on right now? So that is where my role comes in. I am more of the producer of this project. I keep track of what is everyone working on and what should our priorities be. And then I go through the entire backlog and we have a extra column, which is the priority column in which we put at most 10 issues of these are the things that should be done first. So right now we're preparing for a demo. We like want to launch it in like a day from when I record this video. So there are some updates that still need to be done in regards to balancing, in regards to timing and things like that. I put that as an issue on our priority board. We need to redo our tagging and we have some like exceptions that we need to deal with as well. Then the advantage here is that if Thomas or William are like, I want to do something, but they don't know exactly what to do. They don't have to always send me a message of, hey, what should I work on now? And they can also know by just looking at the priority column and taking one of those issues that, hey, if I implement this feature, I'm going to have delivered value. Whereas if they just take something random from the backlog and they like implement a bigger boss health bar with like some cool animations, that's not really important right now. Like it's going to have to happen at some point, but it's not important for now when we're building up towards a demo. So this is a very like a live column, basically. The moment someone takes, picks up an issue, I start adding new things. So there's always something to do. And generally like the priority here is also like top to bottom, like start with the top if you can. If you don't want to do the one at the top, just go down the list. But that's generally how our priority column works. This is something that I don't know if this is like very much true agile. It's just something that we have learned for us that it works because we're in a team. If you're a solo developer, this can still work. If you have like way too big of a backlog and you also feel like you're working on things that don't really matter, but you can also do things like sprints, which we'll get into. Then we have an extra column where we just lock like bugs that happen. This is more for ourselves as well. So we let that stack up to about like 10 to 15 bugs. And then either William or Thomas are going to be like, okay, today is bug squashing day. And they just go through the entire list in one go, basically. So you don't have that game of whack a mole where you always like spend time opening a branch, fixing one bug, closing the branch and then having to do the merge request. No, instead we do like a bigger batch at the same time. And then we let it stack up again and we just, once again, batch it. Because of course, you're in the middle of development still. There's no point in the moment a bug will appear, which is normal. Bugs are going to appear to just like drop everything else you'd been working on. If it's not like a critical bug, if it's just something visual, you can ignore it for now and focus on implementing more mechanics first. And then once you're done there, there's nothing in progress right now. But basically let's say, oh, I'm going to do some gameplay updates. I drag it into the progress bar and I assign myself or I assign someone else. This is just an example. I am not going to be doing those updates because it's code related. And then we know who's working on what. For example, there would be some issues in here. Like, oh, William is working on rooms. Thomas is working on adding some more items and I'm doing tilesets or whatever. So we all know what everyone is working on. And then once that's done and you're like, oh, I have finished all of my demo changes. I drag it into the review column, which signifies like, hey, this is going to be a merge request. This is something that needs to be validated either code-wise, which means that Thomas or William is going to look at each other's code and be like, hey, why did you do this? And make sure that both of them know how is our code base, even if they don't actually program specific mechanics. And also, are we sticking to the coding standards that we had set out for? And then otherwise, it could also be something more playtest related to where I actually play the game, try to break it as more of like a QA role. And if I can't break it, if I think everything is good, then we go from the review column to the closed, we merge it into our master branch and we're done. And that's pretty much the entire flow for our GitLab boards. So once again, you can 100% copy this if you want on something like a Trello or a Notion or anything else basically that supports Kanban boards. It's very common right now to find those things. So don't worry about it too much. So something interesting that I want to talk about as well is how much do we build up those issues? How much description do we put in it? And that depends a lot on how big the issue is basically. What we try and go for is making issues where you just need one sentence basically to describe what needs to be done because that's the easiest. I know as well, like Thomas, I'm going to throw him under the bus. He does not read these things. That's like multiple times this has happened where we put something in the review column and I'm like, but you didn't implement it like I asked. And he's like, oh, there was a description. So we've learned that for our team, we should just focus on having pretty self-explanatory titles of what needs to happen. Now, of course, certain issues are going to be monsters. And a great example of that is our base UI. This is one of those issues where you need mocks, where you need a description because I had the vision for the UI and someone else had to implement it. And even then, you just need to write down your thoughts. So this is one of the only exceptions where we really spend some time on writing these things down. That's also something that I sometimes find that you guys may be overthinking. The processes for project management, they shouldn't be managing a game but never making it. There should still be a focus first on actually coding and not spending months planning out the ideal sprint and all of your milestones and writing long descriptions for all of them. We are definitely not doing things the perfect Agile way. I know we have a few viewers also who are like Agile experts in their main job, who will probably be crying right now if they look at this. But this is a bit of how we do it. And this has been working for us pretty well. We're able to deliver pretty much on time with the requirements that we're looking for. So we're sticking to this approach for now. And then brings us to the last like main thing, which is sprints. We use one month sprints for Songs of Ever Jade. For next game, we're probably going to be switching back to two weeks. That's also what we did with Forge Industry now that we're full time. Because we feel like one month is a little bit too long. But generally the idea of a sprint is you want to have a deliverable, if you look at the Agile mythology, by the end of each sprint. And every time you build upon whatever the previous deliverable was. For us, what the one month sprints also indicated was, okay, at the end of every sprint, we create a devlog where we share with our stakeholders, if you're looking at lean, but it's basically you guys who are our viewers, what we have been up to the past month. So we gave them some funny names that were like related to Asian mythology. And then inside of those, you can see what we did in this sprint. So this was like the first milestone we ever did, which is very like crude still. It's like, oh, we need a UI. Like those first like kinds of sprints, you're going to have monstrous issues. But you'll learn to make them smaller as you progress throughout the game, because there aren't like giant issues anymore that you're doing once you're later on in your development process. Now, those milestones, how do you plan them? Those we do with the team. So at the beginning of each month, basically right when the milestone starts or right before the milestone starts, we get together for about an hour, maybe a little bit longer. And we as a team, we decide what our priority is going to be. Because we write down in our milestone description of, okay, what are the main high level goals? Again, I'll go into those in a separate video of how you determine those. But here we then sit together and we're like, okay, these are the different things that we're going to have to implement. And we turn them into issues. We make them as a group basically. So everyone has an idea of what exactly are we thinking when we make certain issues. Of course, we'll have issues being created along the way when we encounter new problems. But most of those tickets, most of those issues, we make in group as well. And that's like a little like monthly ritual that is just basically our sprint planning. And then at the end of the week, we also do what we call the bite me core, where we just look at, okay, how has the development been going the last week? Are there things we need to tweak? And are we still on schedule? We don't do daily standups for now because we're only three people. One thing we do do is that I ask Thomas and William to at the end of every day, send me a message of like, hey, this has been what I've been up to. They don't need to finish something every day. They just need to let me know what's going on. And what I then do is I compose a little daily report email that I send out every morning to the entire team. So everyone is up to date about what's going on. And in there, I also talk a bit more about the priorities and things like that. If you're curious about that, I also share those daily reports on our Patreon. So let me plug that right now. If you want some more in-depth content about how we actually run our studio, then go ahead to our Patreon down below. You get bonus videos once a week. We also do more deep dives into our financials and things like that. So if you're taking like this whole studio thing and running a game dev business a bit more serious, I think you're going to find a lot of value from that. I'll leave a link for the Patreon down below. And that's basically our main workflow. It's nothing too complicated because I don't think, like I said, you should overcomplicate this. Just have a way to write down this is what needs to happen. Have something so you can see what are people working on and just make your game. Get a Kanban board. I don't think GitLab is the most optional solution. It's just what works for us. What works for us may not work for you. And that's fine. Just look at any other Kanban solution and you will be good. So I hope this has finally calmed your questions about how do you do project management? If you do have any other questions, leave them in the comments down below or join our Discord and ask them there. I'll be happy to help you out. And apart from that, thanks for watching and I'll see you guys in the next one. Bye.