How We Implement Agile in Developing Document Builder
In software development, existing requirements may change or increase when the development process is already running. Therefore, we (Group A8) need a software development method that can support this, which is a fast method of adapting to changing requirements. The method is none other than Agile Software Development.
Agile’s Unique Manifestos
Agile Software Development is a group of software development methodologies that are based on the same principles or short-term system development that requires rapid adaptation from the developer to changes in any form.
In its application, agile helps the development team to produce products faster. This is because the delivery of the product to the client is not done in one stage at a time, but is done in a small and gradual manner (iteratively). Because of its iterative delivery, this method can adapt well to changing requirements.
What makes agile special is that it focuses on working product and collaboration between product owners, developers, and clients, unlike any other framework. Agile has its own unique manifestos:
Individuals and Interactions Over Processes and Tools
No matter how well-researched the process and high-tech your tools are, it’s the team you work with and the way you work together that determines success. Your team and their ability to communicate effectively and efficiently is more valuable than the processes they follow or the tools you use.
In the end, communicating is the key. This value is molt felt when we have our Daily Scrum Meeting. Although each one of us works on an individual task, we still remain to communicate keeping up about our progress to achieve our target as a team. If there is any idea on what we could implement better, we would discuss it directly. Everyone can give response and critique to the idea.
Working Software Over Comprehensive Documentation
Under the agile philosophy, getting software in the hands of customers is the highest priority. Instead of focusing on documentation, our team is focusing on what to implement next. Documentation can be avoided by writing clean code in our project.
Customer Collaboration Over Contract Negotiation
This agile philosophy highlights the importance of customer-centric product development practices over product-centric approaches. While contracts will always have their place in business, a list of the things we’re offering our clients is no replacement for actually communicating with them about what their needs and purposes are.
Before entering the development process, we had a little argument with our client regarding the “making the letter” flow. After several discussions, we finally met the endpoint of our problem, and now we have passed our first Sprint Review with more feedback on our work. This collaboration helps product people ensure they’re delivering effective, useful solutions to customers.
Responding to Change Over Following a Plan
In other words, the agile methodology lets a product team adjust its priorities and plans whenever doing so makes strategic sense. These teams do not get stuck in an outdated plan simply because they have committed to seeing it through.
Every Sprint Review, we meet with our product owner and clients. From the first one, we have been told that there are some changes we need to do regarding the interface of our application. Luckily, in sprint two, we manage to get resolve the changes.
In the next section below, we will talk about how we implement Scrum in detail.
Scrum Implementation
In PPL course, it is mandatory for us to implement Scrum methodology in developing our web app. Scrum is part of the Agile Manifesto. Essentially, Scrum has 2 main components, Scrum roles and Scrum methodology.
Our version of Scrum doesn’t vary much from ‘normal’ Scrum. There are roles in this process development like Clients who come from the Faculty of Law, University of Indonesia. Then, there is a Product Owner who is Lila Asfari, or Kak Lila as we usually call her and a Scrum Master who is Rahmania Astrid Mochtar or Kak Aci. They both are assistants in the PPL course. Lastly, there’s us, the Development Team. At this project, our five-people-team is serving as the development team, no matter the roles.
Scrum Process Flow
For the Scrum methodology, all of it starts with our product owner, where she provided us with product backlog items (PBI) that have been elaborated based on given requirements from clients. Each backlog item must be finished over the course of 5 sprints. 1 sprint takes around 2 weeks, which makes the total development time 10 weeks, or about 3 months.
There are mainly four activities we do in 1 sprint, there are, Sprint Planning, Daily Scrum Meeting, Sprint Review, and Sprint Retrospectives.
Sprint Planning
Before initiating the sprint, Sprint Planning must be conducted. During this process, the development team discusses with the Scrum Master on which backlogs items will be implemented during the current sprint. These backlogs will be broken down into a number of tasks, and then distributed to each member of the development team. Then, each member will pick a task fairly without weighing other teammates.
From what I have experienced, Sprint Planning meets the following principle in the Agile, that is “best architectures, requirements, and designs emerge from self-organizing teams”.
Daily Scrum Meeting
During the sprint, each member must implement the tasks that they’re responsible for. So far, my team has implemented these tasks considerably well. In these sprints, there are usually Daily Scrum Meetings where each member gives updates (progress, blockers, and to-do) about the tasks they’re currently working on.
For my team, there are only 2 Daily Scrum Meetings in one week due to time limitations and other responsibilities. These meetings only take 15 minutes each and are always held at lunchtime on Monday and Wednesday. So it is 4 in a total of our one sprint.
These meetings are planned to achieve “face-to-face conversation is the best form of communication” principle of Agile.
Sprint Review
After 2 weeks of sprint, there will be a working product that can be demoed during the Sprint Review, in which the clients from FH UI will evaluate and decide if it's their meet the standard (acceptance criteria) or not. Also, at this time, we can discuss any changes in the requirements from the clients that should we know.
Sprint Review is targeted to follow one of the principles of Agile, which is “customer satisfaction by early and continuous delivery of valuable software”.
We just held our first Sprint Review last week. It gladly went well, phew! We managed to satisfy Mas Aligar (a representative from our clients), as it met his expectations. This resulted in the acceptance of all the PBIs that we took for our sprint one. Although the product managed to cross out all the acceptance criteria in each PBI, we got some requirement changes for the UI purpose.
Before the Sprint Review, our clients agreed with the mockup shown below.
But, when the sprint is done, he asked us to remove the preview button and change it to the delete button instead. He also asked to change the color of the button because he thought the color red really isn’t suitable enough for “submit” button. I couldn’t agree more. So, after much consideration, we have this compilation of bugs to fix for the next sprint.
This requirement changes result in some additional tasks on our sprint two. Luckily, we’ve managed to handle the situation and came up with the new design for the button.
Sprint Retrospective
Finally, comes the Sprint Retrospective. The last activity to end the Sprint. It applies “regularly, the team reflects on how to become more effective, and adjusts accordingly” principle of Agile.
The Sprint Retrospective is supposed to be held on the same day after we have a Sprint Review. But in our case, we didn’t have the time to do so and decided to have Sprint Retrospective the day after. We use metroretro.io for our tools in executing a Sprint Retrospective.
During this time, we reflect with the Scrum Master about what we‘ve done right and what we can improve in the next sprint regarding the recent 2-weeks-sprint. For the first Sprint Retrospective we’ve had, each member has different problems in something that reflects on different things and we’re trying to fix that by motivating each other. But, as a team, (alhamdulillah) everything went fine and no one has any hard feelings on others.
After the Sprint Retrospective is finished, we repeat the same cycle by going back to the sprint planning phase, and so on.
Now that we all know about Scrum events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
Based on the Scrum Guide that developed and sustained by Ken Schwaber and Jeff Sutherland, there are three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Transparency is when significant aspects of the process must be visible to those responsible for the outcome. While inspection is applied frequently to inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. The process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
From each explanation of Scrum event, the key to inspect and adapt meeting goes to Daily Scrum. I couldn't agree more with that statement. Based on my experiences doing Daily Scrums several times, Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge.
Agile sounds all nice and perfect, doesn’t it? But you will never know the struggle of implementing the real agile development until you’re in one. Requirement changes suck, but hey, that’s the fun of agile development, right?🤪
Just remember, each team with its own unique product and composition will have a different way that works for them in implementing Agile and Scrum. For my team, implementing Scrum in our work has been giving us more motivation in doing our tasks. The presence of daily activities and a short time sprint keep us more active in completing the project.
