Week 12
Last updated
Last updated
Abstract Our learning objectives for the week were:
I made sure that our submission was organised and sent a reminder to the team that we've all agreed to send our videos to Dan by Tuesday (17th) by our usual working session time of 19:00 BST.
I also indicated that I was going to download the Confluence Space at 12:00 Thursday (19th) for submission. So if the team needed to update any of the planning documentation please do it by then. Otherwise it is closed (the space takes a while to download).
I created a coversheet for submission and created a login for the external examier too.
Login details are as follows: User name - falmouth@akanoodles.com Password - !!gdd730
I'll close the sprint at 12:00 Thursday (19th) and export the Confluence space. Hopefully, the examiner will log in and see our progress, velocity and that it replicates industry-standard workflow.
This module has been quite challenging as it required a lot of horizontal management and leading through influence.
Many of the aspects of the project were simply out of my control. For example, the project's main build was managed by Dan and Lucas and the art style by Luke. This type of structure was not uncommon but more challenging when in a learning environment.
Working in management positions, I usually recruit, hire and validate people before I assemble the team. However, that was/is not possible with the pool of individuals available. We're not the finished article.
For instance, I'm new to game development and couldn't really contribute to the 'development' aspect of the game. So concentrated on things that I could excel in, such as team management, project management, ways of working, pitching and storytelling.
Of course, there were aspects in which the team came together and co-created, where I could stretch myself and contribute, such as the game mechanics and the gaming loop. But we decided to work on the bits we wanted to once we assigned roles.
Assigning roles works better for remote teams. People can focus and get on with work without thinking too much about duplicating work, leaning into our interests knowing what's expected when we come back together. This worked well with the personalities within the group. Wilde (2009) described in his book Teamology: The Construction and Organization of Effective Teams asserting that different types of tasks require different personalities in a team. In detail, people with different personalities diversely approach tasks, resulting in better and faster solutions.
Creating the right environment Having learnt from previous bad working experiences, I prioritised putting together a way of working. That way, people knew where they stood and now to contact each other.
'Golden hours' was extremely valuable as team members knew when they could expect replies back on chat, when we could arrange meetings and times we should commit to making ourselves available.
This worked well in the storming and forming parts, but after week 6 (the mock presentation). Velocity dropped off the cliff. I wanted to gain higher marks. I had it out with the team that I felt I was chasing people up too much and not following what we agreed in the team charter.
After that chat with the team, people stepped things up, and I promoted co-creation sessions. Making a point that people need to work independently and over-communicating, using JIRA properly and updating work without being prompted. Again horizontal management is quite difficult but had stressed that we all want the project to be a success.
Most of the team members were engaged with the communication channels and coordination platforms despite the team's life-changing events, like starting a new job, getting married, having a new baby, moving country and general illness.
Common Enemy What bought us together was our common annoyances with the course structure. The content was released too slowly, and by the time it was relevant, we already had done the work.
We only got to a good place because I had the experience of setting up and working with disparate multi-disciplined teams before and used practices that I implement daily.
Research Our game development process has involved several qualitative and quantitative research rounds informing the final artefact's conception, experimentation, design, and development.
A few areas I found difficulty finding was successful game development pitch decks. I initially started to use my process of bringing products to fruition and pitching to VCs. Until week six, The GameDev business handbook (Futter, 2017) was recommended to me, which gave me an idea of what needed to be in the investment plan. In terms of functions, timelines and what needed to go into a 'game pitch'.
The key thread was to make sure the game loop is clearly defined so that investors understood how viable the game would be and how the game would be different and stand out.
Next Steps The module itself was fine, but I would like to focus more on UX and develop my practice. All the horizontal management, team management, project management, ways of working, pitching and storytelling process used I had recycled from personal experience. So I'd like to explore something else so I could stretch my abilities. The next module seems to be Research paper focused. The use of literature and cited material is a weakness for me, so this will stretch my abilities.
References
Futter, M. (2017). The GameDev business handbook : how to build the business you’ll build games with. London, England: Bithell Games.
J. Wilde, D. (2009). Teamology: The Construction and Organization of Effective Teams. London: Springer London.
