While working on the game “Aetherial,” my group and I are applying the development framework known as Scrum. Before I began this course, I didn’t even know what Scrum was, let alone how to apply it. Fortunately, it is fairly easy to grasp.
The bread and butter of Scrum is the “Product Backlog.” A product backlog is where everything that needs to be included in the game to create a ‘minimal viable product’ is placed and organized based on things such as the discipline responsible for creating it, whether or not something needs to be finished now or when the game is in a more complete state, and so on. These tend to be referred to as ‘artifacts.’ Group members choose one or more of these artifacts during the ‘sprint planning’ at the beginning of the week and attempt to “finish their plate” before Friday. Each day before Friday, group members also need to attend a quick “stand-up meeting” that varies from group to group (for us, it is around noon) where each member talks about their current progress with work to make sure everybody is on the same page and if there might be any snags in their plans. On Friday, the sprint ends. We all see what has and has not been finished and then figure out where to go from there.
For me personally, I do like the overall process and working within the Scrum framework. There is enough structure that it does not feel like I am one of six headless chickens, but not so much that it becomes stifling. For example, there was an assignment in my Graphics minor regarding animation. With scrum, I had the flexibility to ‘double-dip’ and focus on the animation portions of the product (and my assignment). With a more inflexible development framework, such as waterfall (where products are built on ‘milestones’ instead of ‘iterations’), there would have been a nonzero chance the animations I worked on would have been in a future milestone and the end result might have been a grumpy project manager or a tired graphics artist trying to make ends meet.
Another instance where the flexibility of scrum helped was when it became clear during development that an enemy from the concept document we chose would have been a very high risk to pull off. The enemy in question was melee focused and would attempt to grab the ship and slow it down while damaging it. With scrum, my group was able to scrap the enemy in the document and replace it with a turret, something far more simpler in scope from both a coding and art perspective.
Also, from a personal standpoint, Scrum is useful. I do have a small (okay…moderate) procrastination problem. Give me a month to do something and I probably won’t even begin until the second week. A week however is a lot less time for excuses. It’s probably for the best that the sprint plannings go for only a week instead of two for me. That said, the execution of scrum in our group has had it fair share of growing pains, especially on my part:
For the first week, we overestimated what we were capable of accomplishing and didn’t get anything ‘done’ by Friday. The next week, we underestimated and ran into a new set of issues. Then again, this is the first time all of us so this kind of stumbling is to be expected.
On the bright side, I do like using Scrum and it has also surprised me. The stand-up meetings have helped a lot for me despite my initial misgivings about them. At first, especially when the only reason to leave my apartment was to go to the stand-up meeting, I found them slightly strange and due to the existence of the Internet, possibly pointless. However, after a few weeks, it has grown on me. Going back to my procrastination, the meetings help mitigate it as the idea of not having something to show/say for it does not sit well with me. It’s peer pressure, but it’s a good kind.
That’s all for now. Good bye, and take care.
Christopher's Conundrums and Contraptions 