This is the fourth part in a series on applying devops principles and practices to game development. The first post in the series is here, and the entire series can be found under the devops in game dev tag.
In our post on retrospectives, we wrote about taking note of lessons learned (good and bad) after emergencies or breakpoints in your project—after you deliver a feature, or at the end of a sprint or some unit of time. But how do you know what a good breakpoint is? How do you actually incorporate what you've learned in a retrospective into your future work?
Through effective project planning.
I'm not going to go into the very basics of project planning or project management here; I'll assume that you know how to break a project into components and features, and those into smaller tasks that you can estimate (reliably or otherwise!) and work on to completion. You might be doing some form of Agile, iterative prototyping, kanban, or that weird risk-based spiral method that I've never actually seen in action.
It doesn't really matter, so long as you break stuff down and have some sense of upcoming work. It might not always be accurate, but "I'll just keep coding and making art until it seems like a good game" doesn't fall under this umbrella. It might work well for your team (especially for small projects, like game jams), but it doesn't offer many points of entry for reflecting and improving, process-wise.
What's of interest here is how a devops philosophy influences project planning.
Motivations
Here are some common reasons for even bothering to do project planning:
- To know when you'll be "done", either by the number of features or the time remaining
- To make sure you don't forget an feature, idea, or bug
- To help coordinate a team of workers
- To try to predict the cost of a project
An important thread in these is a desire for transparency. To be able to lay out a list of most of what's been done and most of what's left. To be able to know what each of your teammates is working on at any given time. To be able to say how much more money a project is going to cost.
Once you have insight into how things have gone, you can reflect on it and improve it if you need to.
What You Should Capture
We try to capture just about everything. The obvious things to make sure are in your planning are development tasks, testing, art asset creation, and music creation and editing. But there's a whole plethora of "soft" work that takes a lot of time and often gets put off or wedged in around what we tend to consider "real" work.
Are you in a phase where you're interacting a lot with press via email? Allocate time for that.
Is your bizdev work something you can describe pretty clearly? Allocate time for it.
Do you have a marketing plan for your game? Treat it like a "feature": break it down into tasks and put those tasks into your weeks/months/sprints, paced in a way that gets it done.
Do you write articles, blog posts, or newsletters? Make those tasks. If it takes you four hours to craft a blog post, that's work, and it's four hours you aren't spending composing music, for instance.
Community management. Unusual accounting efforts (e.g., yearly tax time). Video editing. Prep work for a conference.
Retrospective Examples
When you're having a retrospective, there are several types of planning-related items that might arise:
- Problems
- Our estimates are too high/too low
- I couldn't finish my allocated work in time
- I finished my work too quickly compared to my teammates, so we were out of sync
- I wasn't sure what I was supposed to work on
- My work didn't seem to be useful or relevant to our goals
- Successes
- My estimates were accurate/more accurate than the last time we held a retrospective
- I finished a new feature on time/ahead of schedule
- Quickly adapted our schedule to an emergency that occurred
- Documentation that we wrote helped us finish a particular task more quickly
Two of the questions to ask in a retro are "How can we fix what went poorly?" and "How can we keep doing what went well?". When it comes to project planning, there are a lot of ways to make changes. Documenting retros ensures you have a log of things you've tried and whether they've worked.
Here are some specific things to try for each of the above problems. Even if they aren't directly helpful to you or your team, they may foster some creative ideas.
Estimates Too High/Low
Figure out what part of the work was wrongly estimated and how. Did the person hit a snag? If so, note that that kind of work is tricky so future estimates can be better.
Was it the first time they'd done that type of work? If someone else had done it before, figure out where the knowledge transfer went wrong. Were they inventing something new and undocumented? Next time, give more buffer in the estimate.
Is this a trend for the estimator? Try more evidence-based estimates for their work. If they consistently take twice as long as they should, start doubling their estimates. It's nice to be able to drill down and figure out why someone's estimations are terrible, but those investigations can happen in parallel to the project's plan being more accurate.
Couldn't Finish Work in Time
This can be poor estimation, as above. This can be that the team thinks they have a rockstar/ninja that they can keep putting more work on. If so, remember that success isn't someone hitting a specific number of finished items within a unit of time; it's that they finish what the team planned for. If they can't finish it, reduce the amount they're expected to get done. Realistically setting expectations doesn't have to be a value judgment or a career-changer.
They might be getting a lot of untracked work—maybe spending time helping colleagues, putting out fires, consulting on other projects, or helping design future work. That work should either be captured or they shouldn't be expected to get as much work done that is tracked.
Finished Work Too Quickly Relative to Other People
If some work depends on other work, then you have a planning problem when people are left waiting for things to get done. There are obvious examples, like needing music to be composed before it can be coded into a game, but here's another example.
Here at Future Proof, we test each other's work. If Gregory does the development on something, then I (Melissa) do the testing before we deploy. It's not a perfect system, but it works pretty well for us. That said, Gregory works more hours per week on FPG than I do, so we can often end up with a queue of items waiting to be tested and deployed. This becomes a noticable problem when Gregory needs to work on new items that are dependent on those older tasks being tested.
One fix for this is to have a portfolio of projects that need work. If the project being clogged is the one in full swing, let the person work more on an up-and-coming project until other folks catch up. Try to make it important work, even if it's not currently high-priority; you aren't trying to fill a timesheet, you're trying to make cool things in an efficient-enough way.
Not Sure What to Do
This is often a communication problem, at its core, and is worth drilling into with the person.
Perhaps there weren't enough details in your project management system, so they couldn't pick up and run with their work. That's fixable—when you talk about what work you'll be doing for the next week/month/etc., give people time to look through their work to make sure they understand it. They might still hit snags, but they should at least know how to tell when they're done.
It could be that they weren't sure specifically how to tackle a problem or feature. This is common with vague or hard-to-reproduce bug reports. We sometimes split things like that into separate "investigate" and "fix" tasks, which can help.
It's also worth asking why they didn't ask what to do before you held a retrospective. If they sat and did little/nothing for the entire time between retros, figure out why they didn't switch tasks or talk to someone.
Work Felt Irrelevant
This might seem obvious, but people shouldn't feel like they're wasting their time. You and everyone on a project should know how what they're working on is helping them make cool things. Even if something is throwaway or part of a throwaway prototype, it should make sense why it's necessary. (This means getting rid of power plays where Important People ask for things just because they can!)
If you have a sizeable enough team that not everyone is involved in all the marketing or design—and if people seem to be feeling like what they're doing day-to-day is useless—try to surface how you've designed your marketing or your game. When you're talking through upcoming work, talk about its context for the project or the company.
We're pretty touchy-feely people here at FPG, so our games are tightly connected with our company's mission statement of exploring transhumanism and demanding audacious compassion of players. If there's work we're bouncing around that isn't keeping our velocity in that direction, we question it, and we pretty quickly notice it's useless.
Final Tips
Listen, notice, and adapt: three of the tenets of a devops philosophy which are readily adaptable to project planning. None of the above items are massive changes. You can try different ways to solve a problem over the course of a few weeks or months (depending on how often you retro). If something you change doesn't improve the situation, try something else.
You (generally) don't need complex project management software. A list of stuff to do, stuff in progress, and stuff complete can be enough, especially for small teams and projects. If you care about time or effort (perhaps in story points or t-shirt sizes), then something to track estimates versus actual time is useful. I won't provide a review of software here, but feel free to ask or chat in the comments about specific tools.
All in all: "Don't get stuck in a local maximum." If there's a project planning-related item in your annoyances file, bring that up in retros and try to address it.
Our Games
Exploit: Zero Day is our cyberthriller with a living story. It's in closed alpha for the moment, but you can get access by joining the mailing list. You'll receive an access code in the next monthly newsletter. YouTubers, streamers, and press, request a copy from distribute().
Our first release, Ossuary is available on Steam, itch.io, Humble, and IndieGameStand. Press-like people, you can also request a copy of Ossuary from distribute().
View on YouTube
