Blog #3 Scrum
|
The best thing with working with agile scrum has been the daily standups. Getting a quick overview of what everyone is doing really increases the communication between the different minors. It’s been a really good way of making sure you’re not completely off track. Working with the sprints however, has been more of a struggle – at least in this project. The weekly sprints makes for a lot of time being time for meetings. Since we have had lectures on many of the weekdays, there’s not a massive amount of time after to work on the project. And when you factor in the 4 meetings of playtest, sprint review, retrospective and sprint planning, it feels like it takes a great toll on the amount of time you can spend working. Yet, I think it’s a good way to introduce us students to the method. In our group, these meetings tend to drag on for quite some time, which might be why I consider it to be a hassle. But these last couple of weeks has been great to repeat the process and greatly increase the efficiency of these meetings. We’ve also had troubles working agilely. When we first sat down to plan which artifacts were needed for the alpha, the list hasn’t changed much until now. The requirements from the course of what needed to be in the game was practically all our group had time doing. Therefore, making sure the game was “fun”, or matching our esthetic felt minor in comparison to making sure sure everyone would pass the course.
If you can’t find the game you’re making enjoyable, how would others? Although you’re not creating games for yourself, you need to see what others would find enjoyable in your game. And I think that is what has been missing for our group while using scrum. Working towards a minimum viable product (MVP) and testing it out to make sure it’s entertaining felt second in priority to getting a grade. Despite everything I wrote, I’m really inspired by what working with Agile Scrum can accomplish. I naively think that a fun development process has a higher likelihood to end up with a better game. And through working towards a MVP, I think the team has an easier time seeing the whole picture, not getting as caught up in details, and getting joy seeing the game evolve in a different way from waterfall production. Especially since we all major in game design, seeing and pointing out flaws or strong points of the game throughout every step in the development will undoubtedly lead to a better experience once it’s complete. TL;DR I think one week is a too short duration for a sprint, but it works well as practice, the goals of the course prevents some of the agile scrum strong points and working towards a MVP could be a very fun and good way to create games. Thanks for reading, sorry if it turned out quite ranty!  |
