A Sprint In a Life using Agile at Yuk Recycle
“We are uncovering better ways of developing
software by doing it and helping others do it”- Agile Software Development website
Hi! My name is Azka and here is an implementation of Agile at Yuk Recycle (and it supposed to be two sprint in a life, but you know what I meant).
Yuk Recycle is a project for a class I’m taking and in it we implement agile software development approach using scrum implementation. This project is provided by Universitas Indonesia while the topic is provided by Gojek.
Agile software development is an approach to software development, and a very flexible one in its kind. To understand what agile actually is, let’s take a look at The Manifesto for Agile Software Development:
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 point of agile software development, as of what I understand, is that we don’t want to pay too much attention to the requirement at the start of the project as there will always be a requirement changes. In agile, both of the requirements and the solution will evolve through collaborative effort of self-organizing and cross-functional team between customers and end-users.
By doing this, the product can evolve more quickly and satisfy the need of the market and consumer much more quickly when we compare it with waterfall where it might always produce a better designed products, but a the cost moving so slowly.
With agile, we could develop, deliver, and sustain complex products much easier and faster. The implementation of agile can take a lot of shape, such as Kanban, Extreme Programming, etc., but here at Yuk Recycle, we uses Scrum.
What On Earth is Scrum?
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
Scrum by all means is a framework. It is an implementation of Agile and the most popular one at that. The detailed implementation is left to the scrum team because the team will know best how to solve the problem they have. But even if the implementation is left to the dev team, they still have fixed roles, responsibilities and meetings.
Scrum Implementation
The implementation of those roles and responsibilities at Yuk Recycle is the following.
Product Owner
Product Owner (PO) is the man who proposes the topic of the project. PO will have the responsibility to manage the product backlog. In this project, the PO is a man from Gojek. He is also the one single stake holder that will accept which work is done and which one should be redone.
Scrum Master
Scrum Master is responsible for supporting and promoting the scrum team. Scrum master is also the one who handles the interaction with those whose outside the scrum team. In this project, the one who holds the responsibility to be a scrum master is from the teaching assistant team.
Dev Team (or Scrum Team)
The one who do the dirty works. These guys are the one who writes the codes and deliver potentially releasable “done” product at the end of each sprint. A good scrum team consists of 3 to 9 people. In this project, there is six people including me, which exclude the PO and scrum master.
The implementation of meetings using scrum framework can still be done properly as written in the Scrum Guide, even while taking account that we are still a university student. In this project, because of limited time frame, there will only be six sprint. At the time of writing this blog, we’ve been doing two sprints. The details of the sprint events will be the following:
Sprint Planning
Sprint planning occurs at the start of the sprint. For the past two sprints, Each sprint planning taking about 2–3 hours, consisting of estimation, breakdown task, and task taking. For each User Stories (A.K.A backlog) we will estimate their weigh using Fibonacci Point. After that, each User Story (US) will be broken down into smaller tasks to make it easier to work on. Then we will start choosing which task we’ll be working on until the next daily scrum meeting based on our estimation at the start of the sprint planning and our own capability.
Sprint
The sprint for this project will be six sprint long and two weeks each. By the end of each sprint, a scrum team supposed to be able to produce a deliverables, or MVP. In this project the MVP supposed to be available starting the end of third sprint.
Daily Scrum Meeting
Daily scum meeting, or daily stand up , in this project will be executed twice a week. So it’ll be 4 times a sprint. For each meeting, there will be scrum board update, task taking and progress report.
Sprint Review
Evaluates dev team performance and the acceptance criteria of each backlog that has been worked on for the last sprint. The one who accepts which backlog is finished or not is the Product Owner.
Sprint retrospective
Consists of evaluation and searching for improvement strategy. In this event it will also be discussed about lessons learned and peer review will be conducted.
Progress For The Last Two Sprints
The last two sprints happens so quickly. And full of road bumps.
In the first sprint, most of the things went pretty well. The most noticeable hiccup is that we’re still have this learning curve when trying to develop a mobile app and a backend using software stack we have never worked on before. Another road bumps in our was that in the first sprint I decided to focused mainly on the CI/CD part and infrastructure stuff, which apparently happens to be a bad decision. This also holds us back because this means we have one less programmer working on the real thing. But we still managed to accomplished two backlogs thanks to our skill full development team (not me).
In the second sprint, things take a turn for the worse. In this sprint, because we had so many backlog leftovers from the last sprint. The good news is that I’ve finished most of the devops stuff at the first sprint and now I can started to actually coding. The bad news is I got a late start and everyone else is already know what to do given some of the problems we are facing. To add insult to injury, we still haven’t decided which architecture we are going to use for our mobile app for the first week of the sprint. So basically, the second sprint was hell for us. But things still works out nice. We do better than the last sprint and the only cause of our suffering is because of the tech debt we had to pay in this sprint. And it wasn’t that bad as we finished at least one (or may be three?) backlog successfully even though we haven’t merge our branches to staging branch.
So how about the Agile?
Even though the development experience wasn’t that great, the manifestos of agile software development pretty much accomplished. Our team can work and interacting with each other without any problem. We work more on delivering working software rather than searching for the right architecture. We also collaborating with our PO to solve some engineering problem. And the most of all we are capable of responding to change when our plan seems to be not good enough.
In the end, we are still a very young team. We have so much to learn, and we need to adapt fast. This is a must for us, so we can grow to be better, as a programmer, and as a human.
