Time to reflect on the production 2 project as a whole from my perspective. I’m doing this after the team post mortem and we went over the team rights, wrongs, and what we have learned. I’m going to write about what I think I did right, wrong, and what I’ve learned, in both a team and individual sense.
What Went Right
The biggest thing that I think went right for me was the opportunity I had to do stuff that I haven’t yet. Systems and Tools is something that I haven’t done in depth yet and this project gave me that opportunity. I was able to use Unity touch stuff to create an input system that was used across the project and I was able to create a level building tool for the designers. This really solidified for me that I like tools and systems the most when it comes to game programming. Individually I think I had good communication with my team members when we as a team communicated.
I think I did a good job of realizing that I needed to change how I was handling my workflow and improving upon that. My old work flow was do everything Sunday/Monday which is counter intuitive towards an iterative environment. This was due to me having so much on my plate this semester in terms of what I was doing and ultimately had to drop a commitment.
As a team I think we did a good job of supporting each other and making sure that we were building healthy personal-work habits. We did a good job at staying positive throughout the project despite the fact that we were struggling so much during the process. I think we as a team did a good job of bouncing back once we realized we had messed up and had little time left to do a lot of stuff. Another thing that I think went well is how people were on boarded onto the project; the on-boarding was relatively smooth and pain free.
What Went Wrong
The biggest thing that I think went wrong personally is that I found myself working towards the end of sprints for a portion of the project. This leads to not being able to iterate on stuff during that week and having to wait a long time before fixing things or working more on things. This a combination of a team error and a personal one; I believe I didn’t have a good understanding of what a team lead actually was and flopped when it came to being a programmer lead. This also leads into personally helping misguide the team on what needed to be focused on for the beginning-middle of the development process. I also found that I was often taking tasks assigned to me and not doing them with others and instead doing them with myself. Hand in hand I found that I wasn’t giving enough feedback to team members that they deserved and we all needed to better the project.
There was a lot that went wrong with the team and how we managed the development process. There was a lot of siloing in the beginning of the project with lead to things either not being done right or things not being done in a fashion that would later lead to iteration on content. There was a lack of communication and feedback being given between team members, which in an iterative project needs to be done as much as possible.
Alongside this lack of feedback came an implementation of waterfall instead of using the typical scrum process which I detailed in another post. There was a lack of accountability for those that were late or just straight missing from meetings. This includes daily scrum which we also found that we were doing poorly. We had daily scrum scheduled only 4 times a week (that’s daily?) and were doing it over voice. This lead to a lot of people missing scrum (not a fault of theirs) and not giving updates. We also had a big issue with relying on a group of people completing a task before anyone else could really get work done. These are called linchpins and they lead to having reduced amount of work and having people sit on the sideline for too long.
People on the sideline was another issue. Since we had so many management issues and were struggling with the larger team size we found that we had a couple people on the sideline not doing a ton of work on the project. There’s probably so much more and as a team we did a team postmortem on what went wrong that is much more in detail and wholistic in content.
What Did I Learn
The biggest thing I learned was to not take on too much. I found once I took on too much work, I began slacking in a couple of classes. I realized this towards the middle of the semester before spring break and decided that I was going to drop a commitment. After that decision, I found that I could much better handle my workload, specifically when it came to production. I’ve also learned how to better handle a larger team, this is really important for moving into capstone. Dividing work, communicating, giving feedback, making sure nothing gets missed, and making sure that all team members are happy. I’ve also learned to abide by scrum and to stay away from waterfall.
I’ve found out to make sure that there are little linchpins in a project and that if there end up being them to work around them. One thing we started to do as a team was, well first have a unified discipline sprint planning, and two make it so that we listed out what was reliant on other things. This way we could assign tasks in a way that meant not too many people if any were relying on someone else to complete their tasks to do theirs. I’ve gained experience in giving constructive feedback vs giving feedback that is not. I’ve learned A LOT this semester from both having a bigger team and having another semester of production.
I guess with this stuff it really comes down to experience. There’s a lot of stuff that I’ve been taught the hard way even after being told that it was going to be a problem. There’s a lot of stuff that I still haven’t learned that I will learn, hopefully not that hard way, and work through.
All in all I’ve really enjoyed this semester and enjoy working on games, even though it wasn’t the preferred or the best scenario. I’ve gained a lot of knowledge and look forward to learning more and working on more games.