Agile and Scrum, Work like a Charm✨

8 min readMar 21, 2021

In the so-called “tech” world, everything moves really fast. There will always be something new every day, such as new technology, new knowledge, new trends, new needs, and the product needs to adapt to these changes quickly to stay up to date. But the thing is, you can’t make a product in just several days. So, how do things work?

Nowadays, every technology organization seems to practice the agile methodology for software development, or they believe they do. According to Oxford Dictionary, Agile means “able to move quickly and easily.” Martin Fowler and the other 16 developers must have aimed for the same meaning when they made the manifesto with the same name. This manifesto laid out four key values:

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

The manifesto was a critical milestone in the history of Agile, which then became the basis of the agile development methodology that is commonly used now. They also laid out 12 principles that stand behind these values:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

From these 12 principles, as someone who already used the agile framework for quite some time, there are some points that I want to criticize based on my point of view:

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The principle talks about how agile methodology support changes considering the market, customer needs, and competitive threats wherever required, even late in the development.

The problem faced by the development team is there are times where the early requirements are not clear enough but keep changing throughout the time. There isn’t a way for the developer to be sure with his/her design or implementation since there is no certainty, which leads to confusion at the end of the sprint about the feature. That is why this principle needs to be applied carefully and needs further action. As in the Scrum framework, the requirement is closed for changes until the next sprint so that developer can deliver the product in time.

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Agile methodology breaks the product’s requirements into smaller components, but there are times when the delivery cycles are too short that even the smaller component may be too heavy to be worked on that short amount of time. So, ‘frequent’ in the principle must be adjusted depending on the context and feasibility.

Principle 4: Business people and developers must work together daily throughout the project.

This principle means that communication is a critical component, especially with iterative product delivery. A successful product will only happen if the business and technical sides communicate well to develop the product. Regular communication between business people and developers helps gain insight from both sides to ensure that the development runs well.

But what mostly happens in the field is the development team suddenly has questions that need immediate answers. But because there are only certain times that these questions can be asked directly, the development team needs to wait to ask the question until the next time they meet, which delays the development as well. This principle also needs further action to be applied, take example on Scrum Framework. Scrum has a product owner role, who connects both parties to prevent these things from happening.

Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This principle gets a bit of a critique because as much as it is great to have a face-to-face conversation to communicate, the development team still needs the track of the changes being made. Not involving everyone and not having a document to track the changes will confuse everyone in the future.

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

In conventional methodologies, where the team structure is a pyramid, the higher position makes key decisions for contributors in the lower part of the pyramid. But in agile methodology, self-organizing means that the decisions can be made as a group rather than by a single person or manager.

What can be added in this principle is the team cannot work alone. They also need support from the outside parties to clarify the requirements and do other things to prevent reworking the product's implementation.

Now let’s dive deeper into agile development methodology to understand it better.

Agile Development

In earlier days, software developers used the Waterfall Model to deliver projects but faced many issues. There were many difficulties around, including the changes and the time and cost required for that.

To deal with these drawbacks, the Agile Development Model was suggested. Its initial phase was designed only to help any software development project adapt to the client’s and market’s frequently changing requirements.

Basically, agile development breaks the task into smaller chunks, which will be delivered incrementally to help teams provide a quick and unpredictable response to the feedback they receive on their project. It creates opportunities to assess a project’s direction during the development cycle. Teams assess the project in regular meetings called sprints or iterations. There are some benefits of Agile Software Development you should definitely know:

Transparency

The agile process actively involves the client throughout the entire project. However, the client must be aware that they see a work in progress, not the final product.

2. Allows for Change

Because it delivers incrementally, Agile processes create an opportunity to reprioritize and refine the product backlog continually. These changes can be added to the next iteration.

3. Focuses on Business Value

The team has a better understanding of what is most important for the client’s business and can deliver features that give the most value to the business.

Agile values and principles are applied in many frameworks; all share similar philosophies, characteristics, and practices. One of the frameworks is Scrum, which I and my team use for software development for the PPL course this year.

Meet Scrum!

Scrum is a framework for agile development and one of the most widely used. This framework helps teams work together to deliver business values in a short time. The Scrum framework usually deals with projects where the requirements are likely to change or are mostly unknown initially.

As mentioned before, the Scrum framework is distinguished from the agile practices, with more concepts added. The Scrum framework is divided into three categories, which are Scrum roles, Scrum artifacts, and Scrum events. Let’s break it down one by one.

Scrum Roles

A scrum team has three specific roles that will participate and work together for scrum projects. The roles are:

Scrum Master, the keeper of the process. They are responsible for keeping the team moving forward, delivering the task on time, and running smoothly. The Scrum Master needs to understand Scrum and the project well enough, to mentor other roles and help the team optimize their delivery flow. As the facilitator-in-chief, the Scrum Master also needs to schedule Scrum events.
Product Owner, focus on the business things. They are the keeper of the requirements. The Product Owner builds the product backlog, focusing on ensuring that the development team delivers the most value to the business.
Development Team, we get things done. In Scrum, usually, the development team consists of 5–7 members. The team does the hands-on work of developing and testing the product. In the PPL project, the team consists of 5 members.

Scrum Artifacts

The Scrum framework has its own kind of artifacts to be made throughout the process. The artifacts are:

Product Backlog, a master list created by the Product Owner, filled with requirements detail for the project. Items in this list are called Product Backlog Item (PBI), which will be entries for Sprint Backlog in each sprint.
Sprint Backlog, a list of items selected by the Development Team to be implemented in each sprint. As mentioned before, the list entries are items from the Product Backlog.
Increment, the usable product that is the result of the sprint.

Scrum Events

Sprint Planning, the meeting to discuss and choose items from the Product Backlog to be implemented in the sprint. The Scrum Master leads the meeting.
Sprint, the time for the development team to work on the items chosen in sprint planning. The period is up to the team, but it usually takes around 2–3 weeks.
Daily Scrum or Stand up, the quick daily meeting to aligned everyone on the same page, voice any concerns, and plan for the next hours before the next daily scrum.
Sprint Review, a session at the end of the sprint to showcase the sprint's final result to the stakeholders and teams to get feedback.
Sprint Retrospective, another session at the end of the sprint to discuss what worked and what didn’t work in the sprint. The session's goal is to focus on what went well and needs to be improved for the next sprint.

How We Do It

As mentioned before, we use Scrum Framework in the PPL course project. The Development Team consists of 5 members, with a Product Owner and Scrum Master. We have Kak Khalis as our Scrum Master and Kak Tepe as Our Product Owner! The client is Pak Frans, from Altara Indonesia.

The project consists of 5 sprints, with 2 weeks duration for each sprint. In each sprint, we take several PBI from the product backlog to be implemented throughout the sprint. Same as the Scrum discussed above, we do the daily stand-up meeting twice a week and a sprint review.

Our team uses the GitLab board to list all of the works and their status to maintain progress.

That’s all! Now that you’ve learned about agile and scrum, I’m pretty sure you want to try to implement them with your team. I hope the Agile and Scrum work like a charm for you!