Exteriors Devlog Week 2

During week 2 I began to have some concerns about how the structure of development was shaping up- the work each team was doing, especially the design team, felt unorganised.

   The Design Team had a Miro board that was shared with the whole development Team; but this board I feel like was taking up far too much time with people making it look nice and adding new notes / features to each mechanic. We needed a Kanban Board to help us properly organise and delegate tasks within an Agile framework. This would have streamlined the overall workflow of the Team and allowed anyone to see what was in progress / completed at any time to get a better idea of how development is shaping up.

   Our goal for the first day of week 2 was to create a project backlog, but I feel like at least the one the design team made was far too vague and took us far too long.

   I was worried that this project might go in a similar way to a Game Jam I had done the previous Summer where I was the Design Lead in a group of over 20 developers on a game called ‘The Rot’. The Rot was the first project I worked on in a large team over several weeks and the final result was disappointing to say the least.

This was in part due to a majority of the Development Team including myself’s lack of knowledge about Agile development frameworks. I wanted to do all I could to prevent Exteriors from going this way. I wanted to implement more Agile techniques such as a Trello Kanban board immediately, sooner rather than later.

   To remedy these concerns, I got the design team to join a group call to discuss our development structure. I suggested that instead of the additive approach currently being taken, that we strip down our ideas into a very basic MVP (Minimum Viable Product) and more diligently adhere to a development cycle more in line with Agile Frameworks (Scrum, specifically) and take an iterative approach from here. I suggested that everyone should have a Sprint Meeting on Mondays and work on a new iteration build of the game each Monday-Friday and over the Friday / Saturday the Design team should get testers to play the game, hold a sprint review meeting with the whole team and discuss what to add in the next iteration, which would start the cycle anew on Monday. 

   This cycle resembles the Scrum agile framework’s sprints far more than the somewhat aimless additive processes that were being undertaken, which I feared would just lead to a lack of cohesive shared vision of the project and falling far behind schedule.

   I am hoping this will make Week 3 far more productive than the previous one. Speaking to a couple of members of the Art and Audio teams, they said the MVP document the Design Team made during the group call gives them a useful and more tangible target within a deadline. Hopefully following this structure will help us have a relatively organised and successful development.