Blog #3: The importance of sprint retrospectives
|
Hello and welcome to my third blog entry! For the development of our Shoot ‘em Up game we were instructed to apply the Scrum framework. Scrum is an Agile framework that is extensively applied in the software development industry (and thus applicable to game development). By placing high value on the Agile philosophy and preserving Scrum principles, game development teams can become very effective and ensure a valuable product is being developed. An emphasis on iterative development, incremental delivery, continuous testing, and the involvement of empowered and collaborative people are some of the core ideas behind this way of working and thinking. The Scrum principles are Empiricism (the “inspect and adapt” cycle), Emergence (as we develop we learn about what is fun in the game), Timeboxing (iterative development and incremental delivery), Prioritization (developing high priority items first), and Self-organization (teams are empowered to be self-organizing and self-managing). In today’s post, I will focus on the sprint retrospective and how it has impacted the development of our game, “Umibōzu”. The sprint retrospective is a brief meeting held after the sprint review by the team and is a reflection upon the completed sprint. It’s purpose is to “inspect and adapt” the value of our emerging game (Empiricism and Emergence principles) as well as refine the way we are working in order to maximize progress. As the Scrum Master of the team, it is my job to facilitate the meeting. The team answers the questions:
 For example, we recognized that using Unity Collaborate is limiting and poses threats to the functionality of our game. The free version of Unity Collaborate only allows a maximum of three people to work on the same project. Also, when merging files, there are significant risks of conflicting issues especially if members worked on the same scene, script, or prefab. In our retrospective meeting, we discussed these issues and concluded that we should stop using Unity Collaborate and find a more reliable, better way of working together in Unity. This leads me to the next question in the retrospective, “What should we start doing?”. We decided we should set up the Version Control System GitHub for the team. Simply put, GitHub keeps track and stores progress or versions of projects. This is done by “pushing” files (in our case Unity files) from your computer to a server and “pulling” files from the server to your computer. This way, everybody who is connected to the same Git project can work collaboratively. It is a lot more reliable than Unity Collaborate and is not limiting yet has a steep learning curve for non-programmers (Tip: using a user-interface like GitKraken will make the learning process a lot less painful). Now to the last question, “What is working well that we should continue to do?”. Active communication on Slack, daily-stand up meeting attendance, working as a group at university, fika-Wednesday, giving and receiving constructive criticism are all things we have identified that are working well and we should continue to do. Identifying and discussing these positive actions to our development is crucial to becoming a better team. Conducting sprint retrospectives is an underrated practice yet an excellent way to improve any aspect of how a team functions. By having a formal conversation and recording the result of the meeting, a great deal of value can be gained. I would argue that it has been the most beneficial practice that has affected our game development. Thank you for reading and until next week! ∼ thedudeleo  |