Differentiate between the Waterfall and Agile software development methodologies, and discuss, giving an example of each, the following agile methodologies:
a) Rapid application development (RAD);
b) Extreme Programming (XP) methodology; and
c) Scrum
The Answer
Differentiate between the Waterfall and Agile software development methodologies
The software development process is divided into different phases in the Waterfall model while Agile methodology segregates the project development lifecycle into sprints.
Waterfall is a structured software development methodology, and often times can be quite rigid, whereas the Agile methodology is known for its flexibility.
According to the Waterfall model, software development is to be completed as one single project, which is then divided into different phases, with each phase appearing only once during the SDLC. However, the Agile methodology can be considered as a collection of many different projects, which are nothing but the iterations of the different phases focusing on improving the overall software quality with feedbacks from users or the QA team.
Agile is quite a flexible method which allows changes to be made in the project development requirements even if the initial planning has been completed. While There is no scope of changing the requirements once the project development starts.
All the project development phases such as designing, development, testing, etc. are completed once in the Waterfall model while as part of the Agile methodology, they follow an iterative development approach. As a result, planning, development, prototyping and other software development phases can appear more than once during the entire SDLC.
One of the major differences between Agile and Waterfall development methodology is their individual approach towards quality and testing. In the Waterfall model, the “Testing” phase comes after the “Build” phase, but, in the Agile methodology, testing is typically performed concurrently with programming or at least in the same iteration as programming.
While Waterfall methodology is an internal process and does not require the participation of customers, the Agile software development approach focuses on customer satisfaction and thus, involves the participation of customers throughout the development phase.
The Waterfall model can be regarded as a stringently sequential process, however, the Agile methodology is a highly collaborative software development process, thereby leading to better team input and faster problem solving.
The Waterfall model is best suited for projects which have clearly defined requirements and in which change is not expected at all, while Agile development supports a process in which the requirements are expected to change and evolve. Thus, if you are planning to develop a software that would require frequent overhauls and has to keep up with the technology landscape and customer requirements, Agile is the best approach to follow.
The Waterfall model exhibits a project mindset and lays its focus strictly on the completion of project development, while Agile introduces a product mindset that focuses on ensuring that the developed product satisfies its end customers, and changes itself as the requisites of customers change.
a) Rapid application development (RAD)
Definition: The Rapid Application Development (or RAD) model is based on prototyping and iterative model with no (or less) specific planning. In general, RAD approach to software development means putting lesser emphasis on planning tasks and more emphasis on development and coming up with a prototype. In disparity to the waterfall model, which emphasizes meticulous specification and planning, the RAD approach means building on continuously evolving requirements, as more and more learnings are drawn as the development progresses.
Description: RAD puts clear focus on prototyping, which acts as an alternative to design specifications. This means that RAD works well wherever there's a greater focus on user interface rather than non-GUI programs. The RAD model includes agile method and spiral model.
Below phases are in rapid application development (RAD) model:
1. Business modeling: The information flow is identified between different business functions.
2. Data modeling: Information collected from business modeling is used to define data objects that are required for the business.
3. Process modeling: Data objects defined in data modeling are converted to establish the business information flow to achieve some specific business objective process descriptions for adding, deleting, modifying data objects that are given.
4. Application generation: The actual system is created and coding is done by using automation tools. This converts the overall concept, process and related information into actual desired output. This output is called a prototype as it’s still half-baked.
5. Testing and turnover: The overall testing cycle time is reduced in the RAD model as the prototypes are independently tested during every cycle.
Core concepts of RAD is
1. Clearly define the requirements
Anyone working on a RAD project should have an extremely clear vision on what the application should do and what problem it is trying to solve.
2. Rapid prototyping
A real, working application should be constructed within a very short amount of time and changes need to be implemented instantly.
3. Lots of feedback
Stakeholders should give their ideas for improvement continuously and be able to contribute to quick iterations.
Example
Employee Resignation
Another RAD example is handling employee resignation. HR teams have a lot to coordinate when an employee decides to leave the company. This app might seem trickier to build just because there are so many moving parts involved. But you can use the same approach.
HR will be leading the charge on this development. However, they need input from management, payroll, IT, and many others.
Creating the perfect workflow is the key challenge here. As you develop the application, you’ll continually think of other people who need to be informed and take action. RAD can play a key role in quickly adding steps to your workflow and testing to make sure that confidential data is hidden from those who don’t need to see it.
At some point in the development process, the HR team may also want to handle resignations and terminations in the same application. In traditional development, this means going back to the beginning and building the app from scratch. But if you are using Kissflow and RAD principles, you can quickly go through and create a different workflow for terminations, or make some tasks conditional.
b) Extreme Programming (XP) methodology
Definition
Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.
The Values
XP incorporates the following five values:
Communication: Software Development projects or projects in any industry rely heavily on communication. XP focuses on effective communication between the team and the customer.
Simplicity: XP looks for the simplest ways to get things done. This means to do what is essential thereby reducing waste, address only the known issues and keeping the design simple for effective creation and maintenance.
Feedback: Feedback plays an important role in project improvement. XP encourages instantaneous feedback. This helps the team identify room for improvement and revise practices.
Respect: The team must respect each other both personally and professionally, to achieve goals.
Courage: XP endorses courage at all levels. This can include speaking up against what does not work and anything that affects the project’s effectiveness, or accept feedback and improve methodologies.
The Practices
The original twelve practices for XP comprise:
The Planning Game
Small Releases
Metaphor
Simple Design
Testing
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-hour week
On-site Customer, and
Coding Standard.
Over the years, teams have found that some practices reinforce the others. To eliminate risks, these should be unified. The following descriptions include some of the refinements based on various teams’ experiences —
Whole Team: Teams should comprise cross-functional groups of people with different skills. In this way, they can complement each other to accomplish a specific outcome.
Sit Together: Most people agree that face to face conversations are the best form of communication. Teams should sit together without barriers to communication e.g. cubicle walls.
Informative Workspace: Teams should be arranged to sit in a way to make the team’s work transparent to each other and the affiliated people outside the team.
Energized Work: This means making sure that a person is mentally and physically healthy to focus on work. This also implies there should be no over-work and respect teams to support their mental and physical health as well.
Pair Programming: The idea behind this practice is that two brains are better than one. Pair Programming refers to software production through two people sitting at the same machine. By this, there is a continuous work review and problems receive a faster response. This method has been shown to improve quality and stay more focused.
Stories: Stories define the features that the product should have that would be meaningful to customers and users. These stories are used for planning and also serve as reminders for further conversations.
Weekly Cycle: The first day of every week, the team meets to reflect on the progress to date. The stories that should be delivered in the week are selected by the customer. The team determines how to approach those stories. The goal behind this is to achieve a running, verifiable feature by the end of the week. The fixed period allows for the production of a feature that can be shown to the customer for feedback.
Quarterly Cycle: The purpose of the quarterly cycle is to check the detailed work of each weekly cycle in the context of the overall project. The customer provides the overall plan for the team within a particular quarter. This not only gives the team a view of the project but also helps the customer to work with other stakeholders involved.
Slack: This implies adding a few, low priority tasks or stories in the weekly and quarterly cycles. If the team is lagging on more important tasks, these can be dropped. Else, these will also be completed, increasing the chances of meeting the estimated schedules.
Ten-Minute Build: The entire system and all of the tests should be run within ten minutes. If the time exceeds this limit, multiple reruns will cost larger periods between errors. This practice encourages automation of the build process, making it feasible regularly, to run all of your tests.
Continuous Integration: This practice encourages immediate testing of new code to the existing larger codebase. This helps catch and fix integration issues sooner. This practice requires discipline and depends on the practices of Ten Minute Build and Test First Development.
Test-First Programming: Instead of following the regular way i.e.,
Develop Code -> Write Tests -> Run Tests
the practice of Test-First Programming takes the path of:
Write Failing Automated Test -> Run Failing Test -> Develop Code to Make Test Pass -> Run Test -> Repeat
This practice, too, reduces the feedback cycle for issue identification and resolution. This results in a reduction in the number of bugs that get introduced into production.
Incremental Design: This practice portrays doing a certain amount of work upfront to understand the breadth-wise perspective of the system design. After that, work further on the details of a particular aspect of the design when specific features are delivered. This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.
We then took a look at some examples of the main practices of extreme programming, for example the Planning Game (a meeting that includes the developers, the project manager, and the stakeholders to define short-term priorities).
c) Scrum
What Is Scrum?
While searching for project management jobs, Laurie stumbled upon a job opportunity for a scrum master. Unfamiliar with scrum, she calls her friend Robert, a software developer who is part of a scrum team, for some guidance.
Robert explains that scrum is a framework that guides small teams to break complex products into small, functional pieces of work that can be coded and delivered in small increments of time known as iterations or sprints. The benefit is that working software is delivered to customers quickly.
Scrum is a term borrowed from the sport rugby and is short for scrummage, which is a way of starting play again. The goal of rugby is to play continuously without any time-outs or other interference.
As in rugby, in scrum, a delivery team must deliver working, quality software by the end of the sprint. A sprint is usually two weeks in length, but can be shorter or longer. The delivery team continues to work in sprints until the end of the product or project. Team members work together, without any outside interruptions, while the sprint is in process.
Scrum Team Roles
The scrum team incorporates three roles:
Delivery team
Scrum master
Product owner
Let's look at each in further detail, starting with the delivery team.
The Delivery Team
The delivery team is accountable for choosing which work it will deliver at the end of the sprint. Team members are self-organizing and empowered to make all decisions on how they'll complete their work. They're also fully dedicated to the product.
Laurie's friend Robert is part of a delivery team, sometimes referred to as a development team. The team size is kept small, usually only five to seven people, so that collaboration and communication is easier. Robert's team has four developers, two testers, and one designer, but their skills are fairly balanced or cross-functional.
Scrum Master
The scrum master is the servant-leader to the delivery team. His or her main responsibility is to remove any roadblocks that are preventing the team from completing work and to protect the team from all outside interference. The scrum master also teaches others, including the product owner and other organization employees, about scrum and ensures that everyone adheres to its principles.
Product Owner
Finally, the product owner is responsible for creating and prioritizing the work listed in the product backlog, which is a list of work that needs to be completed. This person serves as the one voice for the product and works closely with the development team on a daily basis.
The Five Ceremonies
Robert seems fairly excited to explain how scrum teams engage in five standard ceremonies or events, traditionally known as meetings.
These include:
Sprint planning
Daily stand-up
Refinement or grooming
Sprint review
Retrospective
Example :
Scrum by Example is written as an episodic story, with a small cast of characters and a simple fictional product. ... While he has 10 years of experience in software, he has no practical Scrum experience, as this is his company's first foray into Agile. Paula – The Product Owner for the World's Smallest Online Bookstore.