After a two week Easter break, it feels good to be back and working on University Coursework. It has been a busy two weeks which I talk about in my blog post "Being Published by Dread X". This week we are discussing Agile Practice. The first topic up for discussion on the forum is about, what did we do to ensure we completed our tasks on time. To quote the specific course, it says:
While we might not all have rich experiences with Agile methodologies or complex project management techniques, we have all found ourselves in a situation where we needed to get something done.
What did you do to ensure you had completed your tasks in time?
Be it a university assignment or a work-related task you found challenging to complete, what tactics and approaches did you employ to complete them successfully?
Given what you’ve learned about Agile and time management in this course thus far, do you think you could adapt your tactics to Agile methodologies?
Flex.falmouth.ac.uk. 2021. Log in to canvas. [online] Available at: <https://flex.falmouth.ac.uk/courses/911/discussion_topics/19904?module_item_id=49211> [Accessed 13 April 2021].
I guess for me, time management is quite important. In my personal life I am fairly organised and like to keep things tidy. Prior to this course in my previous life, I was a regional manager for many years. Being responsible for 75 people, scheduling 3 months in advance, completing reviews and meeting deadlines and attending meetings. It's a skill very few master. I feel like however I have done a good enough job over the years to say I am somewhat ok with meeting even the toughest of deadlines.
My most recent situation where I have had to get things done quickly and efficiently was with Dread Central. A publisher of small curated indie horror games. I was recently picked up by them to create a new horror FPS game to be featured in their new collection. I had 20 days to create something unique based loosely on a theme. It's been a hectic 20 days but it is finally done. I prioritised my workload. Used organisation app's such as Lucid and Trello to stay on task. Converted my sleeping pattern so that I was on PST so I could ensure I attended meetings on time. My biggest approach to having this completed was to ensure I got all my tasks completed for the day and then started the next days work so I had a head start ensuring that I was always one step ahead.
I think given my current working knowledge that I have learned around Agile Development that this could be implemented and adapted to fit around this. The time frame set by the publisher was limited due to the other developers that they chose to be in the collection so we all had to find a compromise. In a different setting though I definitely feel that adapting this would be easier. Belinda Waldock "In the video below, Belinda discusses the origins and importance of Agile development. While you watch this video, consider how the topics being discussed might change how you manage your project development in future modules."
My takeaway from this video by Belinda is how adaptable the agile framework can be. Taking the 20 percent of agile that will develop the 80 percent of the work, taking away the standard methods of agile and making it more relatable to myself. Although I am involved in a couple of teams who make games, it is good to see this is adaptable for single creators. The reality check is when working on my own, I tend to have a standardised practice. Now, I am thinking about using testing my prototype first be it internally with my team when working with them or not, and even look at selecting a few external people to test.
I like the method of planning future work, then planning on what I am going to do. This would be followed by doing it and then releasing a small prototype build for people to feedback on. I feel using this method going forwards helps me create my own way of being agile, but also creating a more robust version of my idea prior to release.
Product Planning:
According to the dictionary the term envisioning means to "picture mentally, especially some future event or events: to envision a bright future". In regards to indie game development there are many times where we may come up with concepts or certain mechanics that we want to prototype before we start spending a certain amount of time on them. As with all variations of rapid ideation, envisioning should play some part in this process, big or small. There have countless times where I have personally worked on something as a form of rapid ideation and then decided to work on it further and see it through to completion. I spoke about my work on the game ALLON3 where the collaborative efforts between myself and two others ended up being extended past the 48 hour mark because we knew we had something special. We also had a really good mechanic using 3D audio to help guide the player in different directions. Envisioning tends to be classed as a post project process but I also feel it can be utilised during development as mentioned above. In the book, Essential Scrum by Kenneth S Rubin, there is a forward that I really liked that was penned by Mike Cohn. The quote reads as follows:
I had lunch today at a Burger King. A sign on the wall proclaimed the restaurant the
“Home of the Whopper” and then proceeded to tell me there were over a million different ways to order a Whopper. If various combinations of extra or no pickles, tomatoes, lettuce, cheese, and so on can lead to over a million ways to make a hamburger, there must be billions of possible ways to implement Scrum. And while there is no single right way, there are better and worse ways to implement Scrum.
Rubin, K., 2013. Essential Scrum. 10th ed. Upper Saddle River, NJ: Addison-Wesley, p.31.
This quote alone speaks volumes as the example referenced here is not factually true, but for the methods of scrum, he is using this example to exaggerate just how many possibilities there would actually be compared to, if this were true. It's a comical and satirical way of looking at things but in the end it really makes you think about things like this in a bigger way.
In regards to my own artefacts of rapid ideation, I would say I usually think about bigger picture objectives during the development cycle of anything. I usually come up with ways that mechanics will work on paper first, outlining blueprints in my notepad and seeing what would work in my head. sometimes, whilst working on a small rapid ideation project I will come up with something better entirely. This is because I like to consider myself always in the prototype phase in some degree.
The image below shows the steps in the software engineering life cycle. For myself, my usual train of thought is as follows.
1) Concept/Idea
2) Prototype 1
3) Emulate 4) Development Plan 5) Prototype 2
6) Design Confirmation
7) Prototype 3 8) Development plan update 9) Review 10) Implementation
Not withstanding the usual bits that need to go into this for it to work such as code and testing as these are all part of the plan regardless. Testing and coding I feel will always be a part of anyone's development so it seems unimportant for me to list it as a step. If you look at the list I have made above, you can see there are multiple prototype stages which cover the design changes linked to the development plan. The design confirmation is then locked in and won't be changed. There will be a review at the end of the final build so to speak, as again, there is always time for review and feedback during testing and coding. For me, this seems like a good way to implement envisioning into my own personal projects and rapid ideation.
https://jaxenter.com/common-sense-software-engineering-part-iv-life-cycles-and-agile-121889.html
Week 10 Challenge Activity: The artefact that I chose is from the First Rapid Ideation Session where I created a small western town setting with the emphasis being around a fortune teller who reads your fortune. In the game, your character must try to stop a series of events that happen within the town. The fortune teller gives you specific hints in the game and you must try to stop them from happening. Depending on your actions, the game changes and has different endings. A simple plot and purpose but, also contains a decent amount of mechanics that interests a few players.
I never had a name for the game in the end, but the people who played really enjoyed it.
User Stories:
1) As a gamer, I want to discover new and exciting methods that I haven't really seen done before. Something that will grab my attention aesthetically and mechanically.
2) I prefer smaller indie games available from places like itchio or gamejolt and constantly browse the indie section on steam. This is because given my lifestyle and how busy I can be, I don't have time to invest hours into a larger game.
3) As I also have a job that I work at 5 days a week. It's important that I also get to play a game now and then to rest and relax.
Persona Example
Name: Ant Horton.
Role: Working middle class male
Brief description: A full time delivery driver who travels up and down the country. Usually takes, 1 or 2 days off a week.
Demographic information: Age: 27-30 & Location: Cannock
User Goals: To have an easy life where he gets to do the things he likes.
Challenges: Always working and saving money. Puts personal goals above anything else.
Estimation:
According to Woodward et al, “a core principle of Scrum is that the team members responsible for delivering the work should estimate it”. (2010) Estimating the time a task will take can be challenging and easy to miscalculate, fortunately there are a variety of Agile techniques that can be applied and practised to help with this.
To be able to accurately estimate, a Product Backlog full of epics from the envisioning process is needed to answer the following questions:
· How many features will be completed?
· When will they be done?
· How much will it cost?
The epics need to be broken down into smaller manageable stories
Once done, the estimation process can begin. Estimation is all about effort and requires the people that will complete the work to take part. Rubin’s three principles propose that:
· Estimates are not commitments – clarify estimates are just that and subject to change
· Focus on accuracy, not precision (accurate measurements = correct values, precise measurements = consistent values)
· Use relative vs absolute sizes
Reflecting back on this section of the module, I feel that I now have a wider understanding of what my target audience is like by breaking down the different demographics. Also looking at the software engineering lifecycle image, it helped me understand more about my own processes and how I can better them. I outlined above my current processes, and whilst this might be different for games creation vs other artefacts within this type of media, it does allow a simple visual way of allowing users to create their own template for process and review.
Comments