Scrum: Meetings, overwhelming

Context

The concept document for Umibozu seduced a lot of group, most likely because of its art style, and possibly because of the minimum perceived difficulty in making a game out of it. And while yes, none of the explicitly mentioned mechanics were hard to implement  in a basic form, their sum did not create a remotely satisfying game.

We have some liberty to adapt the concept to our vision, unfortunately, no coherent vision emerged at the onset of development and we decided on figuring it out later. We focused our effort on implementing the core graphical elements and game play mechanics we knew we could not remove without straying too far away from the original document.

Now, in this later stage of development, we have a clearer vision for the game and I think one of two things happens. The daily stand up meetings prevented us from forming a clear vision early or the daily meeting enabled to find the game through exploration. I am not yet sure which one happened, but let me elaborate on this.

Meetings as creative fuel

One of the possible scenario is that, by letting us have brief discussion about the state of the game and its elements every day, we came up with regular insights as we were exposed to the game taking form (as in seeing some of its core elements being setup in a design void). We would regularly come with new idea of what we should add or remove to reach a game that approaches the aesthetic intent of the concept document and generally bounce off idea during these meetings. It is in some way the intent behind Agile management methods.

Meetings as ostrich strategy

The other possibility is that did not settle on a vision for this game early because we always had the option to bring any problem that may emerge in the next meeting, so nothing really needed to be set in stone. The daily meetings, with their recap of what  had been done yesterday settled us in false sense of progress. In addition, scrums focus on bite size artifact prevented us to get an immediate grasp on what the game was supposed to feel like on a larger scale. In the end we sliced up what should have been a solid design brainstorm design session into dozens of smaller ones, while we hoped the game’s design would magically emerge as time went on.

 

Conclusion

As you might tell, I am convinced the second scenario is most likely what happened to us, as agreeing on a vision is the main boulder our group dragged around since our very first project. Let it be a cautionary tale, do not let the room for adaptability that Scrum gives you tempt you to just feel your way into development.

 

 

About Nicolas Basil Gerard

2017 Programming