Agile — I Am (Not Just) Speed
When you think about it, the movie characters that could move at the speed of sound isn’t just “fast”, they’re also Agile.
What is Agile?
Agile is a term you’ve probably heard at least once if you dabble in software development that means what you think it means, probably. Agile is both a principle and characteristic. Simply put, to be agile is to be able to adapt to changes quickly and effectively.
In software development, Agile is a principle in which the development process is done iteratively while quickly delivering small increments of usable product to the client. This is done to, of course, adapt to the everchanging requirement that either the client or the development team may only realize in the middle of the process.
Agile gives the development team and the client more leeway and flexibility into making the perfect fit of the product. A product’s requirements may be unclear to even the client themselves, or the requirements may be volatile depending on the market at the time. Such projects benefit greatly from the Agile process.
Manifesto & Principle
Agile development follows a popular manifesto which states 4 things:
Individuals and interactions over processes and tools
This means that Agile values the people and the team’s improvement and skills more than better processes and tools. Agile looks more towards resourceful than a robotic team.
Working software over comprehensive documentation
This means the Agile values shoddy but plenty deliverables more than pristine one-offs that can’t be presented yet. Agile looks more towards incremental update on the product.
Customer collaboration over contract negotiation
This means that Agile values the client involvement throughout the project more than only at the beginning. Agile looks more towards developing together with the client.
Responding to change over following a plan
This means that Agile values flexibility more than the ability to stick to a plan. Agile looks more towards getting the perfect fit instead of getting the planned product.
Agile also follows 12 principles, they are:
These principles largely tells you to:
- Develop and grow together with the team full of trust
- Develop the product in small, fast, continuous, and usable increments
- Deliver fast, but adapt to change even faster
Scrum
Scrum is a popular implementation of Agile. It is a flexible framework consisting of development loops that produces small incremental shippable products.
There are 3 main roles in scrum
- Product Owner: This is not the client, but rather someone responsible in communicating with the client to get the shape of the product that they want and relaying it back to the team.
- Scrum Master: This role serves to make sure the scrum process goes effectively, well, and follows scrum principles. They try to maximize the team’s potential and skills and finding effective solutions and to the team’s problems.
- Scum Team Members: This role is those who develops the product. They are a self-sustaining self-regulating team in-which every individual tries to do the task that has been given as well as possible.
There’s also something called product backlog and sprint backlog. A product backlog is an item in the list of requirement that a product needs, we may call it a “feature” in the entire program. A sprint backlog is a few selected product backlog that needs to be done in a “sprint”.
I mentioned “sprint”, but what is it exactly? Well, it’s one of the events that happens in scrum. As scrum is incremental, there’s a cycle, and within that cycle there are several events.
- Sprint: A sprint is a development period in which the development team tries to implement all the items in the sprint backlog. This last usually from 1–4 weeks depending on the agreement.
- Sprint planning: In this process, the members decide on producing a sprint backlog for a certain sprint with the scrum master and the product owner.
- Daily scrum meeting: In this process, the development team meets with scrum master discussing on what they’ve done, what they will do, and what their problems are so far in the sprint.
- Sprint review: In this process, the team, scrum master, and product owner presents their work to the client to be accepted or rejected.
- Sprint retrospective: In this process, the team and the scrum master look back on the sprint to discuss the good, the bad, and what they should start and stop doing for each sprint. After this step, the product is either shipped and/or the team goes back to planning.
As you may see, while Agile is flexible, there shouldn’t be any change of plan in one sprint. An entire sprint is planned on the Sprint Planning stage and other changes in requirement cannot come until the sprint is over. This is not a restriction however, as agile never meant to be a plan-less approach.
Scrum in Our Team
Sprint
Our sprint length is 2 weeks. Our sprints starts on Monday right after our sprint review, retrospective, and planning. We have a total of 5 sprints, each with the same steps.
Sprint Planning
We modified the planning process a bit than the original. We did our entire sprint planning before the start of sprint 1. This includes getting all the requirement we need from the client and assigning priorities to them while dividing each into smaller pieces. We then decide which one to take and put what we have to do on gitlab’s boards.
For every sprint planning after that, we only decide if we should take as planned before, more, or less. We would do small changes as the requirement comes, changing weight and changing the tasks before deciding. This makes our sprint planning way quicker and more efficient. We did this with the product owner.
Daily Scrum Meeting
We do only 4 daily scrum meeting in one sprint with the scrum master, one every Thursday and Sunday. In this, we decide that there must at least be one item moved across the board per meeting. We usually have a longer meeting than most, we would utilize the first 15 minutes into discussing what we have done and what we’ll be doing, and the next 15 minutes into discussing problems, either on a personal or a professional level.
We do this to get to know each other and grow together better. Our last 15 minutes usually turned into chatter to borderline gossip, which have a refreshing effect. I believe this really helps solidify the development team and give a breather in the cycle. As to why we only do this twice, it’s because we have other classes that we have to attend.
Sprint Review
We would have a sprint review where we would present what we have worked on to the client and the lecturer involved, along with the scrum master and product owner. This process lasts usually about 45 minutes and would have one or two person explaining. This meeting is usually done with google meet. We would also take in the client’s suggestion and demands as a requirement change.
We rotate the speaker for each review to grow each developer speaking and presenting skill. The speaker must know everything about what we have done for the sprint and must be able to reiterate it to the client. In the end of this, the client would be asked if they accept or reject what we have done based on the quality of our work. If they accept, then we can move on, if they reject, then we must do the work again.
Sprint Retrospective
In the sprint retrospective, we would use metroretro to give our thoughts and look back on the sprint we have just done along with the scrum master. We would each list at least 2 good and bad parts of the sprint, and 2 of what we should start and stop doing. We would then devise what actions we should take next.
I would describe this session as a longer daily scrum, as we take this occasion to talk more in depth about our personal and professional problems. We would each take turns telling our side of the story and discuss how we each may solve it. We then would act based on what we conclude from the meeting.
Agile in Our Team
Communication and growing together
We value communication to the utmost level, so much so that we usually code together. We use Discord and Line to communicate, and members would often hang around Discord when they’re developing or just relaxing. This allows us to fill in the daily scrum meetings we couldn’t have.
In these sessions we would share where we are, what we’re doing right now, or even code together. We do this especially because none of us are really interested in front end, so we make sure that the front end changes we ended up doing is known by everyone and everyone can pitch in how to solve each problem.
Deliver fast, adapt faster, and meet the expectation
We chopped each backlog to small deliverable tasks that could be implemented in less than a day. This in turn allow us to finish these tasks quickly and then ask for feedbacks from other members of the team. We also arranged the work in such a way that every sprint would have a good new feature to look at.
We also dedicate a chunk of the backlog to “Legacy work”. This chunk is all the changes that the client requested after every sprint review. We would tackle this part together, and by the end of the next sprint, we would’ve fixed the issue.
Just keep coding
This is inherent from the Agile process. Each of us keep coding, putting trust in each other’s work, maybe offering some feedback here and there. It is only when someone is done entirely on a big enough feature that we do a code review, we would look at the codes and see if there needs to be any change. And if there should be change we say it. This allows us to be fast yet versatile, Each of us would implement differently at first, all over the place, but as the sprint goes on and the completeness of each part increases, we would slowly converge on one thing.
The End?
So, is our implementation of Agile or scrum is correct? No.
But not because it is not correct, but because there is no correct way. You see, there’s no right in software development. We may be wrong for doing only 2 daily meetings, we may be wrong trying to make everything personal, we may be wrong for doing planning and changes like we did. But at the end of the day, it works.
What we have demonstrated here is that Agile is itself agile, you can mold and shape the kind of agile you want to do for your project and it might just work. Conventions are there to make things easier, not to put restriction on you. Implement Agile however you want, the point of Agile that it’s open to changes, and so you should be open too.
Agility is just an adjective. But a step to the right direction is never a bad move to take.