Agile development

AGILE
DEVELOPMENT
UNIT 1
October
2021

CONTENTS
What is Agility ?
Agility and the Cost of change
What is an Agile Process ?
Extreme Programming
Other Agile Process Models
2

WHAT IS AGILITY ?
3
Agility has become today’s buzzword when describing a modern software
process. Everyone is agile. An agile team is a nimble team able to
appropriately respond to changes. Change is what software development is
very much about. Changes in the software being built, changes to the team
members, changes because of new technology, changes of all kinds that
may have an impact on the product they build or the project that creates the
product. Support for changes should be built-in everything we do in software,
something we embrace because it is the heart and soul of software. An agile
team recognizes that software is developed by individuals working in teams
and that the skills of these people, their ability to collaborate is at the core for
the success of the project.
Ivar Jacobson [Jac02a] provides a useful discussion:

4
An agile process reduces the agility and cost of change because software is
released in increments and change can be better controlled within an
increment.
AGILITY AND THE COST OF CHANGE
“Agility is dynamic, content specific, aggressively change embracing, and
growth oriented”
--Steven Goldman
Quote

5
Agility argue that a well designed agile process “flattens” the cost of change
curve shown in following figure, allowing a software team to accommodate
changes late in a software project without dramatic cost and time impact.

6
When incremental delivery is coupled with other agile practices such as
continuous unit testing and pair programming, the cost of making a change is
attenuated.
An agile process reduces the cost of change because software is released in
increments and change can be better controlled within an increment.
Key Point

7
Any agile software process is characterized in a manner that addresses a
number of key assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist
and which will change. It is equally difficult to predict how customer priorities
will change as the project proceeds.
WHAT IS AN AGILE PROCESS ?
Although agile prosses embrace change, it is still important to examine the
reasons for change.
Key Point

8
2. For many types of software, design and construction are interleaved. That
is, both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to predict how much design is
necessary before construction is used to prove the design.
Working software is important, but don’t forget that it must also exhibit a
variety of quality attributes including reliability, usability, and maintainability.
Advice

9
3. Analysis, design, construction, and testing are not as predictable

10
The Agile Alliance defines 12 agility principles for those who want to achieve
agility:
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
WHAT IS AN AGILE PROCESS ?:
Agility Principles

11
agility:
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to
and within a development team is face to face conversation.
7. Working software is the primary measure of progress.
Agility Principles

12
agility:
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity the art of maximizing the amount of work not done is
essential.
Agility Principles

13
agility:
11. The best architectures, requirements, and designs emerge from self
organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Agility Principles

14
Extreme Programming(XP) is the most widely used approach to agile
software development.
 A variant of XP, called Industrial XP(IXP) refines XP and targets the agile
process specifically for use within large organizations.
EXTREME PROGRAMMING

15
Extreme Programming uses an object-oriented approach as its preferred
development paradigm and encompasses a set of rules and practices that
occur within the context of four framework activities: planning, design,
coding, and testing.
EXTREME PROGRAMMING:
The XP Process
Project velocity is a subtle measure of team productivity.
Key Point

16
The XP Process
Above figure illustrates the XP process and notes some of the
key ideas and tasks that are associated with each framework
activity.
The Extreme
Programming
process

17
The XP Process
• The planning activity (also called the planning game) begins with
listening—a requirements gathering activity that enables the technical
members of the XP team to understand the business context for the
software and to get a broad feel for required output and major features
and functionality.
• Listening leads to the creation of a set of “stories” (also called user
stories) that describe required output, features, and functionality for
software to be built.
• Each story (similar to use cases) is written by the customer and is placed
on an index card.
• The customer assigns a value (i.e., a priority) to the story based on the
Planning

18
The XP Process
• Members of the XP team then assess each story and assign a cost—
measured in development weeks—to it.
• If the story is estimated to require more than three development weeks,
the customer is asked to split the story into smaller stories and the
assignment of value and cost occurs again.
• It is important to note that new stories can be written at any time.
• Customers and developers work together to decide how to group stories
into the next release (the next software increment) to be developed by the
XP team.
Planning

19
The XP Process
• Once a basic commitment (agreement on stories to be included, delivery
date, and other project matters) is made for a release, the XP team orders
the stories that will be developed in one of three ways:
(1) all stories will be implemented immediately (within a few weeks),
(2) the stories with highest value will be moved up in the schedule
and
implemented first, or
(3) the riskiest stories will be moved up in the schedule and
implemented first.
Planning

20
The XP Process
• After the first project release (also called a software increment) has been
delivered, the XP team computes project velocity. Stated simply, project
velocity is the number of customer stories implemented during the first
release.
• Project velocity can then be used to
(1) help estimate delivery dates and schedule for subsequent releases
(2) determine whether an overcommitment has been made for all stories
across the entire development project.
Planning

21
The XP Process
• If an overcommitment occurs, the content of releases is modified or end
delivery dates are changed.
• As development work proceeds, the customer can add stories, change
the value of an existing story, split stories, or eliminate them. The XP team
then reconsiders all remaining releases and modifies its plans
accordingly.
Planning

22
The XP Process
• XP design rigorously follows the KIS (keep it simple) principle. A simple
design is always preferred over a more complex representation.
• In addition, the design provides implementation guidance for a story as it is
written—nothing less, nothing more.
• The design of extra functionality (because the developer assumes it will be
required later) is discouraged.
Design

23
The XP Process
• If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that
portion of the design. Called a spike solution, the design prototype is
implemented and evaluated.
• The intent is to lower risk when true implementation starts and to validate the
original estimates for the story containing the design problem.
Design

24
The XP Process
• After stories are developed and preliminary design work is done, the team
does not move to code, but rather develops a series of unit tests that will
exercise each of the stories that is to be included in the current release
(software increment)
• Once the unit test has been created, the developer is better able to focus on
what must be implemented to pass the test.
• Once the code is complete, it can be unit-tested immediately, thereby
providing instantaneous feedback to the developers.
• XP recommends that two people work together at one computer workstation
to create code for a story.
Coding

25
The XP Process
• As pair programmers complete their work, the code they develop is integrated
with the work of others.
• In some cases this is performed on a daily basis by an integration team.
• In other cases, the pair programmers have integration responsibility.
• This “continuous integration” strategy helps to avoid compatibility and
interfacing
problems and provides a “smoke testing” environment that helps to uncover
errors
early.
Coding

26
The XP Process
• The unit tests that are created should be implemented using a framework that
enables them to be automated (hence, they can be executed easily and
repeatedly).
• This encourages a regression testing strategy whenever code is modified
(which is often, given the XP refactoring philosophy).
• As the individual unit tests are organized into a “universal testing suite”
[Wel99], integration and validation testing of the system can occur on a daily
basis.
• This provides the XP team with a continual indication of progress and also
can raise warning flags early if things go awry.
Testing

27
The XP Process
• Wells [Wel99] states: “Fixing small problems every few hours takes less time
than fixing huge problems just before the deadline.”
• XP acceptance tests, also called customer tests, are specified by the
customer and focus on overall system features and functionality that are
visible and reviewable by the customer.
• Acceptance tests are derived from user stories that have been implemented
as part of a software release.
Testing

28
Industrial XP
Joshua Kerievsky [Ker05] describes Industrial Extreme Programming (IXP) in
the following manner:
“IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-
centric, test-driven spirit. IXP differs most from the original XP in its greater
inclusion of management, its expanded role for customers, and its upgraded
technical practices.”

29
Industrial XP
IXP incorporates six new practices that are designed to help ensure that an XP
project works successfully for significant projects within a large organization.
Readiness assessment: Prior to the initiation of an IXP project, the organization
should conduct a readiness assessment.
(1) an appropriate development environment exists to support IXP
(2) the team will be populated by the proper set of stakeholders.
(3) the organization has a distinct quality program and supports
continuous improvement.

30
Industrial XP
Readiness assessment: Prior to the initiation of an IXP project, the organization
should conduct a readiness assessment.
(4) the organizational culture will support the new values of an
agile team
(5) the broader project community will be populated appropriately.

31
Industrial XP
Project community: Classic XP suggests that the right people be used to
populate the agile team to ensure success.
The implication is that people on the team must be well-trained, adaptable and
skilled, and have the proper temperament to contribute to a self-organizing
team.
When XP is to be applied for a significant project in a large organization, the
concept of the “team” should morph into that of a community.

32
Industrial XP
Project community: A community may have a technologist and customers who
are central to the success of a project as well as many other stakeholders (e.g.,
legal staff, quality auditors, manufacturing or sales types) who “are often at the
periphery of an IXP project yet they may play important roles on the project”
[Ker05].
In IXP, the community members and their roles should be explicitly defined and
mechanisms for communication and coordination between community members
should be established.

33
Industrial XP
Project chartering: The IXP team assesses the project itself to determine
whether an appropriate business justification for the project exists and
whether the project will further the overall goals and objectives of the
organization. Chartering also examines the context of the project to determine
how it complements, extends, or replaces existing systems or
processes..

34
Industrial XP
Test-driven management: An IXP project requires measurable criteria for
assessing the state of the project and the progress that has been made to
date. Test-driven management establishes a series of measurable “destinations”
[Ker05] and then defines mechanisms for determining whether or not
these destinations have been reached.

35
Industrial XP
Retrospectives: An IXP team conducts a specialized technical review after a
software increment is delivered. Called a retrospective, the review examines
“issues, events, and lessons-learned” [Ker05] across a software increment
and/or the entire software release. The intent is to improve the IXP process.

36
Industrial XP
Continuous learning: Because learning is a vital part of continuous
process improvement, members of the XP team are encouraged (and possibly,
incented) to learn new methods and techniques that can lead to a higherquality
product.

37
Industrial XP
• Story-driven development (SDD) insists that stories for acceptance tests
be written before a single line of code is generated.
• Domain-driven design (DDD) is an improvement on the “system metaphor”
concept used in XP.
• DDD [Eva03] suggests the evolutionary creation of a domain model that
“accurately represents how domain experts think about their subject” [Ker05].

38
Industrial XP
• Pairing extends the XP pair programming concept to include managers and
other stakeholders.
• The intent is to improve knowledge sharing among XP team members who
may not be directly involved in technical development.
• Iterative usability discourages front-loaded interface design in favor of
usability design that evolves as software increments are delivered and users’
interaction with the software is studied.

39
OTHER AGILE PROCESS MODELS:
Adaptive Software Development (ASD)
Adaptive Software Development (ASD) has been proposed by Jim Highsmith
[Hig00] as a technique for building complex software and systems.
The philosophical underpinnings of ASD focus on human collaboration and team
self-organization.

40
Adaptive Software Development (ASD)

41
Scrum
Scrum (the name is derived from an activity that occurs during a rugby match13)
is an agile software development method that was conceived by Jeff Sutherland
and his development team in the early 1990s.
Scrum incorporates a set of process patterns that emphasize project priorities,
Compartmentalized work units, communication, and frequent customer
feedback.
Key point

42
Scrum
Within each framework activity, work tasks occur within a process pattern
(discussed in the following paragraph) called a sprint.
The work conducted within a sprint (the number of sprints required for each
framework activity will vary depending on product complexity and size) is
adapted to the problem at hand and is defined and often modified in real time by
the Scrum team.

43
Scrum

44
Scrum
Backlog—a prioritized list of project requirements or features that provide
business value for the customer. Items can be added to the backlog at any
time (this is how changes are introduced).
The product manager assesses the backlog and updates priorities as
required.

45
Scrum
Sprints—consist of work units that are required to achieve a requirement
defined in the backlog that must be fit into a predefined time-box14
(typically 30 days).
Changes (e.g., backlog work items) are not introduced during the sprint.
Hence, the sprint allows team members to work in a short-term, but stable
environment.

46
Scrum
Scrum meetings—are short (typically 15 minutes) meetings held daily by
the Scrum team.
Three key questions are asked and answered by all team members
[Noy02]:
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?

47
Scrum
A team leader, called a Scrum master, leads the meeting and assesses the
responses from each person. The Scrum meeting helps the team to
uncover potential problems as early as possible. Also, these daily meetings
lead to “knowledge socialization” [Bee99] and thereby promote a self-
organizing team structure.

48
Scrum
Demos—deliver the software increment to the customer so that
functionality that has been implemented can be demonstrated and
evaluated by the customer.
It is important to note that the demo may not contain all planned
functionality, but rather those functions that can be delivered within the
time-box that was established.

49
Scrum
Beedle and his colleagues [Bee99] present a comprehensive discussion of
these patterns in which they state: “Scrum assumes up-front the existence
of chaos. . . . ”
The Scrum process patterns enable a software team to work successfully in
a world where the elimination of uncertainty is impossible.

50
Dynamic Systems Development Method (DSDM)
The Dynamic Systems Development Method (DSDM) [Sta97] is an agile
software development approach that “provides a framework for building and
maintaining systems which meet tight time constraints through the use of
incremental prototyping in a controlled project environment” [CCS02].
DSDM is a process framework that can adopt the tactics of another agile approach
such as XP.
Key point

51
• The DSDM Consortium (www.dsdm.org) is a worldwide group of member
companies that collectively take on the role of “keeper” of the method.
• The consortium has defined an agile process model, called the DSDM
life cycle that defines three different iterative cycles, preceded by two
additional life cycle activities:
Feasibility study—establishes the basic business requirements and
constraints associated with the application to be built and then assesses
whether the application is a viable candidate for the DSDM process.

52
Business study—establishes the functional and information requirements
that will allow the application to provide business value; also, defines the
basic application architecture and identifies the maintainability
requirements for the application.
Functional model iteration—produces a set of incremental prototypes that
demonstrate functionality for the customer. (Note: All DSDM prototypes are
intended to evolve into the deliverable application.) The intent during this
iterative cycle is to gather additional requirements by eliciting feedback
from users as they exercise the prototype.

53
Design and build iteration—revisits prototypes built during functional model
iteration to ensure that each has been engineered in a manner that will
enable it to provide operational business value for end users. In some
cases, functional model iteration and design and build iteration occur
concurrently.
Implementation—places the latest software increment (an “operationalized”
prototype) into the operational environment. It should be noted that (1) the
increment may not be 100 percent complete or (2) changes may be
requested as the increment is put into place. In either case, DSDM
development work continues by returning to the functional model iteration
activity.

54
DSDM can be combined with XP to provide a combination approach that
defines a solid process model (the DSDM life cycle) with the nuts and bolts
practices (XP) that are required to build software increments.
In addition, the ASD concepts of collaboration and self-organizing teams
can be adapted to a combined process model.

55
Crystal
Alistair Cockburn [Coc05] and Jim Highsmith [Hig02b] created the Crystal
family of agile methods15 in order to achieve a software development
approach that puts a premium on “maneuverability” during what Cockburn
characterizes as “a resource limited, cooperative game of invention and
communication, with a primary goal of delivering useful, working software
and a secondary goal of setting up for the next game” [Coc02].
Crystal is a family of process models with the same “genetic code” but different methods for
adapting to project characteristics.
Key point

56
Crystal
• To achieve maneuverability, Cockburn and Highsmith have defined a set
of methodologies, each with core elements that are common to all, and
roles, process patterns, work products, and practice that are unique to
each.
• The Crystal family is actually a set of example agile processes that have
been proven effective for different types of projects.
• The intent is to allow agile teams to select the member of the crystal
family that is most appropriate for their project and environment.

57
Feature Driven Development (FDD)
Feature Driven Development (FDD) was originally conceived by Peter
Coad and his colleagues [Coa99] as a practical process model for object-
oriented software engineering.
Stephen Palmer and John Felsing [Pal02] have extended and improved
Coad’s work, describing an adaptive, agile process that can be applied to
moderately sized and larger software projects.

58
FDD adopts a philosophy that
(1) emphasizes collaboration among people on an FDD team;
(2) manages problem and project complexity using feature-based
decomposition followed by the integration of software increments.
(3) communication of technical detail using verbal, graphical, and text-
based means.
FDD emphasizes software quality assurance activities by encouraging an
incremental development strategy, the use of design and code inspections,
the application of software quality assurance audits, the collection of
metrics, and the use of patterns (for analysis, design, and construction).

59
In the context of FDD, a feature “is a client-valued function that can be
implemented in two weeks or less” [Coa99]. The emphasis on the definition
of features provides the following benefits:
• Because features are small blocks of deliverable functionality, users
can describe them more easily; understand how they relate to one
another more readily; and better review them for ambiguity, error, or
omissions.
• Features can be organized into a hierarchical business-related
grouping.
• Since a feature is the FDD deliverable software increment, the team
develops operational features every two weeks.

60
The emphasis on the definition of features provides the following benefits:
• Because features are small, their design and code representations
are easier to inspect effectively.
• Project planning, scheduling, and tracking are driven by the feature
hierarchy, rather than an arbitrarily adopted software engineering
task set.

61
Coad and his colleagues [Coa99] suggest the following template for
defining a feature:
<action> the <result> <by for of to> a(n) <object>
where an <object> is “a person, place, or thing (including roles, moments in
time or intervals of time, or catalog-entry-like descriptions).”
Examples of features for an e-commerce application might be:
Add the product to shopping cart
Display the technical-specifications of the product
Store the shipping-information for the customer

62

63
A feature set groups related features into business-related categories
and is defined [Coa99] as:
<action><-ing> a(n) <object>
For example: Making a product sale is a feature set that would
encompass the features noted earlier and others.

64
FDD provides greater emphasis on project management guidelines and
techniques than many other agile methods.
As projects grow in size and complexity, ad hoc project management is
often inadequate.
It is essential for developers, their managers, and other stakeholders to
understand project status—what accomplishments have been made and
problems have been encountered.
If deadline pressure is significant, it is critical to determine if software
increments (features) are properly scheduled.
To accomplish this, FDD defines six milestones during the design and
implementation of a feature: “design walkthrough, design, design
inspection, code, code inspection, promote to build” [Coa99].

65
Lean Software Development (LSD)
Lean Software Development (LSD) has adapted the principles of lean
manufacturing to the world of software engineering.
The lean principles that inspire the LSD process can be summarized
([Pop03], [Pop06a]) as eliminate waste, build quality in, create
knowledge, defer commitment, deliver fast, respect people, and optimize
the whole.

66
Each of these principles can be adapted to the software process. For
example,
eliminate waste within the context of an agile software project can be
interpreted to mean [Das05]:
(1) adding no extraneous features or functions,
(2) assessing the cost and schedule impact of any newly requested
requirement,
(3) removing any superfluous process steps,
(4) establishing mechanisms to improve the way team members find
information,

67
Each of these principles can be adapted to the software process. For
example,
eliminate waste within the context of an agile software project can be
interpreted to mean [Das05]:
(5) ensuring the testing finds as many errors as possible,
(6) reducing the time required to request and get a decision that affects
the software or the process that is applied to create it, and
(7) streamlining the manner in which information is transmitted to all
stakeholders involved in the process.

68
Agile Modeling
The Official Agile Modeling Site,” Scott Ambler [Amb02a] describes agile
modeling (AM) in the following manner:
Agile Modeling (AM) is a practice-based methodology for effective
modeling and documentation of software-based systems. Simply put,
Agile Modeling (AM) is a collection of values, principles, and practices for
modeling software that can be applied on a software development
project in an effective and light-weight manner. Agile models are more
effective than traditional models because they are just barely good, they
don’t have to be perfect.

69
Agile Modeling
The Official Agile Modeling Site,” Scott Ambler [Amb02a] describes agile
modeling (AM) in the following manner:
Agile Modeling (AM) is a practice-based methodology for effective
modeling and documentation of software-based systems. Simply put,
Agile Modeling (AM) is a collection of values, principles, and practices for
modeling software that can be applied on a software development
project in an effective and light-weight manner. Agile models are more
effective than traditional models because they are just barely good, they
don’t have to be perfect.
“I was in the drug store the other day trying to get a cold medication . . . Not easy. There’s an
entire wall of products you need. You stand there going, Well, this one is quick acting but this is long
lasting. . . . Which is more important, the present or the future?”
Jerry Seinfeld

70
Agile Modeling
AM suggests a wide array of “core” and “supplementary” modeling
principles,
those that make AM unique are [Amb02a]:
Model with a purpose: A developer who uses AM should have a specific
goal (e.g., to communicate information to the customer or to help better
understand some aspect of the software) in mind before creating the
model. Once the goal for the model is identified, the type of notation to be
used and level of detail required will be more obvious.

71
Agile Modeling
principles,
Use multiple models. There are many different models and notations that
can be used to describe software. Only a small subset is essential for
most projects. AM suggests that to provide needed insight, each model
should present a different aspect of the system and only those models
that provide value to their intended audience should be used.

72
Agile Modeling
principles,
Travel light. As software engineering work proceeds, keep only those
models that will provide long-term value and jettison the rest. Every work
product that is kept must be maintained as changes occur. This
represents work that slows the team down. Ambler [Amb02a] notes that
“Every time you decide to keep a model you trade-off agility for the
convenience of having that information available to your team in an
abstract manner (hence potentially enhancing communication within your
team as well as with project stakeholders).”

73
Agile Modeling
principles,
Content is more important than representation. Modeling should impart
information to its intended audience. A syntactically perfect model that
imparts little useful content is not as valuable as a model with flawed
notation that nevertheless provides valuable content for its audience.
Know the models and the tools you use to create them. Understand
the strengths and weaknesses of each model and the tools that are used
to create it.
Adapt locally. The modeling approach should be adapted to the needs of
the agile team.

74
Agile Unified Process(AUP)
The Agile Unified Process (AUP) adopts a “serial in the large” and
“iterative in the small” [Amb06] philosophy for building computer-based
systems.
By adopting the classic UP phased activities—inception, elaboration,
construction, and transition—AUP provides a serial overlay (i.e., a linear
sequence of software engineering activities) that enables a team to
visualize the overall process flow for a software project. However,
within each of the activities, the team iterates to achieve agility and to
deliver meaningful software increments to end users as rapidly as
possible.

75
Each AUP iteration addresses the following activities [Amb06]:
• Modeling. UML representations of the business and problem domains
are created. However, to stay agile, these models should be “just barely
good enough” [Amb06] to allow the team to proceed.
• Implementation. Models are translated into source code.
• Testing. Like XP, the team designs and executes a series of tests to
uncover errors and ensure that the source code meets its requirements.
• Deployment. Like the generic process activity deployment in this context
focuses on the delivery of a software increment and the acquisition of
feedback from end users.

76
Each AUP iteration addresses the following activities [Amb06]:
• Configuration and project management. In the context of AUP,
configuration management addresses change management, risk
management, and the control of any persistent work products that are
produced by the team. Project management tracks and controls the
progress of the team and coordinates team activities.
• Environment management. Environment management coordinates a
process infrastructure that includes standards, tools, and other support
technology available to the team.

77
REFRENCES
Software Engineering A Practioner’s Approach by Roger S Pressman

THANK
YOU!
JOSHUA U
Phone
678-555-0128
Email
Joshua537.nit@gmail.com

Agile development

More Related Content

What's hot (20)

Similar to Agile development (20)

Recently uploaded (20)

Agile development