Week 12 – Unit 710 Video Submission

Development Practice

Transcription:

Over the past 12 weeks, I have learnt many useful things, several of which I have now implemented in my own practice, including Hooks, user stories, epics, estimation using the bucket method, agile practices from a practical standpoint, creativity techniques, and ICEDIP.

Agile practice is quite easy to implement with the work I already do, so learning about them from a more practical standpoint has been a highlight from the past 12 weeks.

The Agile practices I have learned during this course are a great foundation for building a business.
In particular, my estimation and envisioning have greatly improved with techniques such as epics, user stories, and the bucket estimation technique.

Building a games company that suits me is one of the goals I have in life, and there are several problems in the games industry that I would like to address with this business.
In “What went wrong, a survey of problems in games development” the writer suggests that some post mortems describe problems in team buildings that lead to communication and relationship difficulties.(Petrillo, Pimenta, Trindade and Dietrich, 2009)
I believe this is directly related to the hiring practices.
I believe that hiring should be more personal instead of dictated by computers and algorithms.

An algorithm will find you a person who tells you that can do something, however, you are not hiring a machine, you are hiring a person, and if the person does not work well with the team, they’re not going to be a good hire.

The paper “teamwork quality and project success in software development: a survey of agile development teams” reach a conclusion that quality of teamwork is a major factor in improving team performance and eventually the product (Lindsjørn et al., 2016), further proving that hiring the right people for the team should play a greater role for a successful business than ticking boxes with an algorithm.

One thing I have started doing is using a variation of the Gibbs reflective system when reflecting on my own work. I find it much easier reflect with the added structure and have greatly benefited from this system.
I am still not brilliant at reflection, it’s something I will continue to look at in the future, but I have improved, especially after my 6-week interim retrospective.

I have reviewed my own products to analyze their hooks. This has allowed me to better understand why people play my games and allowed me to target future updates so that they will be more intrusting to potential users.

It just so happened that as I was studying creativity, I was also pitching at the time. So I was able to utilize techniques such as my favorites, mind maps, and opposite thinking, alongside ICEDIP to generate and improve the pitches.
We have also started to adopt the use of Epics and user stories. This is a way for the team to better communicate on what the goals of the project are.
We can certainly improve upon our use of these techniques but have already implemented user stories as they provide a lot of information about why we do something. Epics are longer to make and are more in-depth, We have not used one yet, but we do intend to in the near future as we design new dungeons and features.

Additionally, My estimating has been based off of ideal days. During the past 12 weeks, I have learnt what an Ideal day actually is. and it turns out that what I was doing was unsustainable with me working late into the evenings
most days. Now I know more about Agile estimating, I can estimate with the Fibonacci sequence and the bucket method. Combined with calculating my work velocity, I will be able to estimate much more reasonably how many tasks I can do.
An advantage to this is that given my estimates will be more accurate, we should be able to do fit in, not necessarily more, but a more appropriate amount of work, and provide much more accurate estimations for clients.

During the two Rapid Ideations, I had two vastly different mindsets.
In Rapid Ideation 1, I set out to create a new type of game that I had never created before, a card game, to see if code techniques I had designed would practically work.
This project was intended to challenge myself as a developer and to provide me with a portfolio project for the future.
I found success in this project as I was able to create a small card game against a simple AI, but I did not have time for detailed art assets, something I still intend to create now, now that there’s more time.

For Rapid Ideation 2, I spent a lot of time trying to understand how to work alongside people with different skillsets to my own.
I want to gain an understanding of as many skillsets as possible in order to have meaningful conversations with people about their own work.
I decided to create an app, I wanted to build this one from the perspective of a User experience expert given I was working alongside UX experts, yet did not know what it was they were really doing.
By completing this project, I have gained a much better understanding about what a UX expert does and why we may want one on a game dev team. Working in their domain has pushed me to think in different ways I would not have considered previously.

According to “game scrum: an approach to agile game development”: after a survey of game post mortems with teams from projects of varying sizes, it was discovered that the vast majority of problems accounted were related to management problems.
Part of these problems were associated with multi-disciplinary teams where there was bad communication between the teams creating division between artists and developers (Godoy and F. Barbosa, 2010).
part of the reason I chose to make an App instead of a second game was because I could potentially bridge that gap by understanding multiple different disciplines. For example, I am a programmer by trade however I am also a trained artist.

Scaling agile stresses that quickly reacting to feedback and continuously improving a product is incredibly important but also that lack of communication amongst the team is an issue that can work against the product (Ebert and Paasivaara, 2017).
By studying the work of my peers, I have solved this communication issue for myself, something I feel I have benefited from even if not in my own practices.
Rapid ideation 1 was for myself, but Rapid ideation 2 will help me work alongside others in the future.

We also covered personal branding.
I don’t think it’s worth personally branding myself so much as using my products to promote myself.
I still have a lot to learn about personal branding but I do know that high product quality will provide a lot of resources to promote myself with, and spending time ensuring that quality will go a long way.

I had some ideas about IP and how I can use IP to promote myself. This fits in well with personal branding. I believe that repeated Logos, relatable characters that become familiar, and worlds created that are consistent among repeated games could potentially be a great way for players to remember me and look at future products.
This process would take a long time but is inspired by the mascot characters of the 80s and 90s such as sonic, Mario, Pikachu, and so on who had great success.
I have not had a chance yet to research this in-depth yet but I hope to be researching more into this theory in the coming weeks when I have more free time.

Bibliography

Ebert, C. and Paasivaara, M., 2017. Scaling Agile. IEEE Software, 34(6), pp.98-103.

Godoy, A. and F. Barbosa, E., 2010. Game-Scrum: An Approach to Agile Game Development. Computing Track – Short Papers, [online] Available at: <http://sbgames.org/papers/sbgames10/computing/short/Computing_short19.pdf> [Accessed 24 June 2021].

Lindsjørn, Y., Sjøberg, D., Dingsøyr, T., Bergersen, G. and Dybå, T., 2016. Teamwork quality and project success in software development: A survey of agile development teams. Journal of Systems and Software, 122, pp.274-286.

Petrillo, F., Pimenta, M., Trindade, F. and Dietrich, C., 2009. What went wrong? A survey of problems in game development. Computers in Entertainment, 7(1), pp.1-22.

Leave a Reply

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