A well oiled machine.

Here at Not Robot, we have created an evolving a development process that currently suits us very well. Taking advantage of Trello for our project management platform, we have created a streamlined workflow process as well as an easy way to plan and track meetings. We’re going to explain what we do in order to provide some inspiration for building your own workflow.

Agile

First and foremost: For this post to make any sense, you will need to have some basic knowledge about Agile Software Development. If you’ve never heard about agile, a quick skim of the Wikipedia article on the topic is a solid place to start. You might also find our short article on using agile for indie game dev of interest as well.

The Process: The Overview

Our process consists of week-long sprint iterations with a retro at the end of each sprint. Every Saturday we get together on Mumble and have our weekly meetings: We end the previous week with a sprint review and a retrospective. After the end of sprint meetings, we’ll kick off our next week with our sprint planning meeting. All of us here have paying jobs during the day, so most of the Not Robot work gets done after the sun has set. There isn’t a really good time for us to have a daily standup, as we are all located in different parts of the country. So finding a convenient time to meet is difficult enough for one meeting a week; once a day would not be worth the headache.

The Life of a Card This is the flow of how a bug or feature moves through our system to get implemented

The Sprint Planning Meeting

In our sprint planning meeting we will look at our feature list board and decide what makes sense to do in the coming week. We have a different list for each priority (Must Have, Should Have, Could Have) and in each list is a card for any segment of the project that still has work to do. For each segment, there is a checklist the card with a list of tasks that need to be done to complete the segment. During sprint planning, we copy tasks from these lists onto our sprint board. Once a task has finished development, we will check off the corresponding item on the checklist. Once the checklist on a card is fully checked, that segment is considered finished.

A peak at our feature list board Here’s what our feature list looks like. Don’t worry, spoilers are censored, you’ll just have to play the game to find out everything we have planned!

Another place where tasks can come from is our Bugs board. Any time one of us finds a bug, we’ll make a card on the bug board. The bug board has 3 main columns: Unconfirmed, Confirmed, and Tweaks/Fixes. All new bugs go into the Unconfirmed list, hopefully with a screenshot and adding information on how to reproduce it. Adding screenshots is extremely valuable, since a picture can generally explain things much faster than words can. Plus trello makes adding images to cards very simple.

When a reviewer confirms a bug by repeating it, the card gets moved to the Confirmed list where it waits to be picked up. The Tweaks/Fixes list is a place where we can add things that we feel need to be changed, but aren’t exactly new functionality. An example would be buoys being too high in the water. It’s not exactly a bug, and the buoy card is already finished, it’s just something that needs to be tweaked.

The Current Sprint Board

The Current Sprint board is the bread and butter of our work week. During the sprint planning meeting, we identify the tasks from the feature list and the bug board that are top priorities and transfer them into the ‘To Do’ list in the Current Sprint. When the cards are added, each one is given a time estimate. This estimate is intended to be the actual ‘work time’ a card should take. Butt-In-Chair time doesn’t count, only the actual flow time that a card should theoretically take. If you are working on a 2 hour task but are checking facebook and getting distracted, that card might take 4 hours, but it still only counts as 2. The estimated time is just a rough estimate, and although we intend them to be accurate they very often are not. We use the estimates to shoot for about 10 hours of work per week for each person.

The Scrum for Trello extension makes time estimates very simple, as the estimates are clearly displayed on each card. Furthermore, each list is summed up so you know exactly how many hours are in each column. It even displays the total sum of the entire board.

Once all the work is added and assigned, we quickly review everything we’ve committed to for that week. We all talk and make sure one last time that the whole team believes that the tasks in the to-do list are all accomplishable. If everyone believes, then we commit to the work as a team.

The Work Week

Our current sprint board has a basic workflow of To Do, Doing, Done. We’ll split up the ‘To Do’ list into categories: Business, technical, or art. When someone begins a task, he will move the card to the ‘Doing’ list. Once complete, the card goes into the ‘Done’ list. As the week goes on and cards are moved across the board, we might re-evaluate the work remaining if the original estimate is showing to be wildly inaccurate.

Once in a while, we’ll pick up a card and get stuck on it. Either the feature is using a part of the code we don’t have experience in, or there’s a problem with something that we just can’t get past. This kind of stuff happens, and when it does, we try to help each other out as much as possible. When we get to a point like this, we’ll add a label to the Trello card that indicates there is a problem. This label will most likely be accompanied by a comment on the card describing our issues. Everyone else will see that this task is blocked, and they’ll try to help however they can. If a certain person would be a valuable resource, we can add that person to the card, and then write a comment. This will make sure that the person gets an email notification, so they can respond faster and get the card unblocked.

Some cards depend on others, and that’s just a fact. Sometimes the dependency revolves around a pull request that needs to be merged, or a design card that needs to be finished before the implementation can begin. In these cases, we will add labels to the appropriate “Blocker” and “Blocked” cards, showing that these are higher in priority than other cards. These are the cards we will try to work on first, before cards that aren’t actively blocking others.

When we think that our task is finished, we’ll move the card in Trello to the “Done” column and put in a pull request. Using Github-Trello integration, all of our issues (including pull requests) in GitHub will appear on our Trello board as cards in the “To Do” column. These cards will get a pull request label and are placed at the highest position in the list. When a pull request is created, it means that a different developer needs to do a code review on that new branch. We try to get code reviews finished as quickly as possible so we don’t hold up any other dependent work. If a problem with the code is found during the code review, we’ll let the appropriate person know, and they will work to fix whatever the issue is.

One of the things we try to do every Tuesday is to have team-wide office hours. On Tuesday nights we’ll all try to get on Mumble (The VoIP software we use) for at least a little bit and be available for any questions someone else might have. The purpose of this is to get us together and asking questions early in the week so that if there are any blockers, problems, or puzzles, we can try to get them resolved early. We don’t want issues to hold up other cards later in the week. We’ve also found that having office hours creates a positive feedback loop where everyone gets a large number of productive hours without distraction since we are all working at the same time. It’s almost like having a virtual office.

The Sprint Review

The sprint review is a chance for us to tell everyone what we did in the past sprint. Since we don’t have any formal meetings during the week, we may not all know about everything that’s going on with everyone else. We’ll take turns talking about what we did that week, followed by what went well and what we can improve on. It’s extremely important to be honest during this part, because we can identify and solve problems, whether they are problems with our project management process or our personal work styles. By identifying problems we can find solutions and commit to increasing future productivity.

Once everyone has given their update, we’ll move on to the meeting. We have an entire board dedicated to our meetings. It is a board where anyone can add discussion topics to a list, and we’ll talk about them. This saves time during the meeting in general, as we’ll already know ahead of time what needs to be discussed. Also, by being encouraged to immediately write down any topics we think of, we’re less likely to forget about them. For the meeting we’ll just walk down the list and talk about every card there. We’ll reorder some cards if they make sense to talk about together, or we’ll hold off on others if the entire team isn’t needed to talk about it.

Communication

One thing that we have to be vigilant about is communication. Since we aren’t guaranteed to see everyone during the week, we need to make sure that important questions are answered with key information surfaced quickly and effectively. This communication can happen in any number of ways (Email, IM, Trello, Pull Requests). Trello is particularly effective, because of the nature of card comments. We can write a comment on a card, and any relevant people will be notified and can respond in their own time. The Trello comments are also visible to all team members so anyone on the team can see the discussion, something that doesn’t always happen with emails or IMs. We always need to have the channels of communication open, or else we’ll come to the end of the sprint and someone will have a nasty surprise which should have been dealt with earlier in the week.

Iteration

This process has been working great for us because we are constantly improving on it. Our current workflow version is not what it looked like a few months ago, and chances are it will look slightly different a few months into the future. It’s extremely important to listen to feedback and recurring problems during those sprint reviews and to change your process to adapt to your team. By listening and iterating, we have managed to build a workflow that keeps us organized, despite the fact that we are all full time employees scattered throughout the world.

Let us know what works for you. As always, give us a shout out about things you like and dislike about our process and if you do something similar or different.

UI Artist by Day, Tech Artist by Night

Diversifying your skill set to improve productivity Continue reading

F2P 101: Acquisition

Published on December 10, 2014

The 10 Hour Work Week

Published on November 16, 2014