The Path to Become Agile: Part I: http://gamasutra.com/blogs/SamyDib/20151109/258815/The_Path_to_Become_Agile_Part_I.php
We have officially completed our first week of implementing the agile methodology into our working environment. Again, if you read my last post I noted that sprints are usually set to last between 2 to 4 weeks long. For this project however, we will be running sprints throughout one week periods due to time constraints. We assigned tasks that we felt were achievable throughout a one week period and began to attack them vigorously. At the end of this week we went through a quick review to what went right and what went wrong.
What went right? Well using software like Axosoft allowed us to visually see what tasks were to focus on for this week. Keeping us on track helped to ensure we didn’t falter any and digress from what we should be working on. We were also able to see how long each task was estimated to take. As far as the estimations went, I feel we did a pretty good for the most part on guessing the durations. After we began to knock out the tasks and change their status to “completed” we could now visually see a list of all the hard work we were completing. It felt great to see.
What went wrong? Well this is the tough part to write about because nobody wants to sound like they are doing things wrong. We learn through our mistakes though and I think failure is a big part of success. At the end of the week it appears that we threw a bit too many larger features onto our list of things to do. For example, some larger features we estimated to take about 24 hours’ worth of work to complete but didn’t figure that having three of them in one week would be too much. During the sprint review we determined that having only one larger feature should ever be implemented into a sprint and see how that works better. As it stands now those larger features were the only thing we weren’t able to complete during the sprint.
During the first week sprint our major feature that we got completed was the equipment upgrading system. This feature allows for the player to upgrade their weapon, armor, or shield by visiting the merchant and paying a small fee. Our goal was to keep this as simple as possible so the player didn’t have to go crazy hunting down resources all day long. This feature was finished, tested, and found bug free within the first sprint which was a good sign. The second feature that we couldn’t finish and thus moved over to the second sprint was the bounty system. I won’t go into too much detail about this feature yet but it’ll work like a random bounty that appears throughout the day to have players excited to check out periodically.
We also completed ten additional dungeon levels for the game using our custom made level editor and continued our online presence campaign. It seems that our social media accounts aren’t gaining much speed at the moment but Super Bit Adventure is having a lot more success on SlideDB.com. With every post we add to it, we’ve been getting around 500 views and at the high point, reached #6 in popularity out of over 14,000 games. I would say that this is pretty good so we will continue posting consistently over all platforms and hope that something will catch fire soon. That’s it for now. Be sure to follow us and we will see you again next week!
Keith, C. (2010). Agile game development with Scrum. Upper Saddle River, NJ: Addison-