Week #4: Why Agile?
Hello! Allow me to introduce myself; my name is Naima, and I am the hustler of this team! As the hustler, it is mainly my responsibility to make sure there are no misunderstandings between the team and our clients. This means opening a steady stream of communication, asking any questions the team may have, and arranging meetings when necessary. I also need to think about the clients’ needs regarding the application, while at the same time measuring exactly how many of those needs can be satisfied by our team. All of these sound very complicated, right? That’s precisely why I need help doing it, in the form of the Agile Software Development.
able to move quickly and easily.
Derived from the definition of the word agile, Agile Software Development is an approach to software development, under which requirements and solutions evolve through the collaborative effort between the client and the development team. Unlike traditional software development models such as Waterfall, where the client is only involved in designing the requirements at the very start of development, in Agile the client is an active participant throughout the whole process. If the traditional models put clients’ needs and requirements at the center of the development, then Agile puts communication, collaboration, and adaptation as its center.
The Agile Manifesto & Twelve Principles of Agile Software
Of course, this approach to software development did not just materialize out of thin air. The term “agile” was popularized in this context by the Manifesto of Agile Development. This manifesto and the subsequent twelve principles of Agile Software were born as a result of the industry’s frustrations with the enormous time lag between business requirements and the delivery of technology. The fact was, said extreme lag caused the cancellations of countless projects, projects that were already well under way.
And so, in the year 2000, a group of seventeen “thought leaders,” met at a resort in Oregon to discuss this problem. A year later, on their second meeting at The Lodge at Snowbird ski resort in Utah, the manifesto was formally written, and it says:
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.”
Along with those four values (highlighted in bold above), the twelve principles of Agile Development were also born:
- Customer satisfaction through early and continuous software delivery — Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.
- Accommodate changing requirements throughout the development process — The ability to avoid delays when a requirement or feature request changes.
- Frequent delivery of working software — Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.
- Collaboration between the business stakeholders and developers throughout the project — Better decisions are made when the business and technical team are aligned.
- Support, trust, and motivate the people involved — Motivated teams are more likely to deliver their best work than unhappy teams.
- Enable face-to-face interactions — Communication is more successful when development teams are co-located.
- Working software is the primary measure of progress — Delivering functional software to the customer is the ultimate factor that measures progress.
- Agile processes to support a consistent development pace — Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.
- Attention to technical detail and design enhances agility — The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.
- Simplicity — Develop just enough to get the job done for right now.
- Self-organizing teams encourage great architectures, requirements, and designs — Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
- Regular reflections on how to become more effective — Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently
How do we Use Agile in this Development?
In the development of PsychoTip, we use the Agile framework: Scrum. Scrum is a framework where the development process is split into sprints. Sprints typically lasts for around 1–2 weeks, and during that period the team is expected to successfully implement a set of product backlogs (it’s a fancy term for application feature, basically). In order to implement and integrate the product backlogs onto the existing application, the team breaks each product backlogs to a number of tasks. Each person is then assigned a task and is expected to complete them before the next scrum meeting.
I know, I know, that’s a lot of information to digest, right? So, to get rid of any confusion you may have, let me break down the terminology of scrum, and explain to you how it is implemented in our development process!
- Scrum : The framework we use to develop PsychoTip. Scrum is typically broken down into sprints. In our case, we break it down into six sprints.
- Product Owner : The person/organization who owns the product being developed. In our case, the product owner would be the UI Achievement Community (UIAC).
- Scrum Master : The facilitator for an agile development team. The scrum master is essentially the bridge between the product owner(s) and the development team itself. They are in charge of managing the process of information exchange. In this team, Kak Yuna acts as our scrum master.
- Development Team : The team doing the development itself. Development teams in Scrum typically self-organize and self-manage; this means they are largely independent in how they decide to do their work. In our case, the development team is us, the PsychoTeam.
- Sprint : A ‘unit of measurement’ of Scrum, so to speak. Sprints typically last around 1–2 weeks. Ideally, each sprint should produce a Minimum Viable Product (MVP) of the application being developed. In our case, each of our sprint lasts around two weeks.
- Sprint Planning : A meeting between the product owner(s), scrum master, and development team to plan the upcoming sprint. In this meeting, everyone will discuss the sprint backlogs — or the product backlogs that should be done in the upcoming sprint. Said backlogs are also broken down into tasks, and each person in the development team is assigned at least one task. Our sprint planning takes place once every two weeks, and due to our product owners’ busy schedule, we usually plan the sprint with just us and our scrum master.
- Scrum Meeting : A daily meeting between the scrum master and the development team. In this meeting, the scrum master will ask for updates regarding the tasks each member were assigned during the previous scrum meeting. It is generally expected of the development team to have finished the tasks they were assigned in the previous scrum meeting. If they have failed to do so, they may share any setbacks or difficulties they had. In a scrum meeting, the team is also assigned new tasks to further the progress of the sprint. Even though a scrum meeting is typically held every day, our team has a scrum meeting twice a week — every Monday and Thursday.
- Sprint Review : A meeting between the product owner(s), scrum master, and development team at the end of a sprint to showcase the work that has been done. The product owner(s) will be shown the backlogs that has been implemented during the sprint, and they will also try the product themselves. Afterwards, they may accept or reject the backlogs that have been done — according to how functional it is. For us, sprint reviews take place every two weeks.
- Sprint Retrospective : A meeting between the scrum master and development team after the sprint review and prior to sprint planning. The purpose of this meeting is to reflect on the previous sprint — what went well, what went badly, and what the team will commit to do in the future. Like sprint reviews and sprint plannings, our sprint retrospectives take place once every two weeks. During our sprint retrospectives, we usually take time to write out the good and bad things we thought about our team on post its. We then grouped the bad things based on a general term (i.e. lack of focus, poor time management, etc.) and discussed what we can do to avoid them in the next sprint. Afterwards, we soothe the sting of any criticism by reading out what we thought was wonderful about our team and each other.
How Well is it Implemented Within our Team?
Well, we might not tick every box when it comes to agile implementation, but I’m fairly certain we’ve covered most of it. For example, we (the development team) have a channel for communication through the social media app LINE, where we have a group consisting of us (the core development team), our scrum master, and the product owners themselves.
This LINE group serves as our primary communication channel. On it, we discuss everything: whether it be when and where we have our scrum meetings, arranging meetings with the product owners, and also any difficulties we might encounter during a sprint. Especially since we are developing an Android application, which happens to be a first for everyone in our team.
We are also very lucky in the sense that our product owners are also university students, therefore they have been very understanding about our capacities for learning and discovering new things. They’re also very accommodating when we request to meet face-to-face, to discuss problems that we might have faced during the current development phase.
In that picture, we were meeting to discuss changes to the requirements. We had faced some problems during designing and pitching the idea to our lecturer, and we finally had to erase some requirements for now, because again: it’s our first time developing an Android app. Thankfully, our product owners were really considerate about it, and agreed to lessen the requirements for our application.
At the end of this week, we will meet them again for our first sprint review. During the course of development for this app, we have set a 2-week period of sprints, with a total of 6 sprints involved. This ensures that we deliver a working prototype every 2 weeks, without skipping one. We keep track of everything we’re currently working on in our scrum board, and we (the development team) also meet everyday to help and motivate each other while doing our tasks!
All in all, although we have yet to experience our first sprint review and sprint retrospective, I think our team has implemented quite a bit of the Agile development principles. I’m sure as we go further into the development phase, we will find new examples of how we implement the Agile Software Development in this development!
P.S.: Here’s some bonus pics of our team being the dorks we are.