The Development of a Dev: Greenlight

The Process

If you read the last installment of this series, you will know that my team's game passed through our studio's greenlight process! What you don't know (unless your psychic in which case I have a job for you) is how I felt about the process and what I learned from it. If I'm going to be honest, the greenlight process felt a bit arbitrary. We worked on a project for two weeks with team members many people had never worked with before, and then had to present a game that would be judged against its peers. This timeline in particular usually led to one of two things happening (sometimes both), the game concept would be rushed or the team would crunch. This is not good practice for making games or working in teams! Rapid prototyping can be very useful in some situations, but I am of the opinion that it loses some of its value when it's used in a situation like this where newly formed teams are competing against each other to have their game (prototype) go through.

Now I want to get back to why I said the process seemed arbitrary, I will use my game and another greenlight game that didn't go through as examples. As you may remember, my team was very successful in the two weeks we had leading up to greenlight. Our programmer had access to an Oculus Rift and the whole team worked very well together. However, a key factor for our game was that we planned to get access to more VR headsets after greenlight so that our devs could test and build the game in the VR space. What actually happened was the exact opposite, our access to that Rift was removed and we were without a headset for 2 weeks. Not only did this slow our development, but it also prevented us from going through with the plan we had to get additional headsets. Currently, we are able to work on our project with the resources we have, but that unforeseen setback offset our success in the first two weeks to a certain degree. In comparison, one of the other teams working on a greenlight project also had what seemed to be an excellent concept, but their only designer was badly ill and couldn't work with them for most of the two weeks before greenlight. Our project could have easily been in that same position if we had lost our access to the Rift headset before greenlight. My point is, two weeks is an absurdly short amount of time to do anything, especially when you are only expected to work on the project for 8 hours a week. Is it the best system? No. But its also not the worst, the process of being cut and adding people to existing teams is an important process to go through and lesson to learn.

The New Team

We have been working together for two sprints (weeks) at this point and the integration of new members has gone wonderfully! We gave heavy focus to getting to know each other through a myriad of meetings and events during the first week; including our foray into an escape room (spoliers: we escaped). Here is an image of us at the venue!

But, just because we are all friendly with one another doesn't mean our workflow is perfect. In fact it is far from it, as can be expected of a new team. We are currently working as two sub teams that meet throughout the week as necessary and share information primarily through documentation and messaging. This isn't ideal for the translation and flow of information, but we recognize it and have been making steady and prompt improvements to how we communicate as problems or shortcomings arise or are forecast. The major problem that we have run into, which is tied into communication, is the team's ability to plan work for the sprint at the member level. None of us have ever worked on a team this big, and we have been struggling to accurately push the correct amount of work into each sprint so that each team member is doing a similar amount of work. More specifically, we have been generally under filling our sprints with work. For this coming sprint we have made two preliminary changes to address this. First, we have made changes to our product backlog items so that they more specifically address features we are planning for in the next few weeks and we are going to be investing more time into doing that continually. Secondly, we are going to invest more time planning the sprint in more structured ways. To outline briefly, the team leadership is going to know what we want to accomplish in each sprint and that will be presented to the team. Each team member will then react and think about how much work that will require of them, if it is too much or too little we will have a discussion as a team and remove or add stories as necessary.

The most important thing that I have learned over the past month or so, is that even one person added to a team can create entirely new team dynamics and will create many new and necessary communication channels. This change is inevitable and needs to be planned for to have a successful integration of human resources. I was somewhat aware of this prior to our team expansion and tried to plan for it to some degree, but I would say that my first plan ultimately failed. I didn't account for many things that would have helped us as the new team was formed, and I would say that was born out of both inexperience and a lack of research. I underestimated the issue to a certain degree and have luckily been able to adapt quickly and propose changes that will hopefully help the team. I know that I will carry this lesson with me as I continue on my developer journey.