Normally, digital products are in a new, fast-moving market that changes frequently. That being said, the development process of digital products needs an approach that is flexible.
What is Agile?
Agile is “the art of iterative and incremental software development”. It is a type of project management process, where problems and solutions are evolving through the development process. It consists of a collection of principles that provide adaptability and flexibility.
Agile concept emerged around the end of the 90s to the beginning of the new millennium. In the 1990s, with the increasing of software needs, the industries realized that they couldn’t move fast enough to meet customer demands, it took about 3 years to develop a single software. At that time, softwares were released all-at-once, which means, the customer could not use the product until it was fully developed. Because it took an enormous time, by the time an actual application was finished, it was highly likely that the requirements defined at the beginning of the development, three years before released, had already changed and the software became outdated.
In 2001, a group of industry practitioners gathered up to discuss a new approach in software development. Although the aim of the discussion was to talk about effective development cycles, it was the beginning of Agile Methodology.
Every philosophy or concept must have a manifesto that consists of a declaration of values and principles that expresses its stance, views, and intentions, including Agile.
Agile Manifesto made up of four foundational values and 12 key principles.
Agile Manifesto Values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Derived from these values, from agilemanifesto.org/, there are 12 principles in Agile Manifesto.
Agile Manifesto Principles.
- Customer satisfaction through early and continuous software delivery
- Accommodate changing requirements throughout the development process
- Frequent delivery of working software
- Collaboration between the business stakeholders and developers throughout the project
- Support, trust, and motivate the people involved
- Enable face-to-face interactions
- Working software is the primary measure of progress
- Agile processes to support a consistent development pace
- Attention to technical detail and design enhances agility
- Simplicity
- Self-organizing teams encourage great architectures, requirements, and designs
- Regular reflections on how to become more effective
However, in my opinion, these principles and manifestos should not be ‘stiff’ because we can eliminate some of these points can be eliminated with the agile purpose still achieved.
Accommodate changing requirements throughout the development process
To some point, I agree that accommodation for changing requirements should be available throughout the development process, but only for minor things like the design of the button, etc. If we’re changing the core requirement like the business process of the application in the middle of the development, the software will less likely to be finished and the effort the development team has put in will be useless.
Enable face-to-face interactions
Face-to-face interaction is important to directly update the progress of each member's task. However, with the improvement of technology, the are many tools that were made specifically for scrum and agile processes. For example, there’s a bot in Slack messenger called standup-bot that will automatically ask each member of the group to give an update of their task.
Self-organizing teams encourage great architectures, requirements, and designs
A self-organizing team is a blessing for a collaborative project, but it does not necessarily mean it will encourage great architectures, requirements, and designs, it all still depends on the team member’s initial skill.
Collaboration between the business stakeholders and developers throughout the project
Not all client can accompany throughout the development process. If the client is busy, we can tackle this by settling the fixed requirement at the beginning of the project.
Simplicity
It depends if we over-simplify things, things will get even more complicated after some times, so the important thing is not simplicity but maintaining ✨standard✨.
To achieve these principles and values, organizations usually use several methods such as Scrum, Extreme Programming (XP), Crystal Methodology, Dynamic Software Development Method, etc.
In the software engineering project course, our team develop a web-based application for mobile named Raising Star. This application basically aimed to help parents in tracking their children’s development. We decided to use Agile to approach our project because the client wants to see every increment of the development of the product.
Agile Methodologies
Scrum
Scrum is characterised by cycles or stages of development, known as sprints, and by the maximisation of development time for a software product. It is usually used in the management of development projects for software products, but it can also be used in a business-related context.
Kanban
Kanban means “just-in-time”. In practice, the Kanban method exists in a board or table (Kanban board), divided into columns that shows every flow of the software production. As the development evolves, the information contained in the table changes, and when a new task comes into play, a new “card” is created.
Extreme Programming (XP)
This methodology prioritises customer’s satisfaction over anything else. This methodology motivates developers to accept change of requirements even if they arrive in a later stage of the development cycle.
In XP, when the team stumbled upon a problem, it is solved by the whole team of managers, developers, and customers.
Lean Development
Lean Development is a methodology that comes directly from Lean Manufacturing, created by Toyota. There are 7 principles in Lean Development:
Deleting the things that do not matter
Everything that does not bring effective value to the customer’s project is deleted
Quality development
creating quality in development requires discipline and control of the quantity of residuals created
Creating knowledge
the team is motivated to document the whole infrastructure to later retain that value
Differing commitments
this point encourages the team not to focus too much on planning and anticipating ideas without having a prior and complete understanding of the requirements of the business
Fast delivery
deliver value to the customer as soon as possible
Respecting the team
communicating and managing conflicts are two essential points
Optimise the whole
the development sequence has to be perfected enough to be able to delete errors in the code, in order to create a flow of true value.
Crystal
Crystal focuses on principles such as People, Interactions, Community, Skills, Talent and Communication, aiming to deliver the best possible software development process. The core of this development process is interaction and symbiosis, which have to exist between the people allocated to the projects and processes in order to bring efficiency to the development.
Non-Agile Methodologies
Besides agile methodologies, there are also non-agile methodologies. The difference between agile and non-agile methodologies is in non agile methodologies, you can only proceed to the next stage when the current stage is 100% done. There are some non-agile methodologies:
Waterfall
Waterfall methodology is a linear approach to software development. In this methodology, the sequence of events is:
- Gather and document requirements
- Design
- Code and unit test
- Perform system testing
- Perform user acceptance testing (UAT)
- Fix any issues
- Deliver the finished product
In a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin..
Waterfall V-Shaped Model
The difference with Waterfall method is in V-Shaped Model, quality assurance actions related to each activities
Why Scrum is more popular than others?
After knowing many software development methodologies, you’ll wonder why do people usually use Scrum instead of other methodologies?
Adaption
Scrum is about adapting as you progress, rather than excessive planning in the beginning. In this fast-paced world, being adaptive is important.
Get Value Fast
In each iteration/sprint, customer can see the results fast which can lower risks of customer unsatisfiablity and improves stakeholder relationships. Other than that, customer/clients also have the opportunity to change or refine the rquirements.
Team-Focused
Scrum is known to be a “team-centric” project management approach. It’s perfect for organisations with many teams (which almost all companies have many teams).
How our team using agile to develop our product
To implement Agile Methodology, we use Scrum Method.
What is Scrum?
Scrum is a framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. There are several actors in Scrum Framework:
Product Owner (PO)
Product Owner is the one that orders the work for a complex problem into a Product Backlog and managing the backlog, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items
- Ensuring that the Product Backlog is transparent, visible and understood.
Scrum Master (SM)
SM is responsible for ensuring Scrum is understood and enacted. SM also needs to make sure that the team can work comfortably, including:
- Coaching the team members in self-management and cross-functionality;
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
SM also helps product owner in several ways:
- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Helping establish empirical product planning for a complex environment;
Scrum Team/Development Team
This is the team that turns a selection of the work into an Increment of value during a Sprint. This team can include software engineers, architects, programmers, analysts, system admins, QA experts, testers, UI designers, etc.
The responsibilities of Development Team includes
- Decides how many items to build in a Sprint, and how best to accomplish that goal.
- Developing, testing and releasing the Product increment.
- Builds the product that the Product Owner indicates: the application or website, for example. The Team in Scrum is “cross-functional”
Scrum Events
Organize the Backlog
This event is the responsibility of the product owner. It is basically a set of features and its expected outcome. In our project, it is manifested this way:
Every feature is put into a more detailed list called backlog, these backlogs are what we need to do in order to develop the feature.
Sprint Planning
This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific use stories are then added to the sprint from the product backlog.
Our team usually has a 2 hours meeting for Sprint Planning. In Sprint Planning, we picked which features we want to develop and weighed each backlog. After that, we discuss the distribution of tasks.
Sprint
A sprint is the actual time period when the scrum team works together to finish an increment. Each sprint in our team is 2 weeks. To ease the development process, we develop every user story and task in different branches.
Stand Up Meeting
This is a daily super-short meeting that happens at the same time (usually mornings) and place. We do our stand-up every Thursday and Sunday.
If you can’t do a standup meeting daily, make sure the gap between days is even.
Sprint Review
This happens at the end of the sprint. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback.
Usually, in Software Engineering Project Course, the Sprint Review is held in the class schedule every 2 weeks. In every sprint review, our team presented what we developed.
First Sprint
In the first sprint, we developed tutorial page, login and signup pages, and also child’s assessment. We chose these backlogs in the first sprint because these features are essential for the whole products.
Second Sprint
In the second sprint, we developed Activity pages which consists of activities that user can do to accelerate their child’s growth.
Third Sprint
In the third sprint, we developed ‘Materi’ pages and profile pages.
Fourth Sprint
In the fourth sprint, we developed static pages of consultations.
Fifth Sprint
In the fifth sprint, we basically fixed things that are not perfect in the previous sprints, but for the new features, we developed sign up using Google Account and Edit Profile.
Intermezzo: change during sprint by Product Owner
What if in the middle of a sprint, PO asks for requirement changes?
In my opinion, product owner can change the requirement if:
- The change not violates the sprint goal
- Changes should be negotiated with the development team.
Sprint Retrospective
The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies.
In each sprint retrospective, we usually write down 4 things: What are the bads, the goods in the previous sprint, what we need to start doing, and what needs to stop. This is an example of what we think we need to start do in the next sprint:
Closing Remarks
To develop software is to organize and understand the people. I think that the approach of Agile that puts interaction between team members first is a good approach.
Thank you for reading 😊
References:
https://zenkit.com/en/blog/agile-methodology-an-overview/
https://techbeacon.com/app-dev-testing/when-agile-wrong-choice-your-organization
