Chapter 3

 Agile Development
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim

Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman

1
What is “Agility”?
 Effective (rapid and adaptive) response to change
 Effective communication among all stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of the work
performed
Yielding …
 Rapid, incremental delivery of software

2
Agility and the Cost of Change

The cost of change increases nonlinearly as the project progresses

3
 When we choose Agile?
 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.

 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.

 Analysis, design, construction, and testing are not as

predictable (from a planning point of view) as we might like.

4
An Agile Process
 Is driven by customer descriptions of what is
required (scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a heavy
emphasis on construction activities
 Delivers multiple ‘software increments’
 Adapts as changes occur

5
 Agility Principles
 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.
 4. Business people and developers must work together
daily throughout the project.

6
 Agility Principles
 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.
 8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.

7
 Agility Principles
 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.

 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. 8
 Extreme Programming (XP)
 The most widely used agile process, originally proposed by
Kent Beck
 focuses on improving software quality and responsiveness
to changing customer requirements through frequent
releases, customer feedback, and technical excellence.
 XP Planning
 Begins with the creation of “user stories”
 Agile team assesses each story and assigns a cost
 Stories are grouped to for a deliverable increment
 A commitment is made on delivery date
 After the first increment “project velocity” is used to help define
subsequent delivery dates for other increments
9
Extreme Programming (XP)

10
Extreme Programming (XP)
 XP Design
 Follows the KISS principle
 Encourage the use of Class-responsibility-collaboration
CRC cards (see Chapter 8)
 For difficult design problems, suggests the creation of
“spike solutions”—a design prototype
 Encourages “refactoring”—an iterative refinement of the
internal program design
 XP Coding
 Recommends the construction of a unit test for a store
before coding commences
 Encourages “pair programming”
 XP Testing
 All unit tests are executed daily
 “Acceptance tests” are defined by the customer and
executed to assess customer visible functionality
11
 Core Values of XP
XP is built on five core values that guide its practices:
• Communication: Developers and customers work closely together to
ensure there’s a constant flow of information, feedback, and alignment.
• Simplicity: Focus on designing and building the simplest solution that
works. This helps avoid over-engineering and encourages easier
maintenance.
• Feedback: Frequent feedback loops through customer involvement and
testing ensure that the project is on track and that potential issues are
addressed early.
• Courage: Developers are encouraged to take risks, refactor code, and
suggest improvements, even if it means changing the design
significantly.
• Respect: Team members respect each other’s skills and opinions,
creating a collaborative and supportive environment.
12
 Key Features of XP
 Test-Driven Development (TDD): Developers write
automated tests before writing the code to pass the tests. This
ensures that code is constantly tested and refactored. It helps
reduce bugs and maintain quality.
 Pair Programming: Two developers work together at one
workstation. One writes code (the driver), while the other
reviews the work and offers suggestions (the observer). This
helps with knowledge sharing and produces higher-quality
code.
 Continuous Integration: Code is integrated and tested
frequently, often multiple times a day. This helps detect
integration issues early and avoids the pain of "integration hell."
13
 Key Features of XP
 Refactoring: Developers continually improve the codebase,
removing duplication and improving clarity, without changing
the external behavior of the system.
 Small Releases: Features are developed in small,
incremental releases. This allows the team to receive
constant feedback from the customer, making it easier to
adjust the product based on their needs.
 On-Site Customer: An XP team works closely with a
customer representative who is always available to provide
feedback, prioritize features, and clarify requirements.

14
Benefits of Extreme Programming
 High Code Quality: Continuous testing, refactoring, and
pair programming result in cleaner, more maintainable code.
 Flexibility: XP allows for changes at any stage in the
development process, which is ideal for projects with
evolving requirements.
 Faster Delivery: Through small, frequent releases and
constant customer feedback, XP enables quicker delivery of
working software.
 Customer Satisfaction: Close collaboration with the
customer ensures that their needs are constantly addressed,
leading to higher satisfaction.

15
Benefits of Extreme Programming
 Requires Highly Skilled Developers: XP relies heavily on
best practices like TDD and pair programming, which may
be difficult for teams not accustomed to them.

 Customer Involvement: XP demands frequent involvement

from the customer, which can be challenging for clients who
aren’t available or willing to collaborate regularly.

 Hard to Scale: XP is best suited for small to medium-sized

teams, and scaling it to large teams can be complex due to
the need for constant communication and close
collaboration.
16
Adaptive Software Development (ASD)
 Adaptive Software Development (ASD) is a software
development methodology that emphasizes flexibility,
collaboration, and adaptation to change.

 It was created to address the challenges faced by

traditional software development methodologies in
handling rapidly changing requirements and environments.

 ASD is often associated with Agile practices, as it

prioritizes responsiveness and iterative development,
aiming to produce software that can evolve based on
continuous feedback.
17
 Principle of ASD
Principle of Adaptation
 ASD is built on the principle that change is a natural and
inevitable part of the software development process.
 Unlike traditional methods that often try to minimize or
control change through detailed planning, ASD embraces
change and allows the development process to be
adaptive and responsive to evolving requirements.
 The idea is that the development process should evolve
along with the product, ensuring that the software always
meets the current needs and expectations.

18
 Phases of ASD
Speculation (Planning)
 In this phase, the initial requirements and design concepts
are loosely defined. Instead of detailed upfront planning,
the team speculates about the direction the project will
take, forming early hypotheses and making educated
guesses about the functionality.

 The goal is to set the initial vision for the product and
identify potential challenges, but without locking into a rigid
plan.

19
 Phases of ASD
Collaboration (Development and Design)
 This phase is about collaboration among all team members
(including developers, testers, and customers) to develop
the software incrementally.
 During this phase, prototypes or working versions of the
software are created, and feedback is gathered from the
customer or end-users. The team works closely together to
iteratively refine the product based on this feedback.
 The team constantly adjusts the design and code based on
the feedback received from earlier iterations.

20
 Phases of ASD
Learning (Reflection and Feedback)
 After each iteration, the team reflects on their progress and
learns from the work done. This phase involves evaluation
and reflection, where the team gathers insights from what
worked well and what didn't.
 The team uses this learning to improve both the product
and the process. The cycle of learning ensures that the
software evolves and gets better with each iteration.
 Customers also contribute to this phase by providing
feedback, helping the team refine their approach and make
necessary adjustments to the project.

21
Phases of ASD

22
 Benefits of ASD
 Responsiveness to Change: Because ASD embraces change,
it allows teams to better handle dynamic requirements and shifts
in customer needs or market conditions.
 Customer Satisfaction: Active customer involvement ensures
that the final product aligns closely with user needs, leading to
higher satisfaction.
 Early Delivery: By delivering functional software in increments,
ASD enables faster delivery of usable features to the customer,
with continuous improvement.
 Reduced Risk: By focusing on collaboration, early prototyping,
and feedback, risks can be identified and mitigated early, rather
than later in the project.

23
 Challenges of ASD
 High Customer Involvement: Continuous collaboration
requires a customer who is available and engaged throughout
the development process. This can be a challenge for some
organizations, especially if the customer is not fully committed.
 Scope Creep: Since requirements are expected to change
frequently, managing the scope can become challenging.
Teams must carefully manage customer expectations to avoid
the project growing beyond its original goals.
 Skill Level of Team: ASD requires teams that are skilled in
agile techniques, collaborative work, and handling uncertainty.
Without the proper skillset, it can be difficult to maintain the
flexible and adaptive approach that ASD demands.

24
 Difference between XP and ASD
Adaptive Software Development
Aspect Extreme Programming (XP)
(ASD)
Flexibility and adaptation to change, Technical excellence, practices, and
Focus
overall process evolution. software quality.
Approach to Evolving requirements; focus on Requirements evolve with customer
Requirements speculation and collaboration. feedback but driven by tests.
High customer involvement;
Customer Frequent, but more advisory and
customer is an integral part of the
Involvement collaborative.
team.
Strong focus on technical practices
Technical More flexible and process-focused; does
like TDD, pair programming, and
Practices not prescribe specific practices.
continuous integration.
High collaboration with a focus on
Team
Focus on collaboration and learning. shared code ownership and pair
Collaboration
programming.
Focus on risk-driven development and Focus on technical risk
Risk and
evolution of both the product and the management and ensuring quality
Adaptation
process. through practices. 25
 Sample Questions
 How do the roles of customers differ in XP and ASD? Which
methodology demands more customer interaction, and in
what ways does this impact the development process?

 How does each methodology approach the identification

and management of risks early in the project?

26
 Scrum
 The name is derived from an activity that occurs during a
rugby match where A group of players forms around the
ball and the teammates work together (sometimes
violently!) to move the ball downfield.

 Scrum is an agile process framework used for managing

complex software and product development.

 It's built around a small, self-organizing team that works

collaboratively to deliver valuable software incrementally.

27
 Scrum Roles
Product Owner
 The Product Owner represents the interests of the
stakeholder community in front of the Scrum Team, to
which he must clearly communicate the functionality
requirements of the product.

 They manage the Product Backlog, prioritizing features

and ensuring everyone understands the "what" and "why"
of the product.

 Think of them as the voice of the customer.

28
 Scrum Roles
Scrum Master
 The Scrum Master acts as a servant-leader for the
Development Team.

 They facilitate the Scrum process, remove impediments

that hinder the team's progress, and ensure the team
adheres to Scrum practices.

 They are not a project manager in the traditional sense but

rather a coach and facilitator.
29
 Scrum Roles
Development Team
 This is a self-organizing and cross-functional group of
professionals who do the actual work of designing,
developing, testing, and delivering the product increment.

 They decide how to best accomplish their work within the

constraints of each Sprint.

 It is suggested that the team should be small (typically 3-9

people) and have all the skills necessary to deliver a
working increment.
30
Scrum Roles

31
Scrum Roles

32
 Scrum framework
 Scrum principles are consistent with the agile manifesto
and are used to guide development activities within a
process that incorporates the following framework
activities:
I. Requirements gathering,
II. analysis,
III. design,

IV. evolution, and

V. delivery.

33
 Scrum framework
 Within each framework activity, work tasks occur within a
process pattern 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

34
 Backlog
 A prioritized list of all the features, enhancements, bug
fixes, and other work that needs to be done on the product.
It's a living document that evolves as the product and
requirements change.

 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.

35
 Sprint
 The heart of Scrum, a Sprint is a short, time-boxed iteration
(typically 2-4 weeks) during which the Development Team
works to produce a potentially shippable increment of the
product.

 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.

36
 Sprint Meeting
 Meetings are short (typically 15 minutes) meetings held
daily by the Scrum team.

 Three key questions are asked and answered by all team

members:
I. What did you do since the last team meeting?
II. What obstacles are you encountering?
III. What do you plan to accomplish by the next team
meeting?

37
 Scrum Master
 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” and thereby promote a self-organizing team
structure.

38
 Sprint Review
 Held at the end of the Sprint, this is an informal meeting
where the Development Team presents the increment they
have built to the Product Owner and stakeholders.

 The focus is on gathering feedback and making necessary

adjustments to the Product Backlog

39
 Sprint Retrospective
 This meeting also takes place at the end of the Sprint. The
Scrum Team (Product Owner, Scrum Master, and
Development Team) reflects on the past Sprint and
identifies what went well, what could be improved, and
what changes they will implement in the next Sprint.

 This fosters continuous improvement.

40
Scrum Framework

41
 Sprint Advantages
 Highly Adaptive: Scrum excels at responding to changing
needs and delivering value incrementally.

 Strong Collaboration & Quality: Teamwork and frequent

feedback lead to better products.

 Faster Delivery & Customer Focus: Value is delivered

quickly and aligns with stakeholder needs.

 Empowered Teams & Continuous Improvement: Self-

organization and reflection boost motivation and efficiency.
42
 Sprint Challenges
 Relies on Mature Teams: Requires committed and
capable individuals for success.
 Potential for Scope Issues: Flexibility can lead to
uncontrolled changes if not managed well.
 Scaling Can Be Complex: Implementing Scrum
effectively in large or intricate projects presents challenges.
 Demands Discipline & Commitment: Adherence to the
framework is crucial.
 Not a Universal Solution: May not be the best fit for all
project types.

43