Rapid Ideation Session: Sprint Retrospective

This will be the last post for the rapid ideation session and this will be a sprint retrospective, in which I assess what went well, what went wrong and where I can improve.

What went wrong?

As I mentioned in the sprint review, I did not manage to complete my game prototype. I experienced a lot of technical setbacks towards the end of the rapid ideation session. This could be because I relied on several different sources in order to come up with scripts for certain functions – all of whom would have had different approaches to scripting – and therefore it got muddled.

Most of the functionality I set out to implement in the game, namely collecting items for an inventory, adding a UI, creating moving elements of the environment and a door activated/deactivated by a laser. This was largely because I spent a lot of time troubleshooting the death/respawn function which meant that other stuff fell to the wayside and also because of lack of scripting knowledge.

What went well?

I enjoyed the early ideation process. I particularly enjoyed the use of cut up headlines to generate random sentences, which themselves could form the basis of new ideas. I managed to generate a lot of ideas that I can use and take forward in some form or another.

While I was hesitant at first, I also believe I took to level design fairly quickly, even if I was unable to build any of my creations fully. I enjoyed the process of using a story I had developed as a basis for developing mechanics for a game.

I was also able to play to my strengths at several occasions during this rapid ideation session, including using my illustration and animation skills to create a player character for my game. The drawing and animation may not have reflected the scope of my ability, as I was largely concentrating on getting the project realised in the short time frame, but it went very smoothly.

I also developed a more thorough understanding of Unity and while I am still not fully adept in this game engine, I have a lot more confidence. I also started to recognise the versatility and significance of various collider components within the game and how these can be used to do everything from building the environment through to triggering actions.

Although the rapid ideation session is largely about learning and developing new skills, I found the parts of the project that went well were those that played to my strengths. I have learnt that when I do develop projects, that they should be done in a way that does largely play to my strengths, but allows room to challenge and remedy weaknesses.

What could be improved?

As I mentioned above and as I have mentioned across numerous previous posts, I need to continue developing technical skill. Now that I have some more experience of what it takes to make a game and I have a better understanding of how much time I should budget for, depending on how big my team is or whether or not I even have a team, I will need to ensure that I focus on projects that have specific and measurable goals, which can be accomplished within the time I am allocated.

I identified a lot of areas of game development where I do not have much experience. While I have attempted to rely on tutorials to guide me, this has had mixed results. I also need to ensure that any sources I used to learn skills, I approach with a critical eye and I always question why processes are done in a certain way. I also need to be careful when drawing upon multiple sources to learn new skills as many approaches are different and may contradict one another.

I realise that I would benefit from collaborating with other people on the course – primarily those who have different skills to me, so that I can learn from them and they can learn from me. I need to ensure that I reach out when I am struggling.

I also need to change my mindset so that I am less focused on the end result and that I focus more on what I actually got during the course of a project. I have started to do this during the rapid ideation session, when I reassessed how realistic my original goal was on day 7 and then refined it.

I also need to consider how my critical reflection has developed over the course of this project. As the number of posts I have written has increased since I last addressed the five domains of reflection, I have done a further check to see if this has change and whether I am considering more domains of reflection. Here are the results

Reflective domainPosts
Procedural domain37
Cognitive domain19
Dispositional domain9
Affective domain6
Interpersonal domain3

I have increased in all five of these areas, but when I compare these results to the results from one week ago, I can see that there has been some change.

Procedural is still by far the most dominant domain of reflection, followed closely by cognitive. However, interpersonal, affective and dispositional have all seen as small increase as I have started to consider these more in my critical reflection and these are areas I can continue to work on.

Using Agile / Scrum

Throughout this rapid ideation session, I have endeavoured to use the Scrum framework and assess how effective it was for managing this project and also facilitating critical reflection and reflective practice.

I acknowledged at the beginning of this process that I would need to make modifications to the Scrum framework, given that I was working solo and the project only lasted two weeks, the average length of a single sprint. As I proceeded with this rapid ideation session, I found that I maintained several practices that were core to the Scrum framework throughout, whereas others I gradually abandoned as I did not find them conducive to this particular project.

Throughout the entirety of the rapid ideation session, I maintained the practice of having daily ‘Stand-up meetings’, through the form of posting daily ‘Stand-up’ posts in which I would state what I had done the previous day, what I intend to do on the given day and what is blocking my progress.

These posts were particularly important in ensuring I kept a clear mindset during this project. They allowed me to track my progress from day-to-day, while also having the opportunity to document any obstacles, tangible or otherwise, so that I could assess to what extend it could block my progress. Although I did not finish the creative artefact that I came up with during the project, these ‘Stand-up’ posts prevented me from becoming stressed and helped me to see the bigger picture and how I was meeting my goal.

The Scrum framework stipulates that there is a product backlog and a sprint backlog – however, as this project consisted of one sprint, these backlogs essentially merged into one. To facilitate the tracking of assets and tasks within the backlog, I set up a Kanban board on Trello. I intially maintained this and used it to track progress with assets and tasks that came about during the development of the project.

However, as time went on, I found the Kanban board less useful and it just started to feel more like one more thing that I needed to do, rather than being an integral part of the running of this sprint. I found it more beneficial to document my progress and record any newly discovered requirements in my blog and track these through my daily posting. Over time I largely ditched the Trello board.

This is not to say that maintaining a Kanban board or Trello board is not useful in and of itself. If I had been working on a group project, the Trello board would have played a more active role in assigning roles, as well as tracking and visualising the progress of all team members. Furthermore, I was essentially acting as my own Scrum Master and Product Owner, but if I was working in a group, there would have been a specifically appointed Scrum Master who would be responsible for maintaining the progress of all team memebr using the Trello board. As I was working on a solo basis, it seemed more redundant because my blog was fulfilling this role.

In attempting to apply the Scrum framework to my practice during this session, I have found that there are aspects of it that did but there are also

While the Scrum framework favours smaller teams over larger teams, I have learnt that it also favours smaller teams over no team at all. Although I moved away from several aspects of Scrum which I found did not apply to this project, as it was a solo project, there were nevertheless aspects that I found very beneficial. I found positing daily posts in which I assessed my progress against any obstacles, as well as developing plans based on these extremely beneficial within reflecive practice. While I largely moved away from having a product and sprint backlog, I did find the philosophy of Agile and Scrum very workable as I was able to set a goal and then generate assets and tasks in the process of reaching that goal, which expanded my learning.

The extent to which I apply the Scrum framework again, or indeed any Agile framework, will largely depend on whether or not I work in a team. If I work in a team, I will definitely utilise the Scrum framework, or I will at lease propose that we utilise it. However, if i work solo, I will not implement the entire framework, but I will use many of the practices and approaches I found beneficial.

This week is reading week, which means we have not been assigned any more work for this week. I will likely use this week to take a step back so I can reflect and possibly work on some unfinished art projects.

We will have a second rapid ideation session, which will commence next Wednesday (11th). This session will have a new theme and I will have an opportunity to set myself a project which involves creating another artefact. Much like this session, I will be required to set myself a clear and concise goal that I will then document my progress on throughout. However, I will now have the benefit of hindsight and I will have a better understanding of the skills that I will require to meet the needs and requirements of both my own set goals and the overall purpose of doing the rapid dieation session.

I have already started to think about ideas for what I could set to acheive during this next rapid ideation session. I am particularly keen on using it to design and create a game character in Blender in order to revisit my 3D skills, but what I ultimately decide upon will be depenednt in part on the theme that is revealed and also whether I choose to work solo or in a team.

2 Replies to “Rapid Ideation Session: Sprint Retrospective

Leave a Reply

Your email address will not be published. Required fields are marked *