How My Team Implemented Agile Software Development Using Scrum
So a long story short, I was taking one of the courses at my university, especially majoring in computer science, namely software projects (Proyek Perangkat Lunak). As the name implies, in this course I was given the task of creating a team of five people and making software with predetermined topics. My team got the topic of creating mobile applications that are involved in academia, especially in the field of law. The name of the application is Pantau Peradilanmu. Well, in this article I will briefly explain how my team implemented agile software development using Scrum.
What is Agile?
Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.
The authors of the Agile Manifesto chose “Agile” as the label for this whole idea because that word represented the adaptiveness and response to change which was so important to their approach.
It’s really about thinking through how you can understand what’s going on in the environment that you’re in today, identify what uncertainty you’re facing, and figure out how you can adapt to that as you go along.
What is Agile Software Development?
Agile software development is more than frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).
Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions, and sprints.
Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.
One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.
Scrum
Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments. That is when the framework is used properly. Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team’s context.
Scrum Values
Teams following scrum are expected to learn and explore the following values:
Commitment
Team members personally commit to achieving team goals
Courage
Team members do the right thing and work on tough problems.
Focus
Concentrate on the work identified for the sprint and the goals of the team.
Openness
Team members and stakeholders are open about all the work and the challenges the team encounters.
Respect
Team members respect each other to be capable and independent.
Scrum Mindset
When you’re trying to introduce Agile Project Development into your company or to a new team, it’s important that you know how to make it work. More than the terms, practices, meetings, and user stories, the Scrum Mindset keeps the team on point and helps them self-manage even if they aren’t too familiar with the terms used in Scrum.
How My Team implements Scrum Mindset?
Look at failure as a learning opportunity
In project work, I myself have experienced a few failures in the first sprint. Where I failed in implementing testing using flutter. However, this did not make my enthusiasm decrease, but I took a lesson from my failure so that on the second sprint I was successful in implementing the test. Yay! 😄
Welcome different perspectives and diversity of thought
In working on the project, of course, there were some differences of opinion in my team. However, this was not a problem for my team, because we were together discussing these differences of opinion in order to find the best solution.
Transparent
In project work, transparency is also quite crucial. When I or my team experience difficulties or other problems, honesty is needed so that there are no bigger problems in the future. I myself also often encounter difficulties and what I do is be honest with my friends and ask for help so that the problem can be dealt with quickly.
Knowledge sharing is done willingly and freely
During project work, my team is very open to helping each other and sharing knowledge. For example, in my team, there is one person who is more mature in working on flutter and firebase-based projects. So, at the beginning of the work, he shared some of his knowledge with other friends including me by holding a crash course.
Want and need to collaborate and communicate
In project work, collaboration and good communication are needed not only with the developer team but also with the Scrum master and product owner. With good collaboration and communication between the developer team, the scrum master, and the product owner, it will make it easier to work on projects. This has been implemented in my team because I have a team with Scrum masters and product owners who have good communication skills and are willing to collaborate.
Having fun
And most importantly, my team doesn’t forget to have fun working on projects. While working on projects, we often joke around while listening to fun songs so that my team is still in a happy state. We also often play together when we finish working on project work. Don’t forget to have fun! 💃
How My Team implements Scrum?
Roles
The distribution of the Roles / Actor Scrum in the PPL 2021 course is as follows:
- Product Owner: The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. (Teaching assistant).
- Scrum Master: The Scrum Master is responsible for ensuring Scrum is understood and enacted. (Teaching assistant).
- Dev Team: The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. (Which is My Team :D).
Artifacts
- Product Backlog: The product backlog is an ordered list of all the possible changes that could be made to the product. Items on the product backlog are options, not commitments in that just because they exist on the Product Backlog does not guarantee they will be delivered. The Product Owner maintains the product backlog on an ongoing basis including its content, availability, and ordering.
- Sprint Backlog: The Sprint Backlog is the collection of product backlog items selected for delivery in the Sprint, and if the team identifies tasks, the tasks necessary to deliver those product backlog items and achieve the Sprint Goal.
- Increment: The increment is the collection of the Product Backlog Items that meet the team’s Definition of Done by the end of the Sprint. The Product Owner may decide to release the increment or build upon it in future Sprints.
- Definition of Done: The definition of done is a team’s shared agreement on the criteria that a Product Backlog Item must meet before it is considered done.
Events
Number of Sprint: 5, each sprint time: 2 weeks
- Initiation Phase: Making a mock-up and set up the environment.
- Sprint Planning Phase: Determine the point estimate/weight of each user story, break down user stories into smaller Tasks, the product owner sets a sprint goal for an upcoming sprint run, select the Sprint Backlog related to the sprint goal.
- Sprint Phase (Implementation): Every implementation/code of the user story that is used must put in the repository (GitLab), determine the deliverables from each user story, daily standup meetings are held at least 2 times/week (4 times in 1 sprint, including with Sprint Planning and Sprint Review/Retrospective), update and maintain the backlog if needed
- Sprint Review and Sprint Retrospective Phase: Time Sprint Review (assessing software products) and Sprint Retrospective (assessing team) at the end of the sprint as per the schedule in the Course Guide. For odd sprints, the time and place of the sprint review are determined by Scrum Team. For even sprints, the time and place of the sprint review correspond to the class schedule. Make sure to bring the WORKING SOFTWARE (Releasable) during the Sprint Review. Sprint Review Meeting in front of lecturers, topic proposers, and teaching assistants. Approval and Acceptance of the Product Owner. Sprint Retrospective, conducted on the same day after the Sprint Review that discusses lessons learned and peer review.
- My Team repeats phase 2–4 until the desired outcome of the product has been met.
That’s all I can share regarding how my team implemented agile software development using Scrum. Thank you for reading this article. I hope you like it.
References
- Panduan Scrum PPL 2021
