Agile: A Savior Methodology in Software Development

This article was written as an Individual Review assignment for PPL Computer Science Universitas Indonesia 2021


Without any experience in developing software, they began their project from meeting after meeting with the company to know what they want for their websites. Meeting-Designing-Developing Code, that’s what they do over and over again, until they reach a certain point to realize they are doing it the wrong way. One by one they start reviewing all of their work to find out what went wrong with their project.

Finally, they realized that they had forgotten the most important thing in software development, which is the methodology.


They found one methodology which will become their savior in the project. That is Agile Development.

Start with WHY: WHY Agile?

What is Software Development Methodology?

Software development methodologies define the processes we use to build software.

Some methodologies are fairly lightweight and don’t tell you much besides a set of principles to stand by.

Software development methodology is way in developing a software that consist of steps that we can use to make our work easier based on user/teams needs. There are many software development methodology that you can use based on your requirements.

What is Agile?

Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.

Agile really help you in thinking through about what’s goin on in the environment that you’re in now, by identifying what is the uncertainty that you’re facing and how you can adapt with that.

What is Agile Software Development?

Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it.

From reading this, you realize that Agile software development is more than just a framework and its more than practices such as test-driven developement, sprints, and etc. It’s a roof that consist of framework and practices that really based on Agile Manifesto and 12 principles that support the manifesto. Agile approach in software development is focusing on the people doing the work and how they work together.

Teamwork GIF by GIPHY

How to use Agile Software Development?

  1. Individuals and interactions over processes and tools

We must valuing people more highly than processes or tools, it’s easy to understand because it is the people who respond to business needs and drive the development processs. Good communication is a good example of how we differentiate between judging individuals about processes

2. Working software over comprehensive documentation

Enormous amounts of time were spent on documenting the product for development, the list was extensive that causing the long delays in development. Agile doesn’t eliminate documentation. In agile, you values documentation, but it values working software more.

3. Customer Collaboration Over Contract Negotiation

Agile manifesto describes a customer who is engaged and collaborates throughout the development process, this makes it easier for development to meet their needs of the customer.

4. Responding to Change Over Following a Plan

In conventional way, change is an expense, so it was to be avoided. In Agile Manifesto, flexibility is main the key of agile, customer requirements can change at anytime, we must adapt to it at every sprint and plan it for the next one. The result is a higher quality of the project and more satisfaction from customers.

Next one, here is the 12 principles with how I and my team implement the principles in our project:

  1. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. How to do it: We always try to adapt with the requirements change that the clients ask. Even, if it not possible to do that in a sprint, we always consider it to do it in the next sprint, adjusting with the weight of the change to the project.
  2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. How to do it: We deliver working software consistent for every two week to the client.
  3. Business people and developers must work together daily throughout the project. How to do it: Our client is the business people, so we always ask their advice about our progress daily to keep us together on track to reach our goals.
  4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. How to do it: My team is the most importing in the developing a software. Me and my team have the same goals and motivation in developing our project. We regulary communicate with each other to discuss our progress and ask each other advice for building a better environment in our work.
  5. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. How to do it: Because of the pandemic, we can’t meet face-to-face with each other, but that doesn’t reduce the communication between us. We regulary have video call meeting every week to discuss the problem we’re facing in our work.
  6. Working software is the primary measure of progress. How to do it: Every two weeks, we have some task we must complete to become a working software, we always try to finish it before the deadline.
  7. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. How to do it: We always communicate with each other to ask the progress, is every person is on the same pace? if it’s not we will discuss together and tried to solve the problem.
  8. Continuous attention to technical excellence and good design enhances agility. How to do it: We always tried to implement basic principle like clean code, TDD, and etc. to make our work more readable for everyone. Our work always refers to the design that has been approved together with the clients.
  9. Simplicity–the art of maximizing the amount of work not done–is essential. How to do it: Every work we do always refers to the timeline that we make on the beginning, so we always tried to keep a full functionable task done on time than the design that can catch up in the end.
  10. The best architectures, requirements, and designs emerge from self-organizing teams. How to do it: Me and all my team member know their own roles and task to achieve our goals.
  11. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. How to do it: Every two week, we have a meeting that is called sprint retrospective, to reflect about the work and progress that we do in the past two weeks. There are clients, lectures, product owner, and scrum master that will join that meeting to review our work and give us advice about that to make our development better on the future.
images from

Last, to complete our undestanding in Agile Development, there are many methods we can use to implement Agile Development. The method that me and my team use is Scrum. Scrum is a framework that helps people, teams, and organization generate value through adaptive solutions for complex problem. There are three roles in scrum, that is:

  1. Scrum Master: SM helps the product group learn and apply Scrum to achieve business value. SM serves the team, in helping to remove impediments, protects the team from outside interference, and helps the team to adopt agile development practices.
  2. Product Owner: PO is responsible for maximizing return on investment by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next sprint.
  3. Development Team: Dev Team is a collection of individuals working together to develop and deliver the requested and commited product increments and each members capable of achieving the sprint goals.

Agile Scrum Artifact

source: atlassian

Product Backlog

The product backlog is a list of new features, enhancements, bug fixes, tasks, or job requirements needed to build a product. It is gathered from input sources such as customer support, competitor analysis, market demand, and general business analysis.

The product backlog is a “live” artifact that is updated on demand as new information becomes available. This is a cross-team repository that the product owner maintains and curates between sprint cycles and as new ideas emerge. It contains tasks that are in the active sprint but are prioritized and moved to the backlog.

Sprint backlog

The sprint backlog is a set of product backlog tasks that have been promoted for development during subsequent product improvements. The sprint backlog is created by the development team to plan deliverables for future increases and details the work required to make those increases.
The sprint backlog is created by selecting tasks from the product backlog and breaking those tasks down into smaller, actionable sprint items.

Product increment

Product upgrades are customer deliverables that are generated by completing product backlog tasks during a sprint. It also includes adding to all previous sprints. There is always one increment per sprint and one increment determined during the scrum planning phase. Improvements occur when the team decides to release to customers. The product additions are very useful and complement CI / CD in version tracking and, if necessary, version rollbacks.

Extended artifacts

  • Burndown chart: The sprint burndown (or burnup) chart is not an official scrum artifact but many teams use it to communicate and track progress towards sprint goals during a sprint.
  • Definition of “done”: It is important for the team to have a clear definition of “done.” This definition can be another type of artifact, which must be documented and shared.

In Scrum, there are five key event that we need to do:

  1. Sprint Planning: This is the event that kick starts each sprint, where PO and Dev Team discuss which Product Backlog Item (PBI) will be done in a sprint. The outcome of the sprint planning event is to get a sprint goal and sprint backlog that everyone agrees is realistic and achievable.

2. Daily Scrum: Daily Scrum is the time for Dev Team to check-in, assess progress towards achieving the Sprint Goal and to review and plan their activities for the next 24 hours.

3. Sprint Review: Sprint Review usually takes place on the last day of the sprint. The SM will show the done increment to stakeholders and inspecting working features produces during the sprint.

4. Sprint Retrospective: This is the final event in Sprint. The SM will reviews what could be improved for future Sprints and how they should do it. This event should be a collaborative effort just like the entire Agile process.

That’s all! Thanks for your time in reading this article!

To connect with me, you can connect with my LinkedIn


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store