So, for this blogpost I will talk a bit about Scrum and Agile and how that effects game development, and especially how it affects our group’s development.
I will start right of the bat that we don’t really work in a Scrum or Agile environment, at least not in the way our course literature and we in Design/Design class have been taught earlier. This is more of an adaptation and version of Scrum that isn’t really the most optimal way. But it is a step in the right direction and something we can learn from going forward.
The problem lies in that a lot of steps are overlooked in how the course is set up. And that they are not taught out to all the different disciplines, and maybe especially the managers. Because they are supposed to plan the whole development process, but if they don’t know all the things that’s available for them to use, they won’t use it. And when other parts are mandatory to get a grade. They take priority over the things our course literature teaches us.
For example, ‘User Stories’ are a big part of what we as designer have been learning about, but they are not even mentioned to the rest of the Game Design majors. Since the rest of the team don’t know how to use the user stories they will just think it is extra work for them to read through them and work around them rather then just filling out a backlog.
About Agile:
- Individuals and interactions > process and tools
- Working software > comprehensive documentation
- Customer collaboration > contract negotiation
- Responding to change > following a plan
These are the four manifesto points that Agile builds on, which is something great to follow in my opinion and something I like about Agile as a development method. For example, having a lot of documentation before you start your project paints you in a corner if something doesn’t work out as you intended or thought. And having a fluid work environment with the development makes you think constantly on how to make things better rather then doing what you thought at the beginning. This ties in really well with the point about “responding to change”.
About Scrum:
I like the idea with having scrum and agile tied together, they work really well hand-in-hand with each other. Because having meetings regularly (maybe we have them a bit to much with once a day) and demanding them to be physical rather then online is a bit much in my opinion, but I can adapt.
But having them and just talking about the game together even when you are not physical in the same space helps you out a ton with the game development process, with making decisions on what direction you will take the game in.
As an end note on Scrum and Agile. I am nowhere near understanding and knowing everything about these systems, but it is something I really like and appreciate to learn as we move forward in our education. It is something I think we all will have use for later in life, no matter where we end up. But I think you have to take parts you like and parts you don’t like and make it your own, and especially tailor it for your groups work.
Game Design 
If I understood everything correct, your group is not working with scrum. You explain why you do not work with scrum but you don’t really explain how you are working. It would be very interesting to know how you guys are working instead. Do you still use the product backlog? Do you have sprint meetings? I would like to know more about how you are handling the project management. How has working like this worked for your group?
I fully understand when you talk about what other majors have been taught and not taught. Like you said about the user stories, my group had never heard of user stories. This was a very informational post and very interesting to see that you are doing something different. I would really like to know more about how you are doing it but other than that, great post! //Jesper Bergman
LikeLike