3.

0 Software Process Models – II

Lesson Introduction

Agile is an umbrella term for a collection of iterative and incremental software development
approaches, with each of those variations determine its Agile framework. The most widely used
Agile frameworks include Scrum, Dynamic Systems Development Method (DSDM), Crystal, and
Extreme Programming (XP). While each Agile methodology has unique characteristics, they all
incorporate elements of iterative development and continuous feedback when developing
software applications.

Learning Outcomes:
• After completion of this lesson, students will learn the basic principles behind agile
software development. Also, they will be able to describe different agile models in
software development.

Lesson Outline:
• Agile models
• Differences between agile models and traditional models
3.1 Agile Software Development

The Agile development began in the 1990s as a rejection of rather steady development methods
such as the waterfall model and V-model. These traditional approaches had a reputation for
missing deadlines, going over budget, or failing. Agile approaches offered a means and often
promised more than they can actually deliver. Despite the methodology, the strengths and
weaknesses of any method must be understood before proceeding. All Agile methodologies
share a set of core ideas: iterative and incremental delivery of code, regular collaboration with
stakeholders, self-organizing teams, and the ability to incorporate changes later in the project.

In February 2001, the Manifesto for Agile Software Development was created by seventeen
people with desires to find alternative approaches to software development. Each of them
played a prominent part in the opposition of the current software development processes, which
they considered rigid, heavyweight, and too focused on documentation.

Their response, summarized in the manifesto, which reads as:

“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.”

Below are the twelve principles underlie the Agile Manifesto.

i. Customer satisfaction by rapid delivery of useful software
ii. Welcome changing requirements, even late in development
iii. Working software is delivered frequently (weeks rather than months)
iv. Working software is the principal measure of progress
v. Sustainable development, able to maintain a constant pace
vi. Close, daily co-operation between business people and developers
vii. Face-to-face conversation is the best form of communication (co-location)
viii. Projects are built around motivated individuals, who should be trusted
 ix. Continuous attention to technical excellence and good design
x. Simplicity
xi. Self-organizing teams
xii. Regular adaptation to changing circumstances

Watch the video titled “agile manifesto explained” available

in Moodle for more information.

3.2 Agile Process Models

“Agile process model” refers to a software development approach based on iterative

development. Agile methods break tasks into considerably smaller iterations and therefore, do
not directly involve long-term planning. In agile, the project requirements are clearly laid down
at the beginning of the development process. Thus, the plans regarding the number of iterations,
the duration and the scope of each iteration are clearly defined in advance.

In earlier days, the Iterative Waterfall method was very popular with the complete a project. But
today developers face a variety of problems while using it to develop software. The main difficulty
was handling the change requests from the customers during the project development.
Therefore, high cost and time required to cooperate and handle these changes. In order to
address the drawbacks in the waterfall model, Agile software model was proposed in the mid-
1990s.

Agile software development aims at addressing the problems of waterfall model through a real
communication between programmers and customers.
 Figure 1

Agile model refers to a group of development processes. These processes share some basic
characteristics but do have certain subtle differences among themselves. A few Agile SDLC
models are given below:

● Crystal
● Feature-driven development
● Scrum
● Extreme programming (XP)
● Lean development
● Unified process

Agile software engineering embraces a philosophy that encourages customer satisfaction,

incremental software delivery, small project teams (composed of software engineers and
stakeholders), informal methods, and minimal software engineering work products. Agile
software engineering guidelines stress on-time delivery of an operational software increment
over analysis and design.

● An agile team is able to respond to changes during project development

● Agile development recognizes that project plans must be flexible
● Agility encourages team structures and attitudes that make communication among
developers and customers more facile
● Agility eliminates the separation between customers and developers
● Agility emphasizes the importance of rapid delivery of operational software and de-
emphasizes the importance of intermediate work products
● Agility can be applied to any software process as long as the project team is allowed to
streamline tasks and conduct planning in ways that eliminate non-essential work products
Advantages of Agile:

● Pair programming can produce well written programs which has less errors compared to
programmers working alone.
● It reduces total development time of the whole software project.
● Customer representative get the idea of updated software products after each iteration.

Disadvantages of Agile:

● Due to lack of formal documents, it creates confusion and important decisions taken
during different phases can be misinterpreted at any time by different team members.
● Due to absence of proper documentation, when the project completes and the
developers are assigned to another project, maintenance of the developed project can
become a problem.

Below we discuss some of the well-known agile methodologies in detail. We will start with understanding
the concepts behind Agile Scrum methodology.

3.2.1. Agile Scrum Methodology

Scrum is usually known as as a methodology; but rather than viewing Scrum as methodology,
think of it as a framework for managing the software development process. It is one of the
approaches that influenced the Agile Manifesto, which articulates a set of values and principles
to guide decisions on how to develop higher-quality software faster. Figure 2 presents a pictorial
representation of the agile scrum methodology.
 Figure 2

In the agile scrum methodology, major part of the work left it to the Scrum software development
team instead of providing complete, detailed descriptions of how everything is to be done on a
project. Because the team will know best how to solve the problems that they are presented.
This is a most popular agile methodology and widely used by the software development teams.

Scrum teams are supported by two specific roles in agile development,

➔ The first is a ScrumMaster, who can be thought of as a coach for the team, helping team
members use the Scrum process to perform at the highest level.
➔ The product owner (PO) is the other role, and in Scrum software development,
represents the business, customers or users, and guides the team toward building the
right product.

Watch the video titled “agile scrum” available in Moodle for

more information.
Upon watching the above video, now you can understand the key terminologies used in Agile
scrum as described below.

Scrum team: A typical scrum team has between five and nine people, but Scrum projects can
easily scale into the hundreds. However, Scrum can easily be used by one-person teams and often
is. This team does not include any of the traditional software engineering roles such as
programmer, designer, tester or architect. Everyone on the project works together to complete
the set of work they have collectively committed to complete within a sprint. Scrum teams
develop a deep form of camaraderie and a feeling that “we’re all in this together.”

Product owner: The product owner is the project’s key stakeholder and represents users,
customers and others in the process. The product owner is often someone from product
management or marketing, a key stakeholder or a key user.

Scrum Master: The Scrum Master is responsible for making sure the team is as productive as
possible. The Scrum Master does this by helping the team use the Scrum process, by removing
impediments to progress, by protecting the team from outside, and so on.

Product backlog: The product backlog is a prioritized features list containing every desired
feature or change to the product. Note: The term “backlog” can get confusing because it’s used
for two different things. To clarify, the product backlog is a list of desired features for the product.
The sprint backlog is a list of tasks to be completed in a sprint.

Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held, during
which the product owner presents the top items on the product backlog to the team. The Scrum
team selects the work they can complete during the coming sprint. That work is then moved from
the product backlog to a sprint backlog, which is the list of tasks needed to complete the product
backlog items the team has committed to complete in the sprint.

Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is conducted. This
meeting helps set the context for each day’s work and helps the team stay on track. All team
members are required to attend the daily scrum.

Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they accomplished
during the sprint. Typically, this takes the form of a demonstration of the new features, but in an
informal way; for example, PowerPoint slides are not allowed. The meeting must not become a
task in itself nor a distraction from the process.
Sprint retrospective: Also at the end of each sprint, the team conducts a sprint retrospective,
which is a meeting during which the team (including its ScrumMaster and product owner) reflect
on how well Scrum is working for them and what changes they may wish to make for it to work
even better.

3.2.2. Crystal Methodologies

In 1991, IBM asked Alistair Cockburn to develop the methodology for object-oriented projects.
He realized that it will be a real challenge as he did not know much about software development
methodologies by that time. So, he decided to interview project teams and find out their view of
the project. After doing a research he understood that successful teams shared the same patterns
and techniques without even using any specific project methodology. In other words, they added
value to the aspects like close communication, morale, access to users and others, which you can
not find in any specific methodology. Finally, he used his findings to construct a family of
methodologies and named it Crystal.

Crystal is a software development approach that is contrary to the people and processes and
tools with a focus on their interaction. Some people believe that the people’s skills, talents and
communications has a biggest impact on the outcome of the project. In other terms, this
framework is a natural outgrowth of one of the key values expressed in the Agile Manifesto.

The Crystal agile framework is built on two core beliefs,

● Teams should discover ways to improve and refine their workflows on their own.

● Every project is unique and always changing, which is why that project’s team is best
suited to determine how it will tackle the work

According to Alastair Cockburn, we should see product development as a game that should
inspire everyone to engage, become innovative and create brilliant ideas. He suggests that
instead of concentrating on issues like "is our template accurate?" "We should be looking for
answers to questions like," Is our brand meeting the needs of the customer? Or do we have our
priorities linked as a team?
The Crystal Methods family uses different colors to reflect the "weight" of the technique to be
used. If a project were a small one a methodology such as Crystal Clear, Crystal Orange or Crystal
Yellow may be used or if the project was a mission-critical one where human life could be
endangered then the methods Crystal Diamond or Crystal Sapphire would be used.

Eg:

1. Crystal Red
2. Crystal Orange Web
3. Crystal Orange
4. Crystal Yellow
5. Crystal Diamond
6. Crystal Maroon
7. Crystal Clear
8. Crystal Sapphire

There are five "colors" reflecting the five families of Crystal Methodologies to be applied based
on the size of the project (i.e. the number of people involved in the project).

Clear–up to 6 people
Yellow–up to 20 people
Orange–up to 40 people
Red–up to 80 people
Maroon–up to 200 people

Apart from providing a "size" factor which defines the framework, the other factor listed above
is that of "criticality," which is the amount of potential damage that the device may trigger if it
does not function as expected.

Comfort (C) Discretionary Money (D) Essential Money (E) Life (L)
 Figure 3

Crystal’s Advantages

● The adaptive approach allows teams to respond well to changing requirements.

● Allows teams to work the way they think most effective
● Facilitates effective communication, transparency and accountability

Crystal’s Disadvantages

● Lack of pre-defined plans can lead to scope creep

● Lack of documentation can lead to confusion

The Crystal Method is one of the most flexible agile frameworks, because it is designed around
the people of the project and does not depend on any single set of processes or tools. In that
way, it can be a realistic methodology for companies that want their employees to be motivated
to function.

It is important to keep in mind, since Crystal emphasizes direct team collaboration around the
software, it could deemphasize the importance of transparency and reporting. Thus, the other
departments across the organization will have less insight on the success of the project.
3.2.3. Extreme Programming

Extreme Programming (XP) is an agile software development framework that aims at delivering
higher quality software and a higher quality of life for the development team. XP is the most
common agile framework for effective engineering practices for software development. It is a
systematic approach with a set of values, guidelines, and practices for the rapid development of
high-quality software that provides the highest value to consumers.

XP is suitable in the following conditions.

● Dynamically changing software requirements

● Small, co-located extended development team
● Fixed time projects using new technology due to risks
● The technology you are using allows for automated unit and functional tests

Extreme Programming (XP) is based on values. They are communication, simplicity, feedback,
courage, and respect and are described below.

● Simplicity: This is at the main idea of Extreme Programming. The methodology prefer simple
designs focusing on the requirements of today, while making the program flexible enough to
add the requirements in the future.

● Communication: XP does not depend on extensive documentation. The documentation is

suggested only when necessary. So the methodology relies heavily on communication between
team members and also with the users.

● Feedback: Teams can find areas for improvement through feedback about their previous efforts.
The team collects feedback on the design and implementation.

● Respect: Everyone gets the respect deserved as a valued team member. Management respects
our right to accept responsibility and receive authority over our own work to identify simple
designs and solutions.

● Courage: We're not documenting excuses for failure because we're planning to succeed. We're
not afraid of the work at hand, because no one works alone. We adapt to changes whenever
they happen.
The Rules of Extreme Programming

Planning

● User stories are written.

● Release planning creates the release schedule.
● Make frequent small releases.
● The project is divided into iterations.
● Iteration planning starts each iteration.

Managing

● Give the team a dedicated open work space.

● Set a sustainable pace.
● A stand-up meeting starts each day.
● The Project Velocity is measured.
● Move people around.
● Fix Extreme Programming when it breaks.

Designing

● Simplicity.
● Choose a system metaphor.
● Use CRC cards for design sessions.
● Create spike solutions to reduce risk.
● No functionality is added early.
● Refactor whenever and wherever possible.

Coding

● The customer is always available.

● Code must be written to agreed standards.
● Code the unit test first.
● All production code is pair programmed.
● Only one pair integrates code at a time.
● Integrate often.
● Set up a dedicated integration computer.
● Use collective ownership.

Testing

● All code must have unit tests.

● All code must pass all unit tests before it can be released.
● When a bug is found tests are created.
● Acceptance tests are run often and the score is published.
Extreme Programming Core Practices

Extreme Programming Methodology, which is used to execute software projects, comprises of

twelve basic principles, divided into four areas, drawn from the best practices in software
engineering. This chapter does not intend to describe core practices. Refere the following link, if
you are interested in understanding them.
https://basusourav.wordpress.com/2015/05/18/12-core-practices-of-xp/

3.3 Difference Between Agile and Traditional Models

One of the most challenging questions in software project management is “What way of
organizing the work of software development to choose?” This is all about selecting a proper
software development methodology.

This topic gets many discussions and hot debates as every software development project start
with the selection of implementation methods. In order to understand this, comparing waterfall
with agile would be a good starting point for undergraduate students. It is important that you
understand both of these approaches are usable and mature. The selection of a certain
methodology depends on the particular project and the company that performs it.

Watch the video titled “agile vs waterfall” available in

Moodle for more information.

Below table describes some differences in agile and waterfall.

Agile Waterfall

It separates the project development lifecycle Software development process is divided into
into sprints. distinct phases.
Follows an incremental approach Follows a sequential design process.

Agile is famous for its flexibility. Structured software development methodology.

Therefore, most times it can be rigid.

Changes to be made to the requirements even if There is no scope of changing the requirements
the initial planning has been completed. once the project development starts.

Follows an iterative development approach. Thus, All the project development phases like designing,
planning, development, prototyping and other development, testing, etc. are completed once in
software development phases may appear more the Waterfall model.
than once.

Requirements are expected to change and evolve. Suitable for projects which have definite
requirements and changes are not expected.

Introduces a product mindset where the software This model shows a project mindset and places its
product satisfies needs of its end users. focus completely on accomplishing the project.

Prefers small but dedicated teams with a high Team coordination/synchronization is very limited.
degree of coordination and synchronization.