Let's Get to Know Agile: The Super Magical Power in Software Development

Origin

Once upon a time, there was a time when many of PC industries faced crises. It was the early 90's when everyone in the industry realized that the time between a validated business need and an actual application in production was about more than 3 years. For instance, the Space Shuttle program, which operationally launched in 1982, used information and processing technologies from the 1960. Off course, that problem led many projects developed ended up rejected or cancelled because not relevant anyway to current needs.

So, to solve the problem, some professionals in software engineering led a meeting in Utah in early 2001. From that meeting, they finally discovered a "super magical power" called Agile and its "spell book" called Agile Manifesto.

Manifesto

There are 4 values and 12 principles in Agile Manifesto.

Values

1. Individuals and Interactions Over Processes and Tools – I believe my team has practiced this value because we always try to interact with each other. Moreover, we use Discord to interact.
2. Working Software Over Comprehensive Documentation – I believe my team has practiced this value because we always take a realistic number for PBIs we take to make sure we can deliver a working software. We also don't waste too much time in creating comprehensive documentation because we already have swagger.
3. Customer Collaboration Over Contract Negotiation – I believe my team has practiced this value because we always discuss with the client/customer whenever there is some changes that we should do, such as the change of our submission format in our system.
4. Responding to Change Over Following a Plan – I believe my team has practiced this value because we respond to change especially if it comes from the client. For example, we respond to the client request to change the score scale and the scoring process.

Principles

1. Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases. For example, while developing my PPL project, the development time and the number of PBIs we take are always nearly the same, which is 2 weeks with 5 PBIs average. Starting from the 3rd sprint, we also tested the working software earlier with our Product Owner before going for a sprint review. So, I think the customer will be happier because of the regular intervals and the early .
2. Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes. For example, while doing the sprint review, there are sometimes one or two feedbacks from the client such as a revision of the score scale (from 0-10 to 0-100) and many more. We always accommodate changing requirements because at the end, the one who will use this app is the client, so we should ensure that all of our works match with the client needs,
3. Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software. I think this principle's example is quite the same as the first principle's. As I have mentioned before, in this project, we always delivered the working software exactly every 2 weeks. So, I think we have already followed this principles.
4. Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned. For example, in the last sprint planning, we discussed with the Product Owner and the client about features which had to be done because we knew that we couldn't carry out all PBIs left due to limited time. So, my dev team discussed with the PO, client, and SM to get the best decision for that sprint.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams. I truly believe in this principle because when every member in my team supports and trusts each other, we will probably get a better result. For example, every time we know if there is someone who still confused and incomplete doing his task, we always try to offer him a help and really motivate and take a big trust in him that he can finish his work.
6. Enable face-to-face interactions – Communication is more successful when development teams are co-located. However, in this pandemic situation, my team really experienced difficulties when doing a good communication. Therefore, starting from the 3rd sprint, we built a Discord channel to communicate each other. We can share our screen and coordinate with other team members like we did a face-to-face interaction. And yes, we always got better results since then.
7. Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress. For example, we experienced taking so many PBIs at the first sprint. Yet, at the end of the sprint, we couldn't finish our work although we did many progress. Since then, we didn't take too many PBIs again and always ensure that we make the progress into a working software.
8. Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release. I think we can use the same example from the first principle. We always had a consistent development pace because we always delivered the PBIs every 2 weeks and always took only 5 PBIs.
9. Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change. For example, my team always seek for any case that might be forgotten. After realizing that, then we did some changes to fix and accommodate the case.
10. Simplicity – Develop just enough to get the job done for right now. I think we can use the same example from the 7th principle. We always develop just enough to get the job done for right now because it's more important to have a working software.
11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products. I think this is the best principle to illustrate my team because we don't have any leader in my team. All members are self-organizing people and we really trust each other.
12. Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently. That's why my team always did a sprint retrospective because it's quite important to have reflection. Because of that, we invented a better solution to coordinate and working together as a team (for instance, we created a personal deadline for every PBIs we take).

Agile

To make you understand clearly about this methodology, you might should know what is Agile. From the manifesto above, we can conclude that:

AGILE methodology is a practice that promotes continuous iteration of development and testing throughout the software development life cycle of the project.

https://www.guru99.com/agile-scrum-extreme-testing.html

You can see the default flow of Agile from image below

Scrum

After we talked about Agile, we should know a "tool" or a framework of software engineering that implement Agile. One of them is called Scrum. Scrum is created by Ken Schwaber and Jeff Sutherland (both are also the creators of the Agile Manifesto) in 1990 to manage work on complex and adaptive products or problems. Scrum is an agile framework and a way to manage software development's complex and adaptive projects or problems.

Now, to have a clear understanding about Scrum, let's see one of my website project called Sistem Informasi Penilaian dan Evaluasi Praktikum, a website to help FISIP (Faculty of Social and Political Sciences) UI's students and lecturers to submit and score practical work's (internship) reports. This project is being developed by my team, MK-PPL using Scrum as the framework.

Scrum Roles

There are 3 kinds of specific scrum roles. They are Scrum Master, Development Team, and Product Owner. Together these are known as the Scrum Team.

Product Owner

The Product Owner main job to connecting the clients and the scrum team. The product owner will gather all the requirements from clients. After that, they will divide them into some list of features and backlogs, so that the developer team could understand what they should do. Besides that, they are also responsible for identifying acceptance criteria and make sure which features fulfills the requirements and are ready to show to the clients at the end of the sprint.

The Product Owner for our project, Sistem Informasi Penilaian & Evaluasi Praktikum, is Faizah Afifah. We (the dev team) call her Fio, she is a final-year information system student in Fasilkom UI. At the beginning, she created a list of backlogs called PBI. Here is some examples of the PBIs for authentication feature she had made.

She also created a full document of user requirements called PRD. If you want to see her PRD, you can visit this link:

https://drive.google.com/file/d/1JEDNqomAsLfOg_K8oNYGPraznjV7VxWa/view

Scrum Master

The Scrum Master main goal is to monitor and control the developer team to keep in track with their works and make sure that all scrum teams will implement scrum framework correctly. They also help the product group learn and apply Scrum in the project development. The Scrum Master is the one who usually conduct a scrum events: scrum meeting, sprint planning, sprint retrospective, and sprint review.

The Scrum Master for our project, Sistem Informasi Penilaian & Evaluasi Praktikum, is Yumna Pratista Tasftaftian. We (the dev team) call him Yumna, he is a final-year computer science student in Fasilkom UI. He helps our scrum team to achieve the goals for every sprints.

Development Team

A Development Team is a group of people who are responsible for building the project together and deliver the requested product requirements. Usually it consist of several sub-roles such as back-end engineer, front-end engineer, QA engineer, UI/UX engineer, DevOps engineer, and many more.

The Development Team in our team, MK-PPL team, consists of 5 people

• Muhammad Ardivan Satrio Nugroho – Back-end and DevOps engineer
• Muhammad Irfan Amrullah – Front-end engineer
• Muhammad Nadhirsyah Indra – Front-end engineer
• Razaqa Dhafin Haffiyan – Back-end engineer
• Revan Ragha Andhito – Front-end and UI/UX engineer

Scrum Events

There are 5 kinds of specific scrum events. They are Sprint Planning, Daily Scrum Planning, Sprint Review, Sprint Retrospective, and Sprint itself.

Sprint Planning

This is the event that kick starts each Sprint and is where the Product Owner and Development team discuss which Product Backlog Items (PBIs) will be included in Sprint. While the Product Owner has the right to prioritize each PBI for potential inclusion in the Sprint, the Development team are encouraged to respond, raise issues and push back where necessary. The Development Team then forecasts how many PBIs they can deliver in the Sprint, given their knowledge of velocity, resources and any factors which could influence the time and resources they have available.

To make it more clear, I will give some examples of sprint planning based on my experience in my first sprint planning. At my first sprint planning, all the scrum team (Development team, Scrum Master [Yumna], and Product Owner [Fio]) were together to discuss what features are going to be taken in the first sprint. We all discussed which features were prioritized and their level of hardness. After some great discussions, we decided to take these PBIs:

We chose to take login PBI because we thought that authentication should be the first to built because it will dependent to all features. Besides that, we also took the other two PBIs (below the authentication) because it was highly prioritized by the Product Owner. Here is the picture when we designed our first sprint planning.

Sprint

The Sprint is an event in itself that contains all the work and all the other events that happen during the time boxed period of development. During my first sprint, I took all the authentication PBIs to be my responsibility. I work together with Nadhirsyah and Irfan because they did the front-end task for the authentication PBIs, while I was working on the back-end. The other two members: Revan and Ardivan were working for the other two PBIs. I had to work quickly because in my project, the sprint duration is only about 2 weeks. Sometimes we also worked together (in a same place) when we were doing our PBIs to make sure everything integrated completely, like the picture below.

Daily Scrum Meeting

Scrum seeks to efficiently use your time and resources and the Daily Scrum event is no exception. The Daily Scrum is time boxed to 15 minutes. Standing up is not compulsory. However, many teams find this a useful technique to keep the meeting short and to the point. The Daily Scrum is an opportunity for the Development Team to check in, assess progress towards achieving the Sprint Goal and to review and plan their activities for the next 24 hours. Yet, in my team, we only held a sprint in every Tuesday and Friday due to limited time. For my first daily scrum meeting, I told every progress that I had done, such as complete SSO login feature for users. Below is our first daily scrum meeting.

Sprint Review

Look again at the above principle from the Agile Manifesto — “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” That principle alone sums up the reason behind our next two meetings, the Sprint Review and the Sprint Retrospective. A Sprint Review usually takes place on the last day of the Sprint and allows you the opportunity to show the “done” Increment to stakeholders (customers, management and anyone else considered relevant and interested). As well as demonstrating working features produced during the Sprint, you’re also after useful feedback that can be incorporated the Product Backlog that may help guide the work for future sprints.

During a sprint review, the Scrum Master invited all people who were involved in this project. There are Mr. Budi (representation of the Faculty of Social and Politics Science, University of Indonesia), Mrs. Heninggar (the lecturer of Software Engineering course), Fio (Product Owner), and the Development Team. In my first sprint review, my team presented all PBIs that we had done, such as authentication feature, list of submissions feature, and many more. We got some feed backs from Mr. Budi and Mrs. Heninggar and we asked some questions to make sure the feature clear. Yet, we still have some PBIs which had not completed. So, it was the job of the Product Owner to decide which were done. Unfortunately, I can't find the picture of my first sprint review. So, here is the picture of our online sprint review due to covid-19 outbreak.

Sprint Retrospective

The final meeting in the Sprint is the Sprint Retrospective. This is when the Scrum team reviews what could be improved for future Sprints and how they should do it. The ethos of Scrum dictates that no matter how good the Scrum team is, there will always be opportunity to improve and the Sprint Retrospective gives the team a dedicated time in which to identify, discuss and plan this. The whole Scrum Team should take part including the Development Team, the Scrum Master and the Product Owner. The meeting should be a collaborative effort, just like the entire Scrum and Agile process.

Scrum Master invited all the development team and gave us some sticky notes to fill. We should write things that were already good and not. And then, we gathered all of them and find the solutions for those who were still bad. At my first sprint retrospective, I proposed the implementation of code freeze in our sprint far before sprint review, so that the development team won't finish their tasks in the same day as sprint review is held. Below is the picture of our first retrospective's sticky notes.

That's all from me. I hope my article can be useful for you to understand more about Agile. Thanks for reading!