The Agile Manifesto & Scrum
Agile is a common word that can be seen and used in our everyday lives. Agile itself means the ability to create or respond to change, move quickly and easily. However, what differentiates this “Agile” from the common agile? The “Agile” we’re talking about is the methodology that is used in software development, namely Agile Software Development. The “Agile” here is the approach that a developer can do in software development that emphasizes on team collaboration, continual planning, incremental delivery, and continual learning. The Manifesto of Agile Software Development comes with its key values and principles, as below:
The Key Values of Agile
- 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 12 Principles of Agile & The Application of It in Our Team
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. We at BisaGo stress on delivering the software with satisfaction and on time. We work with a commitment to reach the Scrum Team’s goals for each Sprint, which can be seen in the Profile Page feature from our latest sprint which was not available before.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Requirement changes are something we can expect in the late development stages. As I’m writing this, we currently have not gotten any requirement changes, but if we do, we will also have to embrace these changes to deliver satisfying software. We always welcome feedback so we can create software that will satisfy the customer, for example, our Product Owner asked us to rearrange the orders of the SideBar, which we would then immediately do to reach satisfaction.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. This emphasizes the first principle with the focus on continuous delivery, and as I’ve stated before, we at BisaGo work with commitment for each sprint to deliver continuously.
- Business people and developers must work together daily throughout the project. This also applies to our team’s experience, as if there are certain things that remain unclear, we would immediately contact our Scrum Master or Product Owner to straighten things out. We would also have a fixed work schedule where we would gather and work on the development together to help each other out.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Our Scrum Team always motivates and supports each other to work properly and we also have trust in each other’s skills to do complete their tasks appropriately.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. During the pandemic, it is very difficult to do a direct face-to-face conversation, however, we work around it by using video call platforms such as Zoom, Google Meet, and Discord to communicate with each other.
- Working software is the primary measure of progress. Every Sprint, our team aims to be able to show a part of the working software, and it will slowly but surely, accumulate to a fully working software.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Our Scrum Team focuses on working consistently so we can minimize the possibility of burning out from too much work and not overextend ourselves because it can lead to poor quality software.
- Continuous attention to technical excellence and good design enhances agility. Don’t neglect good design for speed, because, in truth, the key to speed is by having high-quality designs. Our team also expects each other to deliver the highest quality code they are capable of making.
- Simplicity — the art of maximizing the amount of work not done — is essential. Simplicity can sometimes be considered as the best choice, as this is also applicable in Agile Development. Keeping things simple will also keep our code easy to maintain.
- The best architectures, requirements, and designs emerge from self-organizing teams. We give everyone in our team the right to act independently so we can adapt much quicker and be much more “agile”.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. This principle is a combination of the previous principles. Our Scrum Team uses the Sprint Retrospective period to reflect on what we’ve done, what we can do better, and what needs to be stopped so we can improve both as individuals and as a team. An essential thing that we’ve come to terms with to stop doing is procrastinating, which would lead to long nights near the deadline. Another thing that we’ve agreed to maintain is our work pace, as our work pace from the past Sprint has been quite satisfactory according to our Scrum Master.
SCRUM
Scrum is the most widely-used framework under Agile which focuses on reaching a well-defined goal with the team using 2–4 weeks of iterative progress called Sprints. Scrum integrates three roles, three artifacts, five events, and five values.
Scrum Roles
- Product Owner: The person who is responsible for managing the product backlog to avoid any misunderstandings with the development team and increasing the worth of the product created by the development team.
- Scrum Master: The person who is responsible for supporting the Scrum by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master also helps maximize the interactions in the Scrum Team.
- Development Team: The people who are responsible for determining the method and doing the work given by the Product Owner. They are designed and authorized to arrange and manage their own work.
Scrum Artifacts
- Product Backlog: A rundown that involves all of the things required in the product which has entries that are ordered by their priorities, called user stories. The product backlog will accumulate steadily following the changes in the product.
- Sprint Backlog: The subset of product backlog where it specifies the user stories picked for each sprint.
- Product Increment: The sum of all product backlog items completed during a sprint
Scrum Events
- Sprint: Sprint is the event itself where the Scrum team works on the project and all of the other events that happen during that time period. The duration of each sprint is usually 2–4 weeks.
- Sprint Planning: The event where the Product Owner, Scrum Master, and Development Team discuss which Product Backlog Items (PBI’s) will be included in Sprint. They usually do this by firstly estimating the weight of each user story.
- Daily Scrum: Also known as the Daily Stand Up Meeting, is the event that usually lasts for 15 minutes, used for the Development Team to check in on their progress towards achieving the sprint goal.
- Sprint Review: The event that takes place after a Sprint or at the end of it. Its focus is to show the tasks done during the sprint by presenting the working software. A Sprint is considered to be successful if the Product Owner accepts the result of the Sprint after checking it.
- Sprint Retrospective: After the Sprint Review, the Development Team can use this event to assess and reflect on the team’s performance during the past Sprint. They share what they’ve done and classified them based on the things that they should maintain, start doing, and stop doing.
My Experience
I’m currently enrolling in the PPL Course and am a part of the BisaGo Team. As I’m writing this article, I’m in my second Sprint, and my team and I have been through 1 full sprint cycle. Here are the implementations of Scrum that we’ve done.
Sprint Planning
During the start of the sprint, we did the sprint planning. Our Product Owner has provided the Product Backlog that has the PBI’s for BisaGo.
We would then hold the Sprint Planning with our Scrum Master where we used scrumvee.com to estimate the weight of the user stories.
We would then pick the user stories for that sprint with their weights in mind. During our first Sprint, we encountered some problems, such as the back end of the application that couldn't work properly because of reasons outside of our control, therefore, we chose to work on the front end for the first Sprint. Luckily, Thanks to the guidance from our Scrum Master, We were able to identify the causes of the errors in the back end and we’ve decided to work on it in our second Sprint.
Daily Scrum
During the Sprints, we had Daily Scrums to attend to. These meetings were held twice every week, in our case, every Tuesday and Friday evening. During the Daily Scrum, we would report to the Scrum Master about what we’ve learned, what we’ve done, and what are we planning to do next.
Sprint Review
At the end of our first Sprint, there was a Sprint Review that involved the Development Team, Scrum Master, Product Owner, and our lecturer. There, we presented the result of our first sprint which were the “Tentang Disabilitas Page” and Navigation Enhancement where we added a button in the drawer that redirects to the “Tentang Disabilitas Page”. It’s also important to mention that before the Sprint Review, we submitted the application to the Product Owner for UAT(User Acceptance Testing), which would then deemed it to be acceptable.
Sprint Retrospective
Lastly, after the Sprint Review, we held a meeting outside the class schedule where we assessed the team’s performance and specified what we should maintain, start doing, and stop doing.
References:
