Improving Processes in One-Man GameDev Shops

Question

As a hobby programmer, how can I incorporate a continuous-improvement-like process like Agile's retrospectives in my processes?

I've tried bullet items of three good/bad things at the end of each project, but I feel it's not enough. And I feel that a sprint retrospective is overkill. Where's the balance? How can and should I open the door for continuous process improvement?

Or maybe this question should go on the beta Project Management Stack Exchange site?

Answer 1

As this is a personal project, you have to be very careful not to get bogged down in process. While continuous improvement is very desirable, consider choosing elements from Lean and Agile that are philosophically in-line with the simplicity of a one-man-show.

In Scrum and many other systems, sprint retrospectives are beneficial, as they provide time for a team to identify improvements. In Lean, there's frequently a focus on solving a problem as it arises, and I think this is where you could greatly benefit.

When you identify a nasty bit of code or an issue, flag it and take a moment to do the following:

1. Look at where the problem resides
2. Look at the interacting elements and systems
3. Find a quick solution (something that works, what we typically do and stop at)
4. Identify the root cause (ask the 5 why's)
5. Generate a more fulfilling (possibly even standardized) solution or plan for a solution (possibly something to be implemented after this project or sprint)

So, this is taken from the five golden rules of Gemba management and fiddled with to match your scenario. To some degree, it's still not super applicable. Your mileage will vary and you'll have to adapt; but, there's good news: that's all part of Lean!

You need to adapt whatever processes you can find to be "right fit." This is going to be something you'll have to continually improve upon, in and of itself.

I hope that makes sense. I can provide more specific references and comments if you'd like.

EDIT (in response to question in comments):

To get started, I'd suggest visiting LeanBlog.org. You might want to read this article first. It's short and full of pithy quotes. Most of it is about healthcare; but, you'll really rapidly see how it also applies to games.

Not to toot my own horn, but, I wrote an article on gamasutra about standardized work and it has some great resources in the comments section as well as ideas. You can find it here.

I would highly suggest checking out Menlo Innovation's blog. Most of what they talk about is applicable for larger companies; but, you should be able to adapt it.

I'd be interested in finding out your results after a few months :)

I hope those links help!

Answer 2

Although at work we use JIRA for this type of stuff, I adapted a version of it for my own use in gamedev at home. It may or may not be a system that works for you, but I'll add it anyway:

1. Get some index cards and somewhere to keep them - a few piles on the desk works just fine. Mark these piles "Not Started", "In Progress", "Blocked", "Needs improvement", and "Complete".
2. If I think of a task that needs to get done, I immediately write it down on an index card and give it an estimate of difficulty/complexity
3. If a task I'm currently working on is blocked, I write the reason why on the back
4. Unless the task is a blocker, don't do it until you have to (or until you're out of unblocked/in progress tasks)
5. If all of your tasks are in the Needs Improvement or Complete stage, start working on those that need improvement.
6. ????
7. Profit!