A Journey of Scrum at Joyseed (Part 2)
In Part 1 of this post, I have shared about how our misunderstanding of Scrum process hampers our development process. Currently, we are moving our focus on developing new projects. We realized that there are so many mistakes we made, and now we are eager to do better.
After a lot of discussions with the team, finding out the issues and key mistakes, we are now refining our Scrum process. We begin with defining our target in that we want to achieve :
- We need to have a clear focus and alignment in our tasks
- We want to identify waste and eliminate them as early as possible
- We want to know our team capability and how far we can stretch our limits
- Also, since we are a small game studio, we want to use the most cost-efficient tools and methodologies while we can.
Based on those criteria, we defined a set of initiatives within the Scrum that we are implementing. These are the improvements that we made in our Scrum process.
1. Definition of Done
One of the most important takeaways from our previous development is that we don’t have clear alignment when completing User Stories. We tried to remedy this issue by implementing the Definition of Done: a consistent, clear acceptance criterion. The Definition of Done (DoD) ensures everyone on the Team knows exactly what is expected of everything the Team delivers. The following is a DoD example for one of our User Stories :
With a clear DoD, everyone in the Team has a clearer focus on what to complete for the specific User Stories. The team will also have a clear vision of whether their task contributes directly to the Sprint Goal because it is clearly defined in the DoD. Now, the User Stories generated by Product Owner (and with Team’s help) must also be accompanied by a clear Definition of Done.
2. Planning Poker
Besides clear vision, we also want to know our team capability. There are some questions that we want to answer, such as :
- How many User Stories that Team can actually complete in a Sprint?
- How far can the Team stretch their limits towards Continuous Improvement?
- Is the Team still on schedule or lagging behind?
To help to answer those, we are conducting a Planning Poker session in the Sprint Planning meeting. The aim of Planning Poker is to provide fun and fast estimation of Story Points, while at the same time invoking a discussion about uncertainties in the planned task. We play Poker for every task that is planned in the Backlog. You can read more about Planning Poker in this link.
In Joyseed, we use Prime Number cards for the estimation, since it allows us to judge faster with a clear comparison. We also draw and print our own cards, because we need it fast and just clear enough to do the job. (kudos to our Programmer, Vinda for designing our cards!)
Planning Poker helps us in estimating our Team capacity, and have a cross-functional discussion for the Stories. We frequently get better insight about the Task details when we perform the Poker.
3. Sprint Burndown Chart
One of the roaring requests in our retrospective is the ability to “inspect and adapt”. We want to know whether we are still on schedule, or are lagging behind and need to speed up. To do that, we utilize a Sprint Burndown chart that measures work that is Done each day. For each Daily Standup, we count how many points we completed on the previous day and plot them in a simple chart.
By looking at this chart every day, the Team can measure whether they need to stop “overpolishing” the work, or they still have time to provide more quality. The burndown chart also helps us to predict whether we can complete all of the tasks on schedule, or re-arrange the backlog so that deliverables can still be prioritized.
4. Formally appointing the Scrum Master Role
Previously, we don’t really think Scrum Master is important (and we don’t know how to do it). However, we think this role is quite important, and we begin to implement this role in our projects. We hope that by having a Scrum Master role, it will help our Scrum process more streamlined by coaching Scrum process and removing impediments.
5. Joyfulness Index (a.k.a Happiness Index)
Agile development advocates not only for efficient and fast development lifecycle but also to have a healthy and happy process. Therefore, in our Retrospective meeting, we measure everyone’s satisfaction in the last Sprint by conducting a Joyfulness Index (we’re Joyseed after all!). Each of the members will give a Joyfulness rating from 1 to 5 (using our self-made card!), and share why they give that number.
For example, one developer will give a 3 Joyfulness Index, because his/her work in this Sprint is frequently blocked by sudden and difficult dependencies. Another one gives 5 because he/she managed to complete all the assigned tasks and even still have time to add more polishing. We also measured the “average happiness” of this Sprint and compared them to the previous Sprints to see what we can improve.
6. Going Back to “Pen and Paper”
Lastly, we knew that there are a lot of improvements that we were making at the same time. Our current tool (Quire) does not really match our expectation and some free software like Trello does not do the job as well. We explored a subscription-based service like JIRA or Favro that we think suits our needs, but we feel that it is too expensive for our current scale. Also, we don’t want to be limited by tools, we want to really grasp the principles before we use the tools.
Consequently, we have decided to go back to a little bit “primitive tools” of Sticky Notes and a makeshift whiteboard. We put all the task, kanban-style, in the Sticky Notes, and write our velocity estimation in each of them. When a task is finished, the written point is entered into a Google Spreadsheet to mark that it is consumed and counted towards the burndown chart. So far, it works for us!
Some Tangible Results
We started to implement the renewed process in our upcoming games, Wonderpants and Kingdomtopia. We have seen some interesting results that are quite enlightening for us.
1. Productivity
We have seen our increase in productivity for each sprint we went through. Since implementing the process a couple of months ago, we could see that our productivity increase each Sprint. Right now, we managed to increase our Sprint productivity by nearly twice since we started.
Furthermore, we now own the knowledge of our Velocity in our belt. We have a better understanding of our work, and we can always aim higher without fearing that our estimation will be overstretched.
This is still far, however, from what Jeff Sutherland (the inventor of Scrum) envisioned, to “do twice the work in half the time”. We still have more homework to do.
2. We have playable build with clear Increments
One of the key takeaways in our Scrum improvements is to always aim for a playable build by the end of Sprint. Moreover, the playable build always contains Increments that we have planned in the beginning.
This is possible now because of our clearer focus mainly contributed by the Definitions of Done. Our team members ensured that all the Stories marked as Done equals to the feature being included in the build, and tested through QA. This makes our build have minimal bugs and in a nearly-playable state.
Additionally, around the same time when we implement our Scrum improvement, we were also adding improvements in our technical pipeline: Automated Daily Builds. These automated process of building, uploading, and publishing (to internal) drastically reduce our time for identifying and fixing bugs in the project. This results in a more fluid QA pipeline, and always near-playable builds at the end of the Sprint process.
(I will talk more about Automating Unity Builds for Small Studios in the upcoming post. Stay tuned!)
3. We are happier
Since we implement the Joyfulness index, we are now happier! Our average Score started as low as 3, but steadily climbing. We even had a 4.83 Joyfulness Score in one of our recent Sprint… A near-perfect one!
Those were some good news, but actually, the more important takeaways are answering this question:
“How can we make a happier sprint?”
One definite answer comes out from our discussion, that is the best Sprint comes when we managed to complete all the assigned tasks (plus some additional polish) and make them playable. We learned that this is the most important part of our Scrum process, to be able to plan well and execute those plan completely.
Joyseed’s Strive for Excellence
We faced a lot of issues and challenges while developing our previous project. Hopefully, with all the discussion and our improvement in the Scrum process, we can refine our development cycle to achieve the super-productivity envisioned by the Scrum evangelists.
Nevertheless, we are still learning. These improvements may sound trivial, or perhaps has been implemented in other studios. Some of the processes we use now might also not be ideal for other companies, but we learned that the best improvements are the ones discussed and implemented together with the team who runs the process.
My deepest gratitude for all Joyseed’s Ohana for helping me materializing the Scrum process in this article. We are still looking for the best talents to strive together in achieving the “big dream”. Let’s plant a joy! Join us!
Originally published at http://fadhilnoer.wordpress.com on June 10, 2019.
