Blog Post Postmortem

 I was the producer of Group 5. Throughout all five sprints, we had many things go right and go wrong for our group. However, I will say that towards the latter half of the semester, we were able to pull things together as a team and push out a good and functional prototype.

Through trial and error, I was able to find methods to communicate and allocate work with my groupmates. I was unfamiliar with being a producer, and though I have taken the general lead of group projects in the past, this was still a new experience for me as I feel that in my experience, the producer role required a lot more management of my team in order to meet the goals that we set out at the beginning of the first sprint.

For example, something that I learned to do was to break the cards down into much simpler wording and amounts of work. It motivated my partners to be able to do a bunch of little cards rather than a few large cards, and it was easier for them and myself as well to figure out what exactly I needed to do in order to complete the card since the wording was less vague.

Another thing that I learned to implement as a producer was personally categorizing many of the cards into groups in my mind so that when it came to assigning work to my group mates, I could lean them in a certain direction and make sure we did not have any blocked cards and could complete cards consecutively. One instance of this occurring was when Elizeo wanted to pick up a card oriented towards the level design, but I stopped him in favor of giving the card to Francisco because all of Francisco’s cards were already oriented to the overall design as the lead designer of the team. 

That leads into my last point that I learned from this experience, which was that as the producer, team lead, or whatever it may be called in the future, I need to put my foot down more often than not. I initially took a very laissez-faire approach to managing my group mates, focusing on my own work and only occasionally checking in with them. 

As you can see from the velocity on our burndown chart, though, that did not pan out well for us. Instead, after the second sprint, I began to set soft deadlines that predated our actual deadlines for the class, so that I could make sure we would be able to keep pace and implement the majority of the features that we wanted in the game. I also checked on my groupmates consistently outside of class, asking if they were in the process of working on the features so that I could get a better understanding of how far along we were in completing the sprint’s work. 

In terms of the actual development of our game, we were able to complete most of the development with only one major hitch that comes to mind. One of the main issues that we ran into was that it took several weeks for our programmer, Elizeo to get to fixing a bug with the wall climbing, a persistent issue that plagued both our mechanics playtest and systems playtest. To be honest, I am not entirely sure what I should have done to make sure this got fixed sooner, because I mentioned it to him essentially every time that we talked from the time it became known to us in the second sprint to the beginning of the fifth sprint. However, I will note that as soon as I dedicated a card to fixing the climb instead of simply reassigning the initial wall climb card, it got fixed much quicker. This tells me that in the future, if there is any work to be done whatsoever, it is much easier to motivate my peers by assigning some sort of point value to it.

The crafting and inventory that I implemented.

When it comes to things that went wrong during our development, there are two main points that stick out to me as major inhibitors of work completion for our group, and they are directly related. One of them was a persistent issue that I have mentioned in past blog posts, which is that towards the beginning, we often had issues with starting work in the latter half of the sprints, which essentially cut down our time to work in half. We were able to rectify this issue for the most part, but it still affected how much work we were able to complete in later sprints as we were stuck working on features that should have already been done. 

The other main issue was that we were unprepared for our paper playtest and mechanics playtest. This was directly caused by the lack of work completed in our sprints at the beginning. For our paper playtest, it simply felt like we did not have a solid vision behind what we wanted to create as a team, and I was not very efficient at managing the group at this point. This issue repeated itself in the mechanics playtest, and only once I reflected on the past sprints and decided to push the group harder were we able to change how much work we completed each sprint.

The items for our paper prototype were created at the last second.

If I had a chance to redo this class, I would definitely cut down on the number of classes that I take at the same time as this class. Although I am aware that hindsight is clear to me now, having the experience behind me, I took 6 classes this semester, with three of them having 3 hour work periods twice a week. This meant that I spent 30 hours on campus each week, and there were a countless number of hours that I spent outside of class on work other than work for 370. If I had taken even one less class, I would have had much more time and energy to contribute to the project. 

I would also be more strict a lot sooner on my group. My outlook was that they would create better work at faster rates if they did not personally feel that I was breathing down their necks. However, it has become apparent to me that the opposite was true.