Learning from previous mistakes and Scrum

Every time you start a new project, it is a good opportunity to look back on your previous projects and figure out what went well and what didn't. This is my third project as Lead Engineer, so I have a couple of previous experiences to reflect on.

The first project I was lead on was a game called Fat Knight, it was a great little base defense/hack and slash mixture that was worked on in a 6 man team. We didn't use scrum software but we kept and organized list of tasks that needed to be done. In addition, we also kept a reasonable scope throughout the project, cutting when need be. The final project, while not having all the features we wanted originally was polished, fun, and something I am proud of.

The second project that I was lead on was called National Photographic. This game was supposed to be an educational game created as if we were a client for National Geographic. The concept of the game was free roaming Pokemon Snap. You would travel to an area (in our case Yellowstone) and would wander throughout the environment trying to take pictures of animals and learn about photography and animals at the same time. We even had National Geographic interested in coming to see the game, but the final product was nowhere near good enough for us have National Geographic come look at it.

On this project we had a 9 man team to start (with 2 extra artists coming on at the end), with enough talent to actually make a good game, but it went wrong along the way. The project was over scoped from the start, and with something as ambitious as our original idea, we needed to be really organized (but we weren't). I am not here to blame the other leads, but to learn from what I did wrong to make sure it doesn't happen again.

I started off with the right ideas, I created a scrum spent 4 hours populating it with what needed to be done from an engineering standpoint, invited my team members, and even put in some example tasks that the art lead could start with when he started using it. Things were going great for the first week, the engineers were all marking the tasks they were working on and when the finished them, but by the second week nobody was using it anymore, at which point I made a couple of mistakes. The first that rather than forcing people to use the scrum tools I asked if they were interested in using it, to which they replied no. I should have said we were going to use the software regardless, but I really didn't like how time consuming it was (free software is unintuitive at times) so I put it up to a vote. So the scrum software was out and I made my second big mistake, rather than keeping my own physical copy of tasks and progress I just kept it in my head. In hindsight, I should have kept my own spreadsheet of tasks, it doesn't take as long as setting up the tasks in the scrum software we were using, but it still would give me an estimate on how much still needs to be done.

This early mistakes hurt us later on in the project, because we had no list of what needed to be done and what had been done, it was hard from a management standpoint to make sure everyone was moving at the correct speed. It is easy to make the argument that people weren't getting their jobs done so that is why our finished project wasn't that good, but the reality is that it was my job to make sure people were getting them done, and I did a not so great job on that front.

Now that I have made myself look like a horrible leader, lets look at options to make sure both yours and my future projects go along without as many bumps along the way. I am going to talk about Scrum for agile development. If you look up on scrum on Wikipedia it says, “Scrum is an iterative and incremental method for managing software projects and product or application development.” Scrum tools allow you to create tasks (user stories) of a given priority with an estimated time till completion. At the beginning of your sprint (A short period of development time ranging from 1 – 4 weeks), you pick unaccomplished tasks and assign them to people on your team. You are able to use the previously mentioned time estimate and priority to make sure everyone has reasonable goals and that you are working on the most important features first. Recently scrum tools and agile development have caught on and now there are hundreds of software suites that you can spend a decent chunk of change on. These suites provide a lot of nice tools, that on a indie or student project, you will most likely not use, so don't spend the money. Burn down graphs and all the fancy stuff are nice, but when you boil it down the really helpful parts of scrum tools are:

-A list of what still needs to be done for the project (tasks).

-How much time it will take to complete each task.

-Who is working on which part.

-The priority of the task.

There are a lot of free ways to do this: a google spreadsheet, a whiteboard, sticky notes, etc.  Even if you are the only person working on the project I suggest you do some kind of task list. The reality is that you can't keep everything that needs to be done in your head, and if you are working with a team that can't see the list in your head. When people get done with their job early and want to work on something else you want them working on something that helps you make your current deadline, not working on a main menu you don't need for another year. Another thing that the prioritized list helps with is scoping/cutting. Cutting from your project is always a somber moment, but it will happen with most every project. If you have a prioritized list it become easy to figure out what features are not integral to the game and cut those. Even more important is that if you are cutting items that are of lower priority, and you have properly assigned tasks, you may be able to cut items that haven't been worked on yet. The only thing that sucks more than cutting a cool feature, is being the person who has been working on that cool feature for several weeks (I know, I have been on both sides).

When your working on a project you need to be organized from the start. The longer you wait the more difficult it becomes to get back on track (believe me). I know populating the list isn't as fun as programming, but in the long run the time you spend organizing will make for a better finished product than getting the AI system done 30 minutes earlier.