Dietela: Thriving in Agile Development
How we fall in love with methodologies we have yet to master.
This article is written as an individual review assignment for PPL CS UI 2021.
It’s 2021.
Agile development has been adopted by a variety of different communities, appealing to undergraduate students such as myself, freelancers, startups, and even bigger companies. However, while Agile is becoming more common, Agile implementation is unique to every entity.
The Essence
Agile in a Nutshell
In the simplest words, Agile is to deliver and adapt quickly during the process of software development through an iterative, incremental approach.
It mainly offers the values of transparency, flexibility, and continuous improvement.
Therefore, projects with vague requirements, unsettled features, still adjusting to product-market fit, or under a limited timeline are best suited for agile development.
The Sequence
One well-known methodology in implementing agile development is Scrum.
Our team adopts Scrum to develop our project, Dietela, as we are constructing under a limited timeline with vague requirements. Despite that, we are still thriving in our software development process thanks to agile development, and if you are wondering, here is the overview of how we do things:
Initialization: Sprint Planning
As all things should, a sprint starts with planning.
How each entity executes planning differ from one to the other, but the gist remains the same:
Sprint planning resolves around determining features based on their workloads.
In particular to our project, the developer team and the scrum master will gather and follow these steps:
- First, we determine the workload (or story points) of each provided feature (or backlog). A story point represents the standardized amount of working time (in our case, 1 SP = 30 minutes).
- We then select the backlogs to be implemented for the current sprint following a constraint timeline. To finish our project, the mobile team and backend team each dealt with around 40 SPs of new backlogs per sprint.
When the backlogs are finalized, we decompose those backlogs into smaller tasks (as seen from the above picture) and translate them into our task organizing tool, Gitlab Issue Board.
Each task or issue is assigned to a specific developer and labeled to its corresponding backlog. Any unprecedented issues can be adjusted accordingly, as we strive to promote the culture of a self-organizing team.
Implementation: The Sprint Itself
Now, the execution begins!
A sprint phase usually lasts for one week to a maximum of two weeks. Within this time frame, the developers are expected to test and implement the selected backlogs until the features are fully functional and integrated.
A daily standup meeting is conducted to track the whole team’s progress and updates to ensure work transparency and practice effective communication. Generally, the team will share about three core topics:
- Progress: Things you’ve done so far, either in the form of completed tasks or work in progress.
- To-dos: Things you plan to do after the standup meeting, could be continuing your previous tasks or handling new tasks.
- Blockers: Things you found to be hindering your progress so far (if any).
Standup meetings are like your lovers. They regularly ask you how are you doing, listen to your concerns, and help you solve your problems and sort out your (developer) life.
In our project, we follow a two-week sprint with standup meetings conducted twice a week. We share our progress, set our to-dos, and resolve each other’s blockers (like lovers, so sweet). Our updates are reflected through the Gitlab issue board.
Presentation: Sprint Review
At the end of a sprint, whether the features are done or not, we are off to impress!
The whole point of a Sprint Review is a live product demo, whether to our clients, product manager, scrum master, or even just to the developer team (although very unlikely). By its name, a product or working software has to be delivered with the agreed, expected outcome.
The objective of Sprint Review is to have frequent inspections to detect any undesirable behaviors from the eyes of the client or its representative.
Albeit the previously stated “agreed” outcome, we highly value a feedback loop and adhere to adaptation for any major or minor adjustments.
Sprint Review can turn a feature to exist in quantum physics: it may be at the end, the fresh start, or everything in between of the development stage.
Evaluation: Sprint Retrospective
At last, we can get a well-deserved rest and fun team introspection.
Here, we can pour our thoughts about our last sprint. We do silent writing to convey our thoughts without the sight of others’ opinions. Afterward, we can appreciate and celebrate what we’ve done right (yay!), and reflect on the “bad” things and rooms for improvement.
As we introspect ourselves and our team, the unspoken rule is to NOT be complacent. Be critical and open.
The Experience
My first impression of agile development is “Wow, agile is actually pretty easy to pick up.” Not to mention, agile suits my style where I believe that improvisation is as important as planning.
However, after much experience, I dare say:
While Agile is easy to learn, it is difficult to master.
Admittedly, our Dietela developer team has yet to completely master agile development as well. It takes patience, dedication, and self-assurance to be able to deliver at peak performance on every standup meeting and ultimately sprint review.
However, don't worry. That is the fun part! We are in this nonstop, beneficial cycle of learning as our product grows and improves over time. Every contribution we made propels us towards our mastery of (1) the tech stacks we used, (2) the product we build, and (3) of course, what it takes to be agile.
References
- https://agilemanifesto.org/
- https://www.agilistix.com/scrum/three-pillars-of-scrum/
- https://kissflow.com/project/agile/benefits-of-agile/
- Scrum Guidelines of PPL CS UI 2021
