The Path to Become Agile: Part VII - Postmortem

Facebook: http://www.facebook.com/superbitadventure

Twitter: http://www.twitter.com/sbitadventure

Sign up for Beta: http://eepurl.com/bHRQH9

The Path to Become Agile: Part VI: http://gamasutra.com/blogs/SamyDib/20151215/261821/The_Path_to_Become_Agile_Part_VI.php

Postmortem

            The past 2 months have been very interesting when it comes to changing up how a team develops video games. In the past we have seen the major use of game design documents that can be anywhere from a few pages to a few hundred. This worked alright for the time but with the arrival of the agile methodology and scrum framework, game development has entered into a new world of software creation. Learning more about scrum this semester has been invaluable to increasing my own knowledge and experience with developing games.

            As a very small team, I may not have received the full on impact AAA companies receive with their development teams, but I was still able to learn and implement the core principles. With scrum, teams have to remain small, between 3 and 9 developers to effectively work. Every development team must be self-organizing and cross-functional, meaning everything from programming to testing must be able to be accomplished within that team. As a small team ourselves, we were ready to attack every aspect of game development using scrum.

            Sprints usually run between 2 to 4 weeks long at a normal sized company. In order for our small team to try and get the most out of this semester, we crammed our sprints into one week each. We ensured that enough features were added into a sprint of that size so that we could reasonably finish within the allotted time without any overflow. It was tough with some weeks passing through holidays and real life taking us out of the fold. Things like this can’t always be predicted but has to be taken into account when it comes to the sprint backlog. It took us a few weeks to get the hang of it but we finally found a good comfort zone when it comes to pulling features into each sprint backlog.

            Each sprint ends with a sprint review to go over what was accomplished in that sprint and to figure out when to do next. So at the end of the week we would look at what we completed and figure out what the next best action would be. Usually the sprint review is limited to no more than 4 hours for a month long sprint, so for a 1 week sprint we were able to do this in much less time. The small sprints allowed for a sprint review of about an hour where we were able to fit in a team meeting at the same time. This review allowed us to get a closer examination of what we did and where we’re going.

            Usually there will be a sprint retrospective as well to go over what went right or wrong in terms of people, relationships, process or tools. Since we are a very small team, we didn’t really have much to talk about when it came to these. There was some talk about making a few changes to our engine/map editor that we created which would help speed up development. Things like this are vital to the success of a development team and if we had more people, we would definitely have needed more time with the retrospective.

            This course gave me a lot of knowledge about scrum that I didn’t have prior. It gave me the insight and motivation I needed to explore this world even further. I took it upon myself to continue learning about being an effective scrum master and the framework that coincides. I studied guides and reviewed tests that would help me learn what is required from not only the scrum master, but everyone on the scrum team as well. After reach a point to where I felt confident enough in my knowledge, I took the Professional Scrum Master I exam for certification with Scrum.org. It was a close one but I was able to pass the exam on my first try. With this certification I will continue to build my knowledge base with experience and use the scrum framework for the continuing development of our games.

            At the end of the day we can definitely point out things that we wish we could change moving forward. The first thing would be to change the size of our team. A handful more developers would be priceless for our development efforts. This would allow us to tackle even more complex features that we cannot do on our own within the limited amount of time. Along with that, we’d love to be able to work with actual sprint time boxes. So instead of cramming features into the sprint backlog for one week at a time, we’d love to be able to throw more features from the product backlog into a 2 to 4 week sprint.

            Another thing that would have benefited the experience would have been total and complete dedication to the project. Half of the team was able to work on this project full time while the other half dealt with a day job that only allowed for a percentage of time to be dedicated towards the project. In the future, having a larger team who all maintained a 100% focus on the project would increase production by a great deal. With that said, we were still able to accomplish quite a lot throughout the past 7 weeks and feel that we are almost ready to begin beta testing for the players who have already signed up for it.

            At the end of this class, we have developed a pretty solid alpha build that we will be giving out for testing internally only. This is where I feel our stopping point effectively sits at the moment. Now, this doesn’t mean that we are far from done. On the contrary, we have begun talks to have a very short beta testing period prior to release. Originally, we had wanted a few weeks of beta testing but since we are moving pretty fast through development, a few days of testing will probably be all that is required. We look forward to receiving valuable input from the internal team who will be testing the alpha build and help us prepare to release the beta build to a larger audience. If you haven’t signed up for beta, feel free to do so at the top of this article. Thank you again and we will definitely be keeping you up to date on the development of Super Bit Adventure through our social media accounts.

References

Keith, C. (2010). Agile game development with Scrum. Upper Saddle River, NJ: Addison-

Wesley.