Ag·ile: A Software Development Methodology

Surya Nirvana
bisaGo2020
Published in
7 min readOct 8, 2020
Source: unsplash.com

Nowadays, we often hear the term ‘agile’ almost everywhere, and its use has increased exponentially since the 1980s, which speaks volumes about its popularity. So what is ‘agile’ anyways? When we look up the term on Google, the first definition that will come up is “able to move quickly and easily, as well as to adapt to change quickly, effectively, and efficiently.” That definition remains true in the Software Development World. More specifically, agile is a process of discovering requirements and solutions based on the twelve principles defined in the Agile Manifesto, which are:

Twelve principles of Agile

Why Agile?

Agile is well-known for its iterative and incremental process flow. “Iterative and Incremental?” Yes, agile is both. It’s an iterative process in that it plans for the work of one iteration to be improved upon in subsequent iterations. It allows the team to learn something new in each iteration. It’s also incremental because a completed work is delivered throughout the project. Agile also focuses on the team’s productivity and creative problem-solving skill.

Scrum, an agile framework

One of the popular and preferred methods in agile software development is Scrum. The name comes from rugby; it’s defined as a formation where everyone plays a specific role. Scrum is an agile framework that emphasizes teamwork, accountability, and two up-to four weeks of iterative progress towards a well-defined goal. Everyone has a role involved in this development process. These roles consist of Scrum Master (SM), Product Owner (PO), and Development Team.

Source: https://www.visual-paradigm.com/scrum/how-scrum-team-works/

Scrum Master

A very people-centric role with a heavy emphasis on coaching, teaching, and facilitation. The scrum master is responsible for uniting the team and ensuring that the scrum is done correctly. It helps the product owner define value, the development team delivers the value, and the scrum team to get better. It acts as a communication-bridge from the development team to the product owner.

Product Owner

A person who is passionate about the customer, managing stakeholders, and the business domain. The product owner is responsible for delivering the most value of a product. This means that the product owner must understand every single item in the product backlog to avoid miscommunication with the development team and make sure things run smoothly in the development process.

Development Team

At first glance, we might think that the development team only consists of engineers. That’s not the case. Usually, the development team can consist of designers, programmers, QA, etc. It’s a self-organized team that helps the product owner deliver value to the product, which means developing what it needs to be developed. They can support each other, make a decision, and provide the solution to a problem.

Scrum Events

Scrum consists of events that need to be done in each iteration or the term ‘sprint’, as we call it.

Source: https://agilityontap.com/blog/

Sprint Planning

It starts with Sprint Planning at the beginning of the development process. First, the product owner must define the goal of each sprint. Then, the team must choose a corresponding product backlog with the goal. The product owner must break down every product backlog that they choose as tasks. The product owner also has to define the acceptance criteria of each task. After that, the development team will determine each task’s estimation point with Point Fibonacci (1, 2, 3, 5, 8, 13, 20, etc.). This estimation point will determine how long or how difficult the task is. The higher the number, the longer or harder it takes to complete the task.

Daily Scrum Meeting

Or the daily stand-up meeting is a place where questions like “what did you do yesterday?”, “what will you do today?”, and “are there any blockers or obstacles in the development process?” are asked. This helps the team to understand the work that has been done and hasn’t been done yet.

Sprint Review

A sprint review is usually held at the end of the sprint. The team must present tasks that have been done in the past two or four weeks in a working or deliverable software or product. Whether or not each task gets approved and accepted will depend on the product owner’s decision. Usually, the QA will present the working software.

Sprint Retrospective

A sprint retrospective is a place for the team to reflect their performance in the past sprint. They usually share what they’ve learned, what they should maintain, what they should improve, and their plans for the next sprint.

All of these events above are repeated every two or four weeks.

Implementation in Our Team

Since this is the first sprint, we’ve only been involved in sprint planning and daily scrum meeting. Prior to that, the product owner has formulized the Product Backlog Item (PBI for short) and the product’s mockup. Every sprint starts with sprint planning. As I’ve already mentioned above, we must first define our goal: what we want to achieve for this sprint. For example, our current goal is to show different types of disabilities when the “Tentang Disabilitas” page is accessed and getting users’ feedback for the existing application. After that, we must choose the corresponding product backlog with the goal, break it down into tasks, determine each task’s difficulty, and assign each task to each team member.

Now that the sprint planning is completed, we can start the sprint. During the sprint, the Scrum Master will hold a daily scrum meeting. Scrum daily stand up meetings are usually done every day; however, In our case, this meeting is conducted twice a week (every Tuesday and Friday evening). During this meeting, each team member must share what they have been working on, their plans before the next meeting, and share any blockers or obstacles.

I’ve used the scrum methodology several times myself, as well as attending all of its events before (or we can say that I’ve completed a sprint several times before). Based on my experience, what happened was more or less the same as in PPL, as I’ve explained above.

Agile Principles in My Team

Satisfy the customer

Our number one/highest priority is to make the customer happy. Every sprint, we aim to deliver something new to the product. We aim to increase the functionality with the maximum effort to get the maximum results. For example, last week, we managed to reach one of the sprint goals by coming up with a new product feature (“Tentang Disabilitas” page).

Welcome changing requirements

Agile principles support observing changing markets, customer needs, and competitive threats and changing course when necessary. We continuously listen for every feedback that we get, even in the late development process. This requirement changes indicate that our team has learned more and has what it takes to satisfy the customer. The customer wants us to rearrange the sidebar from the last sprint, and we immediately made rearrangement to the sidebar.

Deliver working software frequently

Our goal for every sprint is to deliver a working product, usually conducted every Sprint Review. Before the Sprint Review, we must make sure that our software is working.

Work together daily

One method that we conducted to keep everyone connected is daily update meetings or standups. Not only that, but we usually held a “code-together” session so that the development team can help each other out. But our team still struggling to find the right schedule because each team member has their own stuff to do.

Build projects around motivated individuals

The agile team must be carefully built to include the right people and skillsets to get the job done. Responsibilities need to be clearly defined before the beginning of a project. We usually conduct a daily standup meeting to keep up with each other and keep up the good work.

Sustainable development

Our team tries to pace ourselves and work at a rate that allows us to maintain the project’s highest quality standards, and we try to keep our work pace for each sprint.

Measure of progress

Agile projects measure their progress by measuring the amount of software currently meeting the customer’s needs. We usually share each other progress in daily standup meetings to track our progress on how many tasks are left to meet customer satisfaction.

Face-to-face conversation

In this current situation, it’s hard to conduct a face-to-face interaction. We usually use Zoom, Google Meet, Discord as a platform for us to communicate. It’s not very effective, but that’s what we can do right now.

Continuous attention to technical excellence and good design

High quality is the key to high speed. The way to go fast is to keep the software as clean and robust as possible. Thus, all agile team members are committed to producing only the highest quality code they can. One of the many principles that we tried to apply is clean code. I’ve written my experience of clean code in my other article.

Simplicity is essential

Our team goal is to perform the simplest work with the highest quality of code so that our project can be easily maintained.

Self-organizing teams

Agile team members work together on all aspects of the project. Each member is allowed input into the whole. On my team, each team member is assigned to a task that they must complete. We share our responsibilities because each team member influences them.

Regularity reflect on continuously improving

Sprint Retrospective, one way for us to reflect and improved. We share what we need to start doing, what we need to stop doing, and what should be maintained. From this event, we know what we must do and improve for the next sprint. For example, our team needs to start to deploy the backend to a new server; our team needs to stop procrastinating, and our team has to maintain our work pace.

References

--

--

Surya Nirvana
bisaGo2020

Penultimate Computer Science student who is struggling to write an article. Currently seeking experience in Tech and Data Department.