Agile and Scrum: What and Why?

Audilla Putri
7 min readMar 20, 2021

--

image source : tsh.io

When you’re working on a project, you aim for the success of the project, right? Surely, there are some objectives that you want to achieve. That is why it’s essential to have a good project management system that can help you accomplish your goals. I’m here to save the day and introduce you to a method that will help you manage your project efficiently!

Currently, I’m working on a software development project for PPL course with a team of five. Among many software development methodologies, we decide to use one widely used by many. The method is no other than the famous Agile Methodology.

So what is agile methodology?

Agile refers to a set of methodologies used in software development that involves collaboration, self-organization, and adaptiveness. The word “agile” itself is defined as the ability to move quickly — or in this context the ability to respond to changes. This methodology is based on a manifesto created by 17 software developers in Utah who wanted to suggest a new mindset — “doing it and helping others do it”. There are 12 principles applied in the agile manifesto along with four values :

  • Individuals and interactions over processes and tools — Though, process and tools are essentials for the product, the people behind the process are more valuable. This is because the communication as an individual when there’s a need is more responsive and more likely to satisfy customer’s needs rather than communicating as a process.
  • Working software over comprehensive documentation — Before Agile is introduced, extensive documentations about technical requirements, planning documentation, design documentations, etc. are made for the sake of deployment and development. But the process of making those documents takes a long and exhaustive time. Agile uses user story to help software developers work. Comprehensive documentation is still valued, but working software is valued more.
  • Customer collaboration over contract negotiation — Negotiation for product delivery is usually conducted in the very first step of creating a product. Alas, having the customer stating the requirements only at the beginning of the process may cause some needs won’t be fulfilled. Agile encourages customer collaboration throughout the process so any changes, addition, or critiques from the customer can be worked with immediately before launching the final product.
  • Responding to change over following a plan — Agile keeps iterations in a short period of time so that any changes from the plan can be done in the next iterations. Old development methods used to see changes in plan as an expense, but Agile sees it as an opportunity to improve.

Me, My Team, and Agile

As we’ve discussed before, agile methodology is focused on the people doing the work and how they do the work. It revolves around teamwork and a disciplined project management process. Unlike other methodology, Agile will break down the the products into smaller parts and deliver the product incrementally instead of delivering the product all at once. By doing so, I (and I’m pretty sure the rest of my team members too) felt helped in staying focused on what needs to be done for one sprint. It also encourages us to be productive and improving what can be improved if there’s a spare time.

Another point is that we also feel a deep collaboration with the customer so that we’re not designing and developing the product blindly. Through some reviews and suggestions, we’re able to fix what’s lacking in the design and the functionalities from sprint to sprint. Internally, the communication among the members of my team is also very fluid as we would communicate whenever we’re facing a difficulty in a process.

The vital tool of agile is iterations. As there are various development methods used in agile, iterations are achieved in different ways. In this PPL project, my team use the scrum method. There’s a term in scrum called sprint which is a timeframe where the development team needs to complete defined tasks in order to accomplish certain goals.

Before we cover the depths of agile methodology, let’s get into scrum first so we can understand how it works in the agile workflow.

Scrum

Scrum is one of the many development methods of agile methodology. On my PPL project we implement scrum so our team would be organized and able to finish more work in less time. Scrum consists of sprints that typically lasts for two until three weeks. In my case, one sprint takes two weeks. During a sprint, my team will run a series of steps that will help us achieve pre-established goals. To understand how scrum works, we need to know the actors of scrum :

  • Product Owner is the person who’s in charge of the requirements. They create user stories and product backlog based on the user story.
  • Scrum master is the person responsible for the process. They make sure the team is working efficiently and effectively. A scrum master must be constantly aware of the project’s status and whether there has been any progress or obstacle. Scrum master also facilitates the daily stand up meetings which in my case are held two times a week. In the meeting, our scrum master will ask each member of the team the progress we’ve made and whether we’ve found difficulties.
  • Development Team is a group of people whose focus is in developing and testing the product. Ideally, the number of members in a development team should range around five to nine people. In this project, my team consists of five people. Since we’re the ones who do the hands-on work on the product, we are in charge of splitting the work into tasks and assign the members on specific task(s).

Now that we understand the roles, let’s get into the workflow!

Scrum in the Agile Workflow

image source : finetech.co.uk

1. Requirements. Before designing a product, we need to gather requirements for the product. These requirements will cover the goals that the product wants to achieve, the features that the product will support, and the features that the goal will not support. Product owner will place all these requirement and task into the product backlog. In the scrum framework, this phase can also be called the sprint planning. It is also the phase where my team divide the tasks we want to do for a sprint and assign a member to the task(s). Here’s an example on how my team splits the tasks:

2. Design. Once the requirements are gathered, the development team — me and my team mates — must decide how we will meet the requirements. For the software itself, we discussed about the programming language, tools, frameworks, and libraries that are suitable. Functionality is important, but so is user experience. On the front-end side, we also prepare a UI mock-up along with the application prototype. For the subsequent sprint, the design will be reviewed and refined if necessary.

3. Development. This phase is centered around writing codes that will turn the design into an actual functional software. Compared to other phase, the development phase may take the longest time.

4. Testing. After the development phase, a series of test must be conducted to make sure that the application is compatible and functioning accordingly. In this phase, the development team will make sure that the code is clean and bug-free.

5. Deployment. The product will be deployed once it has passed all the test whether as a demo or a finished product. In this phase which is also known as the sprint review, the result of previous steps will be delivered to the client. While presenting, the client may give feedbacks about the product. The client can also address if there are any changes regarding the requirements. This is where the ability to adapt is needed.

6. Review. After demonstrating the product of the sprint, product owner will conduct a meeting with the development team to talk about the previous sprint. The work of the team will be reviewed along with what can be improved for the next sprint. This step is also called sprint retrospective. When my team holds a sprint retrospective, we use metroretro.io to help us list what things are good and what things are bad in that sprint. We also list what we should start doing and what we should stop doing for the next sprint. Here’s a screenshot of the board my team and I made during sprint retrospective.

Example of sprint retrospective

--

--