A Journey of Scrum at Joyseed (Part 1)
Joyseed is a young game studio, that only last year starting to assemble full, cross-functional team. As an aspiring studio with big dreams, we want to deliver our best quality video game within the most efficient timeframe. One of the methodologies we are trying to use to achieve super-productivity is the well-known Scrum. In these two-part post, I want to share our journey in utilizing Scrum in our daily development operations, and how it affects our productivity and happiness.
We Thought We Know about Scrum
Last year, we published our first game, Hollywhoot, in Google Play and App Store. Hollywhoot is an idle parody game about movie exploration, in which players will play as a director to make movies and train world-class talents. Since then, Hollywhoot got featured in Google Play store twice and App Store once.
What seems like a smooth launch was actually plagued by a lot of mistakes, as written by our CEO. Moreover, the project delivers really late on schedule. We estimated the project to be released in 6 months, but in reality, it takes us more than a year just to release the Early Access build! There was also a lot of waste in the development: delays, unnecessary features, and of course, the infamous crunches. During the development, we also realized that we don’t have clear targets and deadlines, that resulted in a “limbo” development state.
Hollywhoot project was actually using Scrum since the beginning of the development, but little did we know that we were only using the methodology, but not really understand the principles behind it. The following was some of what we thought we know about Scrum, and how they affected our development process.
1. Daily Standup is a progress report
We knew that we need to conduct a daily standup / daily scrum, and we conduct it every single day. We thought that standup is a means for the team to report their progress in the last day, for example :
- Yesterday I was working on coding jumping animation.
- Today I will work on coding enemy collision.
We cycle the report for every person, and that’s it. The standup is done. We thought the purpose of the Daily Standup was only to make the Team understand what the team members are doing. We knew that we also need to declare if there are any issues, but we don’t really act on it quite seriously.
The result? We felt the Standup was repetitive, tedious, and just becoming some sort of “morning ritual” that contributes nothing to the development. At that time, we didn’t know that Daily Standup is so important because of its ability to Inspect: identifying impediments and eliminates them as quickly as possible. What a waste of time!
2. We think a task is finished even though it isn’t really
Each sprint, we arranged a set of Story cards that need to be completed. We thought that writing the task title and a little bit of description is enough for us; I mean, we were only a small team. We want to code and design, not managing Stories! We try to complete the task as best as we could, and then we moved on.
However, when we try and test the feature, it produced some issues that were mostly caused by our poor definition of the task. For example, we implemented a pop-up menu that should be closed when the “X” button is clicked. But we forgot that in Android device, you must make the Android physical Back Button close the menu as well. It seems like a pretty small issue, but the difference can be huge for Android users, and we realized it too late. This is a simple mistake that can easily be avoided when you have clear acceptance criteria for the task.
3. There is no need to estimate the Story Points
When we developed our last project, we feel confident in our Way of Life: work hard, and everything will be done eventually. We knew that Scrum needs to have a timeboxed development called Sprints, so we did it. We planned the Backlog, we assign Stories to Team Members, and then we do it. We felt confident that we can do those Stories on this Sprints, and deliver the Sprint with great results. There is no need for doing an estimation.
What happened afterward is a Chaotic sprint: sometimes we finished too early (hooray!), but some other time, we could not afford to finish all the tasks. Our morale went up and down, and at that time we did not really know why. We work late and had crunches, but still, we didn’t finish all the Stories on time. We did not really understand why our productivity swings erratically.
Just because we don’t do estimation, the Sprints went into turmoil. We didn’t have any idea how fast we are, and whether we are on the right track towards delivery. We also did not really have a clear basis how big our sprint is and whether we can finish the current sprint on-time.
4. Adding feature is more important than fixing bugs
The following was a usual talk in our team :
Person A: Hey, I found a bug about this feature, when I click both buttons at the same time.
Person B: OK, let’s put it in the list and mark it as bug #189. It should be pretty easy, but should I fix it right now? I still have feature Y in my Backlog as well.
Person A: let’s revisit this bug later, just complete feature Y first. This bug is minor.
Person B: Noted.
A couple of Sprints later…
Person A: Hey, do you remember bug #189? There are a number of users reporting it, and it makes them angry.
Person B: OK, let’s see how I can fix it…
Later in the afternoon…
Person B: I have bad news. I can fix bug #189, but since there are feature Y and Z added on top of that, I have to rewrite them as well, otherwise, the game will not work.
Person A: But you said it was easy to fix that…
And that frequently happened during our development. We thought that adding a feature is more important than fixing bugs. The reality is that as more features are added, they will intertwine with the codebase, making the bugs harder to fix without harming related systems. Moreover, when we revisit bugs after weeks, we need time just to search and remember what we wrote. It took us precious and expensive time, compared to if we fix it as soon as it emerges.
5. We want to have a playable build every Sprint, but we don’t have time
In each two-week Sprint that we conducted, we have a seemingly great goal: to have a playable build by the end of Sprint length. We knew how important it is to have clear Increment that we can try and get feedback upon. But you know what? We just didn’t have enough time.
Nearing the end of Sprint, there was always some kind of these excuses:
I still have to add feature Y, because it’s in the backlog.
This UI is complete, but I am still not satisfied with the flow, let me just add one more button…
I need to build the executable, but it takes too long and I still have to code other things.
Last sprint day is tomorrow. I still have more time today to polish this. I will give the asset tomorrow morning, and the program will just need to put it and build it. I’m confident 100% it will not cause errors.
The reality was it frequently makes the project state unplayable when the Sprint ends. There were too many things added in the last minute, and we didn’t have time to test them all. This makes the project rarely have a playable build, resulting in less frequent feedback and updates. It caused a lot of trouble for us, especially when we really need the build for submission for awards, demos, etc. Don’t do this in your own projects!
Our Realization So Far
In the end, we managed to release Hollywhoot and got multiple featuring from the store. It was a great experience for us, to be able to finally publish the game we’ve worked hard so far. The results were not bad too, but it was far from our expectation. We barely managed to reach the finish line. We thought Scrum was easy to master, but it’s not. Our production process encountered many issues due to our misunderstanding in Scrum implementation.
We don’t want to stay like this. We want to do it better. In retrospect, what would we do differently in our next project? We have identified some issues and discuss them together. We are moving on to work for our next two projects: Wonderpants and Kingdom (Codename). In Part 2 of this post, I will share our improvement to our Scrum process, and how it makes us not only more productive, but happier as well. Stay tuned!
And by the way, if you are self-driven, creative, and looking for becoming a prominent figure in the Indonesian game industry, we’re hiring!
