How a Scrum Works
This is to make the un-initiated understand the basics of what Scrum is, and how it can be used as a framework. Feel free to skip if you understand Scrum.
The basic principles of Scrum is to work in an iterative environment consisting of small teams that self-organize tasks that need to be performed in order to ship a product. Some roles in the team are:
Product Owner– The person or entity the team is working for, and determines the overall priority of features and their order of implementation. The product owner is the one who sets out the requirements for the project. For our purposes, the Product Owner role is a combination of the faculty responsible for Game Design 2, and the Project Manager.
Scrum Master – Facilitates communication between the Product Owner and the team, and ensures that critical meetings can occur. Irons out any hiccups in the production pipeline, keep the team up to date and improve their productivity in whatever way possible. Is the keeper of the “Scrum Bible” and is there to answer any questions and make sure Scrum is utilized to it’s fullest potential.
What is essential for Scrum?
Product Backlog – detailed list of features, assets and artifacts that are planned for the product, with varying levels of priority.
Sprints – 1 or 2 week periods that start on Monday and end on Friday, where work is done on small contained parts of the product, planned in the Sprint Planning meeting and reviewed on the Sprint Review meeting, on Monday and Friday respectively.
Sprint Planning – Plan out and allocate time for tasks that need to be done for the current sprint. Each member takes on tasks that they feel they can perform, and estimates the amount of time they expect to be able to put into that task. A Quality Assurance reviewer is assigned to each task, to aid in keeping the task do-er accountable.
Sprint Review – The estimated time for each task is reviewed and evaluated. How well the feature is implemented and notes for what worked and didn’t work are noted down.
Daily Stand Up – Quick 10-15 minute meetings that occurs every workday where the members can share what they worked on since last stand up meeting, and what they will work on next.
Minimum Viable Product– The idea that most steps, assets and parts of the project will contribute to a minimum viable product for shipping. We are not building a car over 12 months by painstakingly crafting every mechanical metal part and putting them together at the end. We are putting a stick between two wheels and adding bits and bobs until it’s safe enough to stand on, and build from there. Iteration is the name of the game.
What benefits have we experienced?
What I deem the most valuable aspect of Scrum is that it empowers the individuals in a team to find work they would like to do. Most work is “grabbed” by the individual who wants it, and in most likelihood the person most capable to complete the task. The process is more satisfying than to be assigned a task, even though that might happen to tasks that no members want to tackle every now and then. Overall it leads to a more gratifying workload where you work on things that you feel a slight excitement for, most of the time.
It rewards strong willed and motivated people with a good sense of progression and development. If using good documentation it’s easy to see how much work has been put into the project, and get a sense of satisfaction. In our project specifically I have been very happy to be able to test out my assets through every step of the way and detect problems early in the process. From this I have had enough time to change the work pipeline to prevent a lot of work from being wasted. These changes include:
- Size of the Player Character compared to other objects
- Size of Tiles
- Types of Tiles that need to be created
- Size of the Big Enemy
- Distance of camera from play-area
- Visual design of certain objects (Testers pointed out the Shield Pickup looks like a mine)
These changes are especially important to me as an Artist, since re-scaling assets is tricky and doesn’t work for Pixel-art most of the time, and re-drawing high detailed art leads to a lot of wasted time. Through iterative development most of these issues were discovered organically, using low-effort art assets. But development is more than just art, and we also worked on these issues:
- Constant change of player movement mechanics
- Focus (or non-focus) on lighting for game-play mechanics
- Mechanics of aiming and shooting
Through iterative development where we could constantly test these aspects of the game, problems would be discovered and eventually resolved throughout the process. This might have saved us from many hours of wasted work, or work being put into a faulty product.
So what’s the Verdict?
One of the biggest strength and weakness of the framework is that it puts a lot of trust on the individuals to find and do work. Sometimes people do not feel confident enough in their own ability to tackle a problem, and tasks that are within their skills fall to other members who might be better suited to handle other problems. A well functioning team can compensate and make sure that everyone does tasks that are suitable for them, but this can sometimes be tricky.
Scrum works best in a team of self-motivating, closely knit and interdependent teammates that hold each other accountable and are excited about the project. Individual work is highly valued and easy to see, and feeds back into the motivational aspect of wanting to do work for the group. Quick feedback loops and visible progression, both in the moment and over time strengthen the feeling of cooperation towards a common goal. It is a valuable tool, but it can be abused intentionally and accidentally.
-Benjamin Thomas Harbakk
EDIT: Here is the Comment I made for this week’s assignment