Ah, Gile!

One sprint has passed since our team implemented scrum methodology in our project. What can I learn, and what have I learned?

So, as part of our PPL course, we implemented Scrum methodology for our project. This is my first time (and probably for the others) working with this methodology after being introduced to it last semester with the RPL course. But before I start writing my experience about it, let’s have a quick introduction to Agile and Scrum methodology.

What is Agile?

Taken from Agile Alliance, Agile software development is an umbrella term for a set of frameworks and practices based on the values of The Manifesto for Agile Software Development and the 12 Agile principles. So terms like sprints, extreme programming (XP), scrum, all of that fall under Agile’s banner. Agile is a process that’s been building since the 1990s, where more and more development methods appeared, which peaked in 2001 when 17 developers met and published the Agile Manifesto.

Agile focuses on iterative, incremental delivery, as products are delivered to stakeholders or clients with a short cycle time (ranging from a week to a month). While development time per iteration is short, Agile also focuses on quality as it uses practices such as TDD, code refactoring, and continuous integration.

The agile cycle.

What is Scrum?

Scrum is a framework that utilizes the Agile mindset to deliver and develop products. Scrums are usually designed for a small team, who work on their goals within a set amount of time (called sprints), usually around 2 weeks. Scrum has a short meeting called stand-ups, which can happen daily or bi-weekly, depending on the team to keep track of progress. At the end of the sprint, a sprint review will be held where stakeholders can get a preview of the current iteration of the product and give feedback, and sprint retrospective where the team reflects on the past sprint to improve themselves on the next one.

Implementing Scrum in our project

Following the Scrum guide for PPL, we will have 5 sprints to complete our product, with each sprint taking 2 weeks. Here is the basic outline for a single sprint:

• Planning

In the planning phase, we decide which user stories we want to take for this sprint and try to give them a score based on how tough they are. We use the Fibonacci scoring system, so the score goes from 1 (lowest), 2, 3, and 5 (highest).

From there, we break down these user stories into small problems called tasks. These tasks are then put into the issue section in Gitlab, where the dev team can pick out which task they want to do. Each user stories usually have 2 members taking charge, although all members can cross over if needed.

• Sprint

The coding phase. We develop the project using TDD and other methodologies that can help us develop while maintaining code quality.

Stand-ups are done bi-weekly, where our Scrum Master asks us about our project while also sharing the problems we are currently facing, whether related to the project. During these stand-ups, tasks that have been done are moved to the ‘Done’ section.

During this sprint phase, we also have Individual Review. We write articles about topics related to our project (like what I'm doing now) and give examples of us keeping our code quality by giving links to our commits in Gitlab.

• Review

At the end of the sprint, we have a sprint review, where we (the dev team), the lecturer, the TA team, and most importantly, our client meet up together in a conference call for us to present the current product and receiving feedback from the client.

After that comes the sprint retrospective, where we reflect on the past sprint with our Scrum Master and take some breather before planning the next sprint.

It’s much harder than this image explains, I swear.

In actuality…

While what I’ve written above is essentially the best case of a sprint, not everything comes to plan. Here are some notable things that happened during our first sprint:

• THE GITLAB IS DOWN

One of the more unexpected things to happen is that our Gitlab went down due to circumstances. Not only our Gitlab but the e-learning website also went down as well. This halted our progress for some days as we wait for the server to come back up. If there’s a saving grace for this accident, the IR deadline was pushed back as well, allowing us to get some more commits in to be presented.

• Mix-ups and mess-ups

As this is the first time most of us use the Issue page in Gitlab, sometimes someone forgot to assign a task for themselves and started to work on a feature without telling anybody. This makes task divisions a bit hectic, as we have to confirm which unassigned tasks are already taken. This also makes our work a bit harder to keep track of individually.

• First day on the job

This is our first time using Scrum methodology, and this puts a bit of pressure on our progress, as sometimes we hesitate on what to do as we don't want to break the rules set in the guide. For example, another member and I had a 15-minute discussion on how to write a commit message for a revert. I feel like we tend to overcomplicate things as we really didn't want to make any mistakes.

• Schedule hell

PPL isn’t the only course we take this semester, as there are 3 to 4 other courses with their own problems that we have to solve. This makes progress considerably slower at times, and I’ve felt it right now in this current sprint, as I haven’t committed a single line of code due to other obligations in other courses.

• Good talk, lads

During our stand-ups and retrospective, the atmosphere is generally more relaxed and calm as we discuss our progress and troubles. Our Scrum Master (shortened to SM from now on) is really good at starting conversations and bringing us from a point to another, and I think meshed well with us. One funny moment happened during our retrospective, as our SM’s little sibling joined our conversation and started giving us nicknames. Also, on the same retrospective, we attempted to make our friend's laptop crash by overheating.

Just like an actual sprint, it is really tiring.

A Retrospective

(get it? Because sprints have retrospectives, and this part is where I reflect? ok)

I’ll be honest: it has been frustrating.

Some of our problems came from sources that we can’t handle, such as the Gitlab going down for a while and one of our member’s laptop broke, stunting our progress considerably. Changes in our tools ended up making things harder for another member, so we have to revert those changes, wasting precious time. Our university schedule disallows us from giving a large amount of time to focus on this project, so we ended up rushing the final 3 days before the sprint review.

Personally, I’ve felt like I wasn’t proactive enough, whether in giving opinions or taking tasks. I’ve also felt like the methodology is a bit of a shock as well, as even though we’ve learned about it theoretically, experiencing and implementing it is another different beast. As of the writing of this article, it reached a point of overwhelming that I’ve started to feel a bit crazy (hence, the title).

But I feel that’s the point. This is our first time, there are bound to make mistakes. And what should we do with that mistakes? We learn. We strive to be better, improving from our mistakes in the past and use it as motivation. In the short period of time we are allowed to work on our project, we have to be able to rectify those mistakes on the go, and adapt to changes along the way, improving our teamwork and team skills along the way. All that to deliver a better, cleaner quality product.

In short?

We have to be agile.

I really wanted to end with that punchline.

here’s a picture of a man giving a thumbs up to make up for the lack of images, apologies.