I am the producer for our company, Druor LLC, formed as a part of the game design program at Indiana University. We started as a team of three and over the course of the first year of our two year development we grew to a total of nine members. Our program required some amount of work tracking for determining student grades, and beyond that it was up to us how much and what we would track. I received Disciplined Agile Scrum Master certification right before the start of development, and using the knowledge gained from that I implemented a variety of administrative tools and work systems for task creation, tracking, and updating that changed over time. The biggest hurdles that created modifications to our tracking methods over the two years was a changing buy-in from team members in how much and what specific administrative work they would do, having zero budget, and not having usual employment levers such as reprimands or raises to incentivize behavior. In this post I will discuss what methods we used, why we used them, and how I worked around the described hurdles.

Team Composition

In the initial stage of development we had three then four team members fairly rapidly. Initially we had one programmer, one designer/generalist, and a second generalist with a fourth support person that just did a few character art pieces. As the team grew over the first year we built up to two programmers, two designers, one artist, one composer, and one producer/UI artist/generalist. Once we gained an additional two programmers we designated one person as the lead programmer and he started handling the tasking for the four of them, which reduced the admin workload on myself quite a bit.

Sprint Structure

We employed a one week sprint structure for our work process. The one week sprint as opposed to a more normal two or four week sprint was used for two reasons: the game design was changing rapidly, and we often had weekly assignments for class with goals that would change week-to-week based on the previous week’s work. This structure allowed us to move nimbly between designs, and would result in scrapping a week’s worth of work rather than two when we’d figure out something wasn’t fun, didn’t look good, was unrealistic to implement, etc. This would only require one meeting a week from the team.

We would meet once a week to perform sprint planning. Initially this was a two hour meeting but to save time I started sending out general goals per department for the coming week the night before the planning meeting, and everyone doing work would create tasks themselves on our sprint board that we would then all review together. This resulted in better attendance as the two hour meeting was too long for many.

Administrative Structure

For task tracking we used a combination of HackNPlan and daily stand-ups performed asynchronously. Getting everyone to create their tasks was pretty easy, but getting buy-in to the stand-ups grew more difficult as the team grew larger. Initially with a smaller team everyone would do the stand-ups daily and include the time spent on tasks in the stand-up and on their tasks in HackNPlan. This was before we had premium HackNPlan so we did not have access to automation features. I would check the hours recorded in the standups and record them in a sprint burndown, as shown below. These burndowns proved useful as we could see how our team tended to do work over the course of a week, and check-in halfway through to see if we were going to make it. Via the burndowns I discovered our team tended to not do much for the first few days, then crunch everything in the last couple days. A typical sprint example is shown below.

Buy-in and manual tracking was easy with a smaller team because I could just direct message members to remind them to log their work or do their stand-ups, but as the team grew in size this became unrealistic as it would’ve involved too much time on my end just asking people to do their admin work. This became a reinforcing cycle where once one person wasn’t doing it, then two wouldn’t, then half wouldn’t, until the stand-ups became unused and people were mostly not logging hours at all. I negotiated with the team on what amount of admin work people would be willing to do without my constant supervision, and that resulted in nixing the daily stand-ups, replacing them with a stand-up during our two class periods a week that no one could avoid, and rigorous use of the HackNPlan. The HackNPlan has an automated burndown feature so this resolved most of the issues, as long as people would log their hours. Over time this began to fall a bit too so I found the easiest way to enforce it was by ensuring everyone had their current hours logged when we would meet for our class stand-up, which meant hours would be logged at least three times a week. Three times a week guaranteed minimum ended up being a pretty solid work approximation for the new burndowns.

Lessons Learned

There were two lessons learned from these changing management systems. First, no one likes doing administrative work. Even if it’s very minor and just takes a few minutes, most creatives just want to focus on making stuff and not typing up hours and tasks. There was a trend with this that the programmers tended to be better trackers, but was not always the case. The second lesson learned is that when you don’t have levers to enforce behavior such as financial incentive or employment status, then you have to negotiate with your team from the perspective that this is also for them, and be willing to give a lot more ground. I learned how to convince the team members that some amount of administrative work was beneficial to them as it would allow for greater efficiency in communication while working asynchronously or when members would work on tasks together. I also learned what things to change to make a system as simple as possible to achieve the highest amount of buy-in.