Agile, Scrum, and How We At pepeel Team Use It
An Introduction to Agile
Individuals and Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a planThat is to say, the items on the left are valued more than the items on the right.
This manifesto is published by seventeen software developers that met at a resort in Snowbird, Utah in 2001. Arising from mutual frustration over what the perceive as the failure of the software development project management paradigms at the time, such as the waterfall method. A rigid paradigm, a stickler of the plan, and uncaring of changes, those methods often leads to failure in software development, where the majority of projects fail without even completing half of the requirements.
In response, Agile is born. Agile does not provide us with concrete methods. Instead, Agile provides approaches, values and principles we stand for, such as delivering product in increments, instead of all at once, welcome changing requirements, et cetera. In Agile, we evaluate our products constantly, changing requirements to match feedback, and respond to those changes quickly. Hopefully, with that approach, we can deliver products that match our customer expectations.
Scrum and How We Use It At pepeel Team
Scrum is one of the frameworks derived from Agile. In Scrum, a team consists of a Product Owner (represented by Kak Lila on our team), who is responsible for determining the requirements, managing it, and evaluate if the team works is per the requirements or not, a Scrum Master (represented by Kak Aci), who leads and guide the team to use Scrum correctly, and the Development Team (consists of Firman, Irene, Asti, Aab, and me, Cahya), who develops and turn the requirement into working software.
Following the rule given by PPL 2020, we work in 2-weeks long Sprint (the iteration or increments as mention in Agile above). During a Sprint, there are some events that we must do, such as:
- Sprint Planning
During sprint planning, we determine what is the goal of the sprint. We also choose the Product Backlog Items that we will work on in the sprint, break it down into simple tasks, and assigning each task to a member of the development team . Product Backlog Items are requirements that are gathered into Product Backlog by the Product Owner.
It’s kind of hard. Different from Sprint Planning I participate in during internships, here at PPL we also must consider other workloads such us courses homework and organization activities. However, I feel that during our sprint planning, we managed to balance our project tasks assignment with our other activities such that we should still able to reach our sprint goal without compromising our other activities.
- Sprint Implementation and Daily Stand Up
Every day during that 2-weeks period, we work on completing our tasks. Also, twice a week, we hold a Daily Stand Up (well, not really a “daily” isn’t it?), a short 15 to 30 minutes meeting where we report on what we’ve been doing, what we will be doing next, and obstacles we encountered during the sprint.
Speaking from my former experiences in internships, stand-up meetings are the most important part of the sprint and should be held every day. With it, we can evaluate if we are falling behind or ahead of the schedule, knows our teammate's progress, and clear obstacles, especially those caused by tasks dependencies. However, due to limitations stated in Sprint Planning, we can only hold it twice a week. - Sprint Review and Retrospective
On Sprint Review, we do a demo to the product owner of what we have achieved during the sprint and evaluating if the resulting product is in accordance with the requirements or not. Both partner and lecturer give advice and evaluation of our work. They will give us a rundown of what the like, what the didn’t understand yet about our work, and whether there is something we can improve for the next sprint or if a feature is liked by them.
In Sprint Retrospective, each member of the team write down what went well and went wrong in the sprint. Those feedbacks are gathered, appreciate the good ones, and discussing what should be we should start doing, and what we should stop doing. We also discuss actions we should do, so our next sprint will go more smoothly and better.
Conclusion
As we already go through four sprints, I already feel some application of the scrum values. For example, in Sprint Planning, we have to be committed to issues that we take and will do. We also have to have courage in speaking up and express our opinions during planning. In Daily Stand Up, we are open about our progress. During implementation, we have to be focused on our work. And lastly, during Sprint Retrospective, we point out the good and bad in our team in a respectful way. Adhering to those values, our teamwork is improved and as a result, developing our software became easier.
Implementing Agile and Scrum is not easy, but with the right application and the right people, it will benefit your team highly.
