Pre-production wrap-up
Second post with this new template that I wanted to try…and I am already breaking it. That didn’t take too long!
I like the idea of ‘Quick hits’ and ‘A closer look’ but this week all of the things I want to talk about are all ‘A closer look’ material. This week there are four of them. I hope you find this information helpful or at the very least interesting…
A closer look - Remote work
For our first year at AIE, all learning was done remotely due to covid restrictions. I must say, meeting my fellow classmates and working with them in a virtual environment was a lot different from how I worked with others in the past. Overall, I would say it was a good experience and I believed it helped that we started the year fully on-line and not having to make the change mid-year. At the start of the second year, all classes were back to in-person. We have continued to learn and work in-person…until this week.
On one of our days off, the Head of School for AIE sent out an email informing the student body that the school will be getting HVAC work completed. As a result, the school would be closed for in-person learning for several weeks. I knew that this sudden announcement could cause stress and worry within the team. It could be a large shock to change from in-person to remote work and I wanted to make that transition as smoothly as possible for all team members.
To help with that transition I wanted to create and communicate a plan to the team. The goal was, if a team member was blind-sided with the news of remote work, they were also learning that there was already a plan in place. There were four areas I wanted to address with my message to the team.
I wanted to inform the team about this change as soon as possible. In addition, I wanted to reassure them that I had a plan in place, and we had time to work any issues that could come up before going remote.
We needed to ensure that all work we pulled from the backlog was work we knew we would be able to accomplish while working remotely. The start of remote work coincided with the start of a new sprint.
We needed to take care of the technical things before going remote. This included setting up the initial Unity project we would be using to make the game. As well as getting the team set-up with version control (P4V) from their home computers.
I needed to ensure that each student had the equipment they needed to perform the tasks they were going to do. AIE provided computers and other equipment to students that did not have their own, while working remotely.
Below is message I sent to the team.
Umbrella Studios, how is it going? After reading Ursula's e-mail, I wanted to drop this in teams to go over the game plan for the next few weeks. 'What was in her email?' you might ask, and the quick answer is; Make sure to clock in and out when going to school, there is now an option for at home learning and (the rumors are true) the school will be closing for a few weeks to add AC to our rooms! Ursula will go over these things again during this week's lunchbox.
What does this mean for us? Not a whole lot, but there are still some things I would like to do to ensure we remain on track during production. First off, this will cut into the first week of our prototype sprint. We need to make sure we know what tasks we need to accomplish while at home and we have the tools and equipment to get those tasks done. Second, I know Ursula's e-mail said we will be back in school March 28. But I want to PLAN assuming the construction goes over the time estimate and we will be doing all of the prototype sprint remotely. So, over the next week or so, here are a list of tasks we need to do to ensure we can keep making the best Major production game this damn school has ever seen!
-We will set up initial unity project file stuff (Ryan)
-Make sure version control is set up in class with step-by-step instructions to set up from home (or be able to walk someone through it over teams)
-Team understands what assets are needed for our prototype deliverables
-Team has the items they need (equipment and programs) from home to complete those tasks.
I will need to get with Aaron to see if we can get the list of items we need to turn in at the end of prototype.
I didn't want to ping anyone on here because I wanted you to enjoy your time away from class. But at the same time, let you know there is a plan in place. Take it easy and I will see everyone on Wednesday
This message was then followed up with in-person communication on that Wednesday during our morning stand up. As of this writing, we have not started the remote work, but I will update you with that progress in the future.
A closer look - Planning poker and user stories
For the entirety of my time at AIE, we have been taught and were using tasks and hours to track progress on projects. So, while using our project tracking software, HacknPlan, we would have a list of tasks that needed done (create X texture, debug Y issue, document Z mechanic) then assign how many hours we think it will take to complete those tasks. On the first week of production, some of our instructors suggested we look into using ‘Planning poker’ for time/work estimation and use ‘User stories’ to break up the work into deliverable chunks.
I had not heard of planning poker, but user stories were something I was aware of but did not 100% grasp the concept. So, I spent some time over the weekend researching these two methods. I did not want to make a decision on these topics without speaking with the team about it. Considering they would be the ones doing the work using these methods, I wanted the final choice to be theirs.
User stories - Before doing some research, my understanding of user stories was that there is an aspect of the game you wanted to have completed within a sprint. At the end of that sprint, all aspects within that user story are completed and final. In this case, let’s say the player jumping. A user story would look something like, ‘As a player, I want the ability to jump, so that I am able to dodge attacks, move around the environment, and climb on top of boxes.’ As a producer, coming up with tasks to complete that user story would include items like, design coming up with specifics about jump mechanic, programmers getting these systems working in engine, art team has fully done player model, animation need to be done for jump/in air/landing and, level design so this new mechanic and be tested.
To me, that seems like a lot of work for a team of 7 to do within a sprint. Depending on the user story and how the work is divided, there seems to be a high risk of waiting on dependencies that could slow down production.
I did some reading about user stories with the book Agile Game Development by Clinton Keith. In there, I learned that you wanted user stories to start larger (epics) then continually break them down into smaller stories until it is small enough to be completed in a sprint. With this in mind, maybe my example from before wouldn’t have to include the jump animation? or the fully completed character model? Another thing that I took away from my reading, there seemed to be a lot of meetings with the stakeholders about what they wanted from each user story. Within our project, it seemed we would spend a lot of time in meetings trying to decide what we want to make and not giving us enough time to make it. Please keep in mind, with a team of 7 people, each team member is doing multiple roles and a lot of work can be lost if those individuals are not given the time they need to work.
Planning poker - This is something I did not know anything about when I first heard of it. After doing some initial research, this is my understanding on how planning poker works. The team meets to talk about a task/user story that needs to be completed within a sprint. Each team member is given a set or cards or items with numbers on them. At the same time, all team members display a number representing how long, or how much work, they think it will take to complete the task. Conversations are had about the working needing to be done or breaking it down into smaller pieces. At the end, there is a consensus, and the team is saying they can complete X units of work/effort. Then over the course of development, the team learns to adjust that number based off of past performance.
My main concern with this approach is that my team is comprised of cross-functional members. I fear that they may over and underestimate work due to them not being 100% knowledgeable about the task at hand. We could spend a lot of time having these conversations than what our schedule would allow. Or this could be used with a more experienced team when working with user stories? I just don’t know enough or have experience with this method.
Conclusion - I presented these findings and my concerns to the team. We all agreed that it would not be best of us, at this moment, to adopt these methods into our project. It mainly boiled down to us not knowing a lot about these methods and we did not want to complicate production trying to implement something new. Especially on a project as important as this one.
Personally, I am interested in seeing how User stories and a system like Planning poker are used within the industry. I think they address some of the key downfalls of a traditional set-up, like we are using. Just wish we had more time in school to go over or use these tools.
A closer look - Storyboarding
At this point in development, we had a pretty good idea of the things we wanted to implement in the game. We wanted three randomly generated levels each with their own boss, several cutscenes to help tie the narrative and user experience together, a dungeon crawler mode, and a player tutorial. Through conversations with the team, I was starting to get the impression that we were not on the same page. None of us had the same vision on the order of events the player will experience while playing the game. Clearly, this was something that we needed to remedy and the sooner in development the better.
So, during some downtime I got the design team together and I asked them to draw out the game scene by scene. As I thought, the design team all had different thoughts on how events played out and when. We spent the next hour going step by step, trying to create a gameplay flow that we all saw the same way and also achieved our objectives of the game. This exercise was not pretty. At several moments myself and the design team were getting frustrated with the progress we were making. Fortunately, no one was taking anything personal and we all understood that this is something we needed to sort out before we got too far into production. If we waited until later, the headbutting would have been much worse.
After we cleared the major roadblocks of when the blood rain scene and player tutorial happened, the ideas and momentum really picked up. The conversation got so animated, in a good way, that other members of the team joined in and offered their opinion. After a little over an hour, we had a base we all felt comfortable using and we were all seeing the game through the same lens.
What made this experience really stand out in my mind is what happened afterwards. The team and I finished this exercise and moved on to other tasks. We left the dry-erase board in the room, thinking nothing of it. Several hours later, a fellow student from another team asked me what was on the board. I gave him a quick rundown of what we did and why I thought it needed to be done. I said something to the effect ‘You would be surprised how many different opinions you’re going to have about just the title screen and the menus.’ He thought it was a good idea then proceeded to steal our dry-erase board to do the same exercise with his team. At the end of the day, another fellow classmate of mine, who was also a completely different group, came up to me to talk about this cool thing he saw another team doing with storyboarding on the dry-erase board! I think it was awesome that my simple little idea and exercise found appeal with other teams and helped them in their development. At the end of the day, we all want to help each other make great games.
A closer look - 1-on-1s
During my career at CarMax, I learned how valuable a well-executed 1-on-1 could be. Most people seem to think it is a wasted time. In my experience, I think that is true when neither participant is really trying to connect with the other. When the person is only asking the questions on their sheet of paper and when the person answering the questions are giving the answers, that they think management ‘wants to hear’, nothing is really learned. Defeating the whole purpose of a 1-on-1. I think it is a great opportunity for both individuals to take some time and learn something new about someone whom you might not work with on a regular basis. That is why during all the 1-on-1s I conducted as a manager; I spent several minutes talking about anything unrelated to the topic of the 1-on-1. I was fortunate enough, when conducting these meetings, that most of the people I was speaking with I had worked alongside for years or was part of their hiring process. It was easier to start the conversation with ‘How are you liking the job so far?’ or ‘I know you moved from the parts department to the business office. How’s that change been for you?’ It helped open up dialog and build trust. Once that happens, open and honest conversation is easier to accomplish.
That is what I wanted to bring to this team. If there was going to be any issues with team members not working together well, or someone not happy with the work they were doing, I wanted to hear about it. If done correctly, a 1-on-1 will get you that information more reliably than hoping someone speaks up during a sprint retrospective.
For our first 1-on-1, I wanted to keep things simple and hit on some of the larger topics and themes of the project. I did not want to dive too deep with the questions, considering this was a new project and new team members. I wanted to use this meeting as an additional way for my team to view me as a recourse and a leader. Below, is the list of questions I asked and a little of the reasoning on why I asked them.
Overall, how do you feel about the project? - Wanted to open with a very general softball type question. I wanted to ask a question open enough that if there was a concern of scope, theme, team members, pipelines, or anything else, I would hear about it. I could also gauge how interested and excited for the project based off their answer.
At the start of the project, you told me the skills that you wanted to show off. With our current plan, do you think you will be able to do that? - As I mentioned in a previous blog post, one of the main ways I wanted to get buy-in was from the team members working on aspects of the project that they think will help them get a job. The question was meant to confirm that we were on the right track to do that. In addition, it reaffirmed to my team that I am placing their needs high on the priority list.
What can I do better? - I feel like this is always a great question for any manager to ask. Noone is perfect and getting feedback as soon possible helps, not just the manager but the whole team as well. I was very clear with the team that if I was doing something incorrectly, or something they did not like, it wasn’t going to help anyone if they waited two months to tell me about it.
Are you open to team builders? - Team builders were a great way to build team morale and generally have some good fun all around. This was especially helpful at CarMax and for our minor production game Hockey at Pacific Science Center. This question was mainly used to gauge their interests and when they would be available to do an event like this.
Can I use your name on my website? - I told the team about my plans for creating this website. I knew there might be a situation or two where I would need to use someone’s name and I wanted their permission before doing that. I also reassured them if what I was writing could be viewed in a negative light, I would not use their name and only refer to them as a team member.
Are you having fun? - Super simple question. No wrong answers. If we are not having fun, we are not going to go our best and make the game we all want to make. Another way for me to gauge the pulse of the team.
Below is a very general group consensus on their answers. I was able to get a few good take-a-aways from these questions.
Overall, how do you feel about the project? - Team felt good with the overall project. A little apprehension from some members wanting to see some pieces come together before they were fully comfortable. One team member wanted to be involved a little more in the narrative side and another was a little worried about scope.
With our current plan, do you feel like we will hit your goals? - Team felt like the initial plan would help them achieve their goals. Not a lot of conversation from the team on this one.
What can I do better? - Most of the team said there was nothing that I could be doing better. I reiteraited to them that I was open to feedback and if anything, I was doing could be improved to let me know. Megan asked if I could help keep her updated on what the team was doing in the moment and what their progress was. Megan stated that she gets a little tunneled vision with her own work and doesn’t know about all the ‘great work’ the rest of the team is doing. She felt like she was missing out on some of that comradery. With this feedback, we created a WIP channel on Teams where members show off their work, they had done that day.
Are you open to team builders? - All team members with open to this idea. They all stressed it would be hard to get everyone together at the same time, but they were willing to try.
Can I use your name on my website? - Not one member of the team had concerns with me using their names. They know I will be a professional and treat them fairly. I work with a great group of developers.
Are you having fun? - Overwhelmingly the group said yes. My concern is that this might be due to a new team and project. Optimism reigns supreme. This is something I want to keep checking in on, with a more rapid cadence. I am not trying to be pessimistic; I just don’t want to have the thought process of ‘well they were fine the other week; I don’t need to check on them again.’
Some good opening 1-on-1s to help break the ice and start building professional relationships with these developers. I plan on adding more of the results from 1-on-1s in future blog posts.
