This week we review the fourth stage in Tuckman’s group development model, performing.
This week’s spark activity involves carrying out a SWOT analysis. Normally, a SWOT analysis is used to identify strengths, weaknesses, opportunities and threats in relation to a business opportunity, or as part of a planning exercise.
In this instance, the technique is applied as a means of reviewing the team’s performance so far. The aim is to harness the team’s intuition to identify areas of teamwork that might benefit from data collection.
Measuring Team Performance
The first lecture was on metrics, specifically, how a team can measure their overall performance. Alcwyn Parker states that agile development promotes working software as the primary way of measuring progress. He advises not to measure everything and to avoid metrics that promote ego. He then categorizes his points into what he labels as 'vanity' (what we want to hear) and 'sanity' (what's happening without bias) metrics.
Types of metrics include value, performance, volume, work not done and velocity. Scrum metrics include deliverables and team effectiveness. And finally, other metrics include team wellbeing, procrastination, communication, satisfaction, creativity and downtime.
Thoughts & Reflection
I found this lecture to be very eye-opening. I have been fortunate enough to be a part of many scrum teams in the past. However, I have often overlooked metrics - finding them useful in a post-mortem report as opposed to the here and now. The only data I remember gathering was during my FMP, using HacknPlan to track my weekly velocity. Furthermore, although I did not list it, I believe that tracking momentum (how, in what manner, did I reach my goal?) could be beneficial to my team as it would hopefully indicate a level of consistency with the project. Although, tracking momentum could only be identified after the project had concluded.
Advanced Topics in Agile Planning by Mike Cohn
Figure 1: Advanced Topics in Agile Planning (2012)
The second lecture was about advanced topics in agile planning by Mike Cohn, CEO of Mountain Goat Software (figure 1). This lecture was very inspiring. Cohn offered great advice by expanding on topics raised by Alcwyn Parker in the initial lecture, such as using metrics to identify a team's performance.
Notes on Cohn's lecture:
It's better to be accurate than precise
Velocity is significant over the long-term
Team members must balance risks
Throw away outlining observations
Scrum masters should only spend one-minute gathering data for every weekly meeting
Have a new team plan a sprint
Team size affects velocity
Slides & Voice Overs
Figure 2: Development Plan (Cottage Corps)
This week was very busy in terms of developing the project and the pitch presentation. It started with me selecting some slides and elaborating on the respective topics. I chose to discuss the development plan (figure 2) and monetisation models. The group decided this was the fairest way of doing things so everyone could contribute to the presentation. I designed my slides before writing my transcript and recording my voice-over, which would later be paired to the slide.
I based my development timeline on past experiences and the development life cycle of video games.
Figure 3: Monetisation Models (Cottage Corps)
After discussing monetisation models with our supervisor, he suggested it was better to be honest if we were unsure which model to choose and to avoid singling out just one model. His advice was to list potential strategies and explain how we would go about tackling each one (figure 3).
Figure 4: Publishing (Cottage Corps)
Finally, I created the publishing slide (figure 4) because I felt the information naturally led off from the monetisation models. This way, our presentation covered a lot of ground. With the pitch done, it was time to head to the editing room!
Video Editing (DaVinci Resolve 17)
Figure 5: Editing the Presentation
The whole editing process took about three days. I made sure I was available to my team through Discard, where I constantly updated them on the progress of the video. The video consisted of the slide deck, voiceovers and a brief showing of the prototype (overlaid with music). Once I was happy with the overall quality of the video, I sent my team a draft for them to offer feedback on (figure 5). With their feedback, I quickly made a few adjustments and sent the second draft to the team. From there, we greenlit the video, and Adam sent it to our supervisor.
Getting into Trello (19/07/22)
Figure 6: Trello (19/07/22)
This screengrab (figure 2) was uploaded on the 19th of July after week seven had finished. After we submitted our pitch presentation to the panel, it was time to turn our attention toward the game! This week I set time aside to complete the grid system and implement enemy spawning. All the while, my teammates worked on UI design, shop mechanics and enemy base units.
One of our group goals is to post more frequent updates on our Trello board to have better communication on the status/overview of the project. I have now made it my mission to update any tasks, so that my peers know exactly what I'm doing and when I'm doing it! I believe I will be scrum master for our next meeting (week 8), so I plan to raise a discussion on how everyone is doing tackling this goal.
Spawning Enemies
Figure 7: Enemy Spawning on Random Tiles
After editing the video, I continued with our Unity project, this time implementing enemy spawning. I set up a system whereby every round would see the grid automatically cleared, and a new set of enemies would spawn (figure 7). It would instantiate the max count of enemies (which at the time was three) by choosing a tile at random, checking if the tile was empty and then instantiating the enemy at the position of the random tile - a for loop was used to achieve this method.
Figure 8: Enemy Units Increment By One Every Five Rounds
Every fifth round, an additional enemy would spawn (figure 8). I mimicked a round change by implementing a button (in the top-right hand corner), and when triggered, a new round would start. Moreover, I restricted enemies to the right side of the board by creating a list of all the tiles and halving said list. I then capped my random tile number within the bounds of the halved list (if that makes sense). However, as of right now, the player is not yet restricted to the left side of the board. Perhaps if I were to use layers and tags, I could achieve appropriate player placement.
Next week I plan to work on player placement, iron out any bugs and start to bring in assets made by the team. Once we have received feedback from the panel about our pitch, I presume we will come together and discuss updating our slides.
Comments