Insight #3 – Scrum

For the development of Behemoth we are using Scrum as our production framework, this decision was taken by the instructors in order for us to learn how to work with it and offer a time-structured design process.

Scrum is an Agile methodology, and as such, its main focus is flexible and iterative collaboration. Scrum specifically is aimed at smaller teams and uses short production cycles called “sprints”, which typically last between one week and one month, these start with a “sprint planning”, in which the team discusses and agrees on the goals to set for that time period choosing from the items on the production backlog. Every day during the sprint the team members are supposed to hold a “stand-up meeting” in which, one by one, they share with the rest of the team what they have done since the last meeting, what they are going to focus on until the next meeting and if there are any complications that may prevent the team from achieving the sprint goal. At the end of the sprint the team holds a “sprint review”, in which the team reflects on the sprint and reviews which items have been completed.

https3a2f2fcdn-evbuc-com2fimages2f306255782f461158519952f12foriginal

 

A diagram of the Scrum Framework

 

While that is the definition of working with Scrum, the actual implementation in the course has been slightly different for every team, this is how it has affected our team up to this point, and specifically the relation between design, art and code.

Our schedule consists of 9 one-week long sprints: 2 pre-production sprints and 7 production sprints. Of these, 1 pre-production sprint was lost due to scheduling issues between team members and overall poor communication, which led to design-related decisions to not be made in a timely manner, which in turn led to complications in later sprints and eventual re-does of whole mechanics and assets, namely the shooting mechanic.

Most of our sprints leading up to the Alpha state have been very intensive, producing most of our assets between sprints 2 and 3. We expect sprints 5 and 6 will also be very intensive and feature-full as we approach Beta.

In general the length of the sprints has felt unsatisfactory, as they begin on Monday afternoon (mostly after our lectures, which usually end around 15:00h) and end on Friday afternoon (again, after lectures, usually around 15:00h), this leaves just a couple of effective days to work with each sprint. We feel like two-week long sprints would have proven more productive to the scale of our project, specially for the production of more advanced graphical assets that sometimes suffered from lack of polish due to time constraints.

Daily stand-up meetings, while in theory a great tool for effective communication, fell short in the context of the program due to the lack of an “office environment”. As team members do not share a common schedule and most of them live outside the city, making the 15 minute long stand-up meeting a 45 minute to one and a half hour long effort most of the days, essentially crippling the team’s productivity. We therefore started doing our stand-ups through VoIP means such as Slack and later created a Discord server in which we could also share files.

The implementation of deadlines and milestones along the project, often mid-sprint, did not help with our production (sprint 3 of production was rendered unproductive because of the Alpha presentation) and created a sense of unease, as it felt more like we working under the Waterfall methodology with a Scrum flavoring.

The usage of Agile tools provided by the faculty (a template on a Google Spreadsheet) proved to be inefficient and more of a bother than an actual effective tool for our production. The bookkeeping of the sheet was very tedious compared to other tools such as Trello, an online Kanban board (another type of Agile tool), which, to be fair, we were allowed to use in addition to the spreadsheet, although that meant duplicating the organizational workload as the Google Spreadsheet is the only thing that will be graded.

Overall I can understand the usefulness of the Scrum methodology when applied correctly, although in our current usage it creates an unnecessary amount of pressure and additional workload for all members. I look forward to work with it in a less-restrictive manner, as I believe that is where the effectiveness of it will shine.

About Roberto Marcos Söderström

2017 Graphics