Blog #3 SCRUM

In this blog I will cover my personal approach to Scrum throughout the duration of my project, as well as negative aspects of using it without proper expertise, experience and environment.

To begin with, I’d like to say that I am very happy that Scrum is becoming so popular within the game development industry, and also that it’s a part of the curriculum here, at Uppsala University Campus Gotland. Scrum can be very beneficial if understood and used properly, as it provides guidelines to creating an efficient, agile environment which is so crucial in creative fields such as game design.

Unfortunately, I have to admit that I have had very mixed feelings about using Scrum in this particular project. Even though Scrum is a great framework, which helps avoiding many problematic situations, it can be very harmful when used improperly, as me and my classmates have been previously warned by Gabriel Chivi during his great guest lecture from the Projects and Leadership course. He has told us that he witnessed on multiple occasions how incorrect interpretation/use of Scrum has harmed not only projects, but entire organisations which claimed to be agile, while forcing the framework on the development team is if it was a methodology.

Scrum has been built for full-time projects with 5 work days per week, with daily meetings happening at the same time every day (preferably in the morning) and with the assumption that it will be used by people who are knowledgeable enough with this framework to be able to put it to good use. In contrast, our groups have been thought near to nothing about Scrum, are expected to work only about 20 hours per week (only half of what Scrum intends) and have varying schedules in our respective minors, which not only prevents us from using the full potential of the Scrum framework, but also restrains us from being truly agile, which is the core value that Scrum promotes. It’s crucial to understand that Scrum is NOT a methodology, and was never intended to be used religiously, instead has been created to create a foundation which is supposed to be altered and tweaked to fit either the organisation using it, or the project it’s being applied to.

To conclude, I am a big advocate of the Scrum framework, however I believe it should be used by those who are very knowledgeable in it, and when it is to beneficial for the project outcome, rather then used “just because”.

Au revoir.

Blog #2 The Alpha presentation

In this blog post I’m going to cover my process of creating the alpha presentation of our current project – Umibōzu.

Before I opened PowerPoint to begin drafting the presentation, I decided to first go through the Scrum document, which I have mentioned in my previous blog entry. I did this to refresh my memory of what the group has done so far, and what is still ahead of us in the upcoming weeks.

After restoring my memory of the last few weeks, I sat down with our Lead Designer, August, to discuss what I have found to be the most tricky part of the entire presentation – identifying aspects of the project that the group has found both most satisfying and dissatisfying. The reason why I have found this to be so intricate is because there is very little the group is dissatisfied with at the moment, while the list of things we found gratifying could go on and on until the end of time, as being able to finally create a game together has been a great experience for all of us. Together, me and August created a little list of what we found the most viable for the criteria. I have later adjusted the list after a larger portion of the PowerPoint has been finished, as it was easier to see the bigger picture and determine what stood out and what was suitable.

My next step was to compare the current direction of the project with the original vision of the team which responsible for creating the Design document of Umibōzu, as it would later help me identify each element which we have either scrapped or modified so that it would fit our needs and capability. In addition, I have later categorized those tweaks and changes into 3 categories: The setting, Mechanics and The aesthetic goal.

The last slide of the presentation (excluding the Alpha footage, which didn’t require any preparation from my side) consisted of a list of all features which we are hoping to include in the next release (Beta), as well a list of existing mechanics/assets which we are not quite satisfied with just yet. Those elements of the game will require revamp of certain assets, and rigorous play testing which we believe is going to enhance the overall player experience both visually and gameplay-wise.

Throughout the entire time I have spent to prepare the presentation, I have been regularly asking for feedback from the entire group to ensure that the presentation would reflect the collective standpoint of Team Unicorn. I sincerely hope I have achieved this goal.

Over and out.

Blog #1 – Scrum documentation

During my previous sprint, I have put a lot of focus and energy into writing, rearranging and organizing my group’s Scrum document to make sure that every member knew exactly was has to be done to finish the project, as well as to reduce time spent individually on browsing the backlog by each person involved in the project.

Firstly, I have gathered the group in order to collectively create a catalog of most artifacts which had to be included in the final product. Secondly, I have individually updated the backlog with help of a casual interpretation of the MoSCoW method (without the “won’t” part), by identifying and categorizing each possible artifact or asset that was missing from the original version of the document, which was earlier written together with the rest of the group. Furthermore, I have later discussed all newly added artifacts with the group, in order to make sure everything has it’s purpose in the project.

Additionally, I chose to make certain changes to the document itself, as I have felt that the template provided by the course wasn’t sufficient enough to meet my needs. These changes weren’t too major, however I believe they could help preventing miscommunication among the team members throughout project’s duration. These changes were mostly visual, nonetheless in my opinion it’s of high importance for this kind of documentation to be very clear and easy to maneuver through, especially since certain responsibilities within both the sound and art department are most likely to be shared between multiple people due to small size of the team. Improving readability of the Scrum document will allow the group to focus more on work rather then wasting time by scrolling through pages of poorly organized documentation. These changes include the following: assigning unique colors to each type of responsibility (Code, Art, Design, Sound, Management and Group) with clear and coordinated structure, to allow multiple people to contribute to various roles (for example, if the Lead artist was in need of help in finishing a certain asset, or when certain tasks would require contribution/presence of all group members simultaneously), making a clearly visible distinction between each sprint, and creating a template for further weeks to allow members to focus on planning rather then technicalities of the google sheet.

To conclude, my goals during this sprint were to improve clarity of documentation and improve workflow of each team member. Following weeks will show if my goals have or haven’t been met.