Agile and Its Implementation with Scrum

Normally, digital products are in a new, fast-moving market that changes frequently. That being said, the development process of digital products needs an approach that is flexible.


Agile is “the art of iterative and incremental software development”. It is a type of project management process, where problems and solutions are evolving through the development process. It consists of a collection of principles that provide adaptability and flexibility.

Agile concept emerged around the end of the 90s to the beginning of the new millennium. In the 1990s, with the increasing of software needs, the industries realized that they couldn’t move fast enough to meet customer demands, it took about 3 years to develop a single software. At that time, softwares were released all-at-once, which means, the customer could not use the product until it was fully developed. Because it took an enormous time, by the time an actual application was finished, it was highly likely that the requirements defined at the beginning of the development, three years before released, had already changed and the software became outdated.

In 2001, a group of industry practitioners gathered up to discuss a new approach in software development. Although the aim of the discussion was to talk about effective development cycles, it was the beginning of Agile Methodology.

Every philosophy or concept must have a manifesto that consists of a declaration of values and principles that expresses its stance, views, and intentions, including Agile.

Agile Manifesto made up of four foundational values and 12 key principles.

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Derived from these values, from, there are 12 principles in Agile Manifesto.

  1. Customer satisfaction through early and continuous software delivery
  2. Accommodate changing requirements throughout the development process
  3. Frequent delivery of working software
  4. Collaboration between the business stakeholders and developers throughout the project
  5. Support, trust, and motivate the people involved
  6. Enable face-to-face interactions
  7. Working software is the primary measure of progress
  8. Agile processes to support a consistent development pace
  9. Attention to technical detail and design enhances agility
  10. Simplicity
  11. Self-organizing teams encourage great architectures, requirements, and designs
  12. Regular reflections on how to become more effective

However, in my opinion, these principles and manifestos should not be ‘stiff’ because we can eliminate some of these points can be eliminated with the agile purpose still achieved.

Accommodate changing requirements throughout the development process

To some point, I agree that accommodation for changing requirements should be available throughout the development process, but only for minor things like the design of the button, etc. If we’re changing the core requirement like the business process of the application in the middle of the development, the software will less likely to be finished and the effort the development team has put in will be useless.

Enable face-to-face interactions

Face-to-face interaction is important to directly update the progress of each member's task. However, with the improvement of technology, the are many tools that were made specifically for scrum and agile processes. For example, there’s a bot in Slack messenger called standup-bot that will automatically ask each member of the group to give an update of their task.

Self-organizing teams encourage great architectures, requirements, and designs

A self-organizing team is a blessing for a collaborative project, but it does not necessarily mean it will encourage great architectures, requirements, and designs, it all still depends on the team member’s initial skill.

Collaboration between the business stakeholders and developers throughout the project

Not all client can accompany throughout the development process. If the client is busy, we can tackle this by settling the fixed requirement at the beginning of the project.


It depends if we over-simplify things, things will get even more complicated after some times, so the important thing is not simplicity but maintaining ✨standard✨.

To achieve these principles and values, organizations usually use several methods such as Scrum, Extreme Programming (XP), Crystal Methodology, Dynamic Software Development Method, etc.

In the software engineering project course, our team develop a web-based application for mobile named Raising Star. This application basically aimed to help parents in tracking their children’s development. We decided to use Agile to approach our project because the client wants to see every increment of the development of the product.

Agile Methodologies

Scrum is characterised by cycles or stages of development, known as sprints, and by the maximisation of development time for a software product. It is usually used in the management of development projects for software products, but it can also be used in a business-related context.

Kanban means “just-in-time”. In practice, the Kanban method exists in a board or table (Kanban board), divided into columns that shows every flow of the software production. As the development evolves, the information contained in the table changes, and when a new task comes into play, a new “card” is created.

This methodology prioritises customer’s satisfaction over anything else. This methodology motivates developers to accept change of requirements even if they arrive in a later stage of the development cycle.

In XP, when the team stumbled upon a problem, it is solved by the whole team of managers, developers, and customers.

Lean Development is a methodology that comes directly from Lean Manufacturing, created by Toyota. There are 7 principles in Lean Development:

Deleting the things that do not matter

Everything that does not bring effective value to the customer’s project is deleted

Quality development

creating quality in development requires discipline and control of the quantity of residuals created

Creating knowledge

the team is motivated to document the whole infrastructure to later retain that value

Differing commitments

this point encourages the team not to focus too much on planning and anticipating ideas without having a prior and complete understanding of the requirements of the business

Fast delivery

deliver value to the customer as soon as possible

Respecting the team

communicating and managing conflicts are two essential points

Optimise the whole

the development sequence has to be perfected enough to be able to delete errors in the code, in order to create a flow of true value.

Crystal focuses on principles such as People, Interactions, Community, Skills, Talent and Communication, aiming to deliver the best possible software development process. The core of this development process is interaction and symbiosis, which have to exist between the people allocated to the projects and processes in order to bring efficiency to the development.

Non-Agile Methodologies

Besides agile methodologies, there are also non-agile methodologies. The difference between agile and non-agile methodologies is in non agile methodologies, you can only proceed to the next stage when the current stage is 100% done. There are some non-agile methodologies:

Waterfall methodology is a linear approach to software development. In this methodology, the sequence of events is:

  1. Gather and document requirements
  2. Design
  3. Code and unit test
  4. Perform system testing
  5. Perform user acceptance testing (UAT)
  6. Fix any issues
  7. Deliver the finished product

In a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin..

The difference with Waterfall method is in V-Shaped Model, quality assurance actions related to each activities


Why Scrum is more popular than others?

After knowing many software development methodologies, you’ll wonder why do people usually use Scrum instead of other methodologies?


Scrum is about adapting as you progress, rather than excessive planning in the beginning. In this fast-paced world, being adaptive is important.

Get Value Fast

In each iteration/sprint, customer can see the results fast which can lower risks of customer unsatisfiablity and improves stakeholder relationships. Other than that, customer/clients also have the opportunity to change or refine the rquirements.


Scrum is known to be a “team-centric” project management approach. It’s perfect for organisations with many teams (which almost all companies have many teams).

How our team using agile to develop our product

To implement Agile Methodology, we use Scrum Method.


Scrum is a framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. There are several actors in Scrum Framework:

Product Owner (PO)

Product Owner is the one that orders the work for a complex problem into a Product Backlog and managing the backlog, which includes:

  • Developing and explicitly communicating the Product Goal;
  • Creating and clearly communicating Product Backlog items;
  • Ordering Product Backlog items
  • Ensuring that the Product Backlog is transparent, visible and understood.

Scrum Master (SM)

SM is responsible for ensuring Scrum is understood and enacted. SM also needs to make sure that the team can work comfortably, including:

  • Coaching the team members in self-management and cross-functionality;
  • Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
  • Causing the removal of impediments to the Scrum Team’s progress; and,
  • Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

SM also helps product owner in several ways:

  • Helping find techniques for effective Product Goal definition and Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Helping establish empirical product planning for a complex environment;

Scrum Team/Development Team

This is the team that turns a selection of the work into an Increment of value during a Sprint. This team can include software engineers, architects, programmers, analysts, system admins, QA experts, testers, UI designers, etc.

The responsibilities of Development Team includes

  • Decides how many items to build in a Sprint, and how best to accomplish that goal.
  • Developing, testing and releasing the Product increment.
  • Builds the product that the Product Owner indicates: the application or website, for example. The Team in Scrum is “cross-functional”

Organize the Backlog

This event is the responsibility of the product owner. It is basically a set of features and its expected outcome. In our project, it is manifested this way:

Every feature is put into a more detailed list called backlog, these backlogs are what we need to do in order to develop the feature.

Sprint Planning

This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific use stories are then added to the sprint from the product backlog.

Our team usually has a 2 hours meeting for Sprint Planning. In Sprint Planning, we picked which features we want to develop and weighed each backlog. After that, we discuss the distribution of tasks.


A sprint is the actual time period when the scrum team works together to finish an increment. Each sprint in our team is 2 weeks. To ease the development process, we develop every user story and task in different branches.

Stand Up Meeting

This is a daily super-short meeting that happens at the same time (usually mornings) and place. We do our stand-up every Thursday and Sunday.

If you can’t do a standup meeting daily, make sure the gap between days is even.

Sprint Review

This happens at the end of the sprint. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback.

Usually, in Software Engineering Project Course, the Sprint Review is held in the class schedule every 2 weeks. In every sprint review, our team presented what we developed.

First Sprint

In the first sprint, we developed tutorial page, login and signup pages, and also child’s assessment. We chose these backlogs in the first sprint because these features are essential for the whole products.

tutorial page
Login page
signup page
assessment page

Second Sprint

In the second sprint, we developed Activity pages which consists of activities that user can do to accelerate their child’s growth.

Third Sprint

In the third sprint, we developed ‘Materi’ pages and profile pages.

Fourth Sprint

In the fourth sprint, we developed static pages of consultations.

Fifth Sprint

In the fifth sprint, we basically fixed things that are not perfect in the previous sprints, but for the new features, we developed sign up using Google Account and Edit Profile.

Intermezzo: change during sprint by Product Owner

What if in the middle of a sprint, PO asks for requirement changes?

In my opinion, product owner can change the requirement if:

  • The change not violates the sprint goal
  • Changes should be negotiated with the development team.

Sprint Retrospective

The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies.

In each sprint retrospective, we usually write down 4 things: What are the bads, the goods in the previous sprint, what we need to start doing, and what needs to stop. This is an example of what we think we need to start do in the next sprint:

Closing Remarks

To develop software is to organize and understand the people. I think that the approach of Agile that puts interaction between team members first is a good approach.

Thank you for reading 😊