Moving Quickly: An Agile and Scrum Overview

8 min readMar 10, 2020

You came into the room nervous. The atmosphere was tense. You were about to present your team’s creation, the software that you had been working for the past six months. You had given the best of your efforts. The one who needed the software is there. He checked on the software and said, “Sorry, this is not what we needed”

Of course that will be a total nightmare. You had done everything to create magnificent and efficient software but that is not what they need. Sometimes you need to change the requirements quite early. Not to mention what will happen if you don’t have all the requirements early in development. Maybe you need to make it quick. Maybe you should go fast. Maybe you need to be agile.

So I used agile methodology before, that is in one of my projects in college. The picture above is the general flow of agile methodology and I will talk about it more after this. I will tell you some of the experience that I have gathered so far.

Agile Methodology

Agile methodology is a methodology that centers around iterative development, that is developing and testing the software iteratively. What it will do is that we can deliver more product faster with better quality. Agile methodology consists of several software development methodologies, so it is actually a framework and not a step-by-step guide to do software development.

When we talk about agile, we can not exclude agile manifesto. The manifesto has the concepts of agile development and is developed by fourteen people who have compiled their experience of what works and what is not working in a development process. Any framework or methodologies that align with the concepts stated in the manifesto are considered to be part of agile methodologies. Some of the popular frameworks that are considered a part of agile methodology are Agile Scrum Methodology, Lean Software Development, Kanban, Extreme Programming (XP) and many more. There are even companies that create their own version of agile. What remains the same is that they all refer to the concepts written in the agile manifesto.

Values

When we first look at the agile manifesto, there are things that popped out immediately, that is the core values of agile itself. Basically, agile manifesto values some things more than the other. That doesn’t mean that the others are worthless though. They value Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan. All of this needs to be followed for a successful agile development.

Principles

Agile methodologies have their principles that need to be followed. There are 12 of them and all of this can be read in the agile manifesto. They all lead to the same values and have the same purpose: to deliver the best software to the customer.

My Experience with Agile

Now since we have established what agile is, I’m going to talk about the use of agile in my team. My team and I are currently working on a software for a college project. Before we even begin developing, we need to establish how to do agile development and to be honest agile might have been the best choice for us. Our customer for this project doesn’t have the full requirement ready. Releasing a lot of increments in a short amount of time might have been better because we don’t know whether or not we need a feature or not. In this case, we use scrum framework. But wait, what is scrum framework?

Scrum Framework

Scrum framework is a framework that is a subset of agile methodology. Scrum framework is one of the most widely used framework for developing software because it is simple and lightweight. Scrum framework is relatively hard to master though. I will provide a lot of examples from my experience of using scrum in this.

The next section will be full of things that are written in the official scrum guide and my own experience. Since there are a lot of different versions of scrum, I will only use the official one (which I put the link down in the reference). As for the picture above, it is the diagram representing the workflow of scrum.

Definition of Scrum

Scrum is a framework that is used to manage big and complex problems. In a development process that uses scrum framework, there are scrum teams with their roles, events, artifacts, and rules. The rules are the one that governs and controls the whole scrum process, ensuring all other components work well. Scrum teams usually consist of a small number of people so that they can work and collaborate productively. The productivity and simpleness of scrum made scrum used in a lot of different fields, such as hardware, software, marketing, and even government. In my case, scrum is used in a software development process.

Pillars of Scrum and Scrum Values

There are three things that need to be done to ensure that a scrum development process comes out successfully. The three pillars are transparency, inspection, and adaptation. Transparency means that all of the processes need to be visible for all team members. Inspection means that the members need to actively check and inspect the scrum artifacts. Adaptation means that adjustments need to be made when there is something that went wrong in the group. These three pillars derive five values that scrum users need to embody. The values are commitment, courage, focus, openness and respect.

In my team, all of these are implemented even though we need a lot of time to adapt to this new framework. For transparency, we use management tools online where all of us can see what the other people have done. We also regularly check the tools to know our own progress. Twice a week we will talk about the obstacles that happen to us while we are developing. That way, other members will know and help us if they can. We need to be open about the problems and have the courage to do the right thing, so that the problems don’t persist and become a bigger problem in the future.

Scrum Team

A development team in scrum, as I stated before, consists of a small number of people with their respective roles. The team should be self organizing; that means the team needs to be able to organize work and no one dictate the team to do something. The other characteristic of a scrum team is that they are cross functional, that means everyone needs to be able to do everything. In our team, these two characteristics exist, even though they still need to be improved. We divide the tasks ourself and divide it by features, highlighting the self organizing and cross functional values.

Even though the development team recognizes no title, there are several roles outside of the development team that need to be recognized. The roles are development team, scrum master, and product owner. We have talked about the development team before, so we will continue with other roles. Scrum master has the function to help other people of the team understand scrum. They act as a coach to the team, ensuring that the scrum is working like it should be. The product owner is the one who knows what the product should be. He is the one responsible for making the product backlog for the team. All of these roles exist in my team. There is one person as the scrum master, one person as the product owner, and five other people as the development team. I am one of the members of the development team.

Scrum Events

There is a need for regularity in scrum. Not only that, we need to minimize the meeting not defined in scrum. The first and the container of all other events is the sprint. Sprint is a time box that is ranged from one week to a month. This closed time box is where an increment is developed. Sprint has all the other scrum events, that is Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective.

A sprint starts with sprint planning, filled with daily scrum meeting, and ends with sprint review and retrospective. Sprint planning is the time when the scrum team “designs” what they will do for the upcoming sprint. It will discuss what should be done and how they will do it. They also define the sprint goal. To monitor the progress of the increment, a daily scrum meeting is done. During the daily scrum meeting, each member would share what they had done, what they would do, and problems they encounter. At the end of the sprint, there needs to be evaluation of the product and the workflow. That is why sprint review and retrospective is made. Sprint review is where the increment is evaluated while sprint retrospective is where the workflow is evaluated. Usually, sprint review talks about whether or not the increment has fulfilled the requirements and sprint retrospective talks about the people and the system.

The implementation of these scrum events might be different in different places. In our team, the term “daily” in daily scrum meeting is not really daily since it is done only twice a week. We still talk about what we should talk about, but just not that often. Other than that, the sprint in my team works almost the same way as other. The sprint lasted for two weeks with sprint planning, daily scrum, sprint review, and sprint retrospective.

There is one thing that I want to talk about in particular. When we are planning a sprint and decide on a task, we may encounter a task that depends on another task, that is we can not work a task before another task is done. This is called blocking. This is a thing that happened during my first sprint. I needed to wait for the other member to work on his task before I could even begin. This is a bad thing because I could have done other tasks. Instead, I needed to wait.

Scrum Artifacts

To work properly, we need something to represent the work at hand and its values. It consists of Product Backlog and Sprint Backlog. Product backlogs consists of product backlog items. The backlog items are a set of things that are known to be essential for the product that is being made. The backlog items are ordered by their priority: the first one on the list are usually the most important one to have. When sprint planning starts we will pick which of the backlog items to be worked on. This set of backlog items that we want to work on in a particular sprint is called sprint backlog.

When we make these artifacts, we need to consider their transparency and their definition of done. A definition of done is what decides whether or not a sprint backlog can be considered finished and we can work on something else.

Conclusion

At the end, the use of scrum in my team needs to be improved. Scrum is an easy to grab framework but it is hard to master. Scrum should be able to help the developers to work together with their team and consumer to bring out the best product but we are not doing that right now. We are still learning how to use it and hopefully we will be able to become a good team and deliver the best version of the application we are working on.