Lecture 3 –

Agility and Process

Tuesday, January 24, 2023
Rapid software development
• Rapid development and delivery is now often the most
important requirement for software systems
• Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements
• Software has to evolve quickly to reflect changing business needs.
• Rapid software development
• Specification, design and implementation are inter-leaved
• System is developed as a series of versions with stakeholders
involved in version evaluation
• User interfaces are often developed using an IDE and graphical
toolset.
2
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

3
Agility and the Cost of Change

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
Agile methods
• Dissatisfaction with the overheads involved in software design
methods of the 1980s and 1990s led to the creation of agile
methods. These methods:
• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this quickly to
meet changing requirements.
• The aim of agile methods is to reduce overheads in the software
process (e.g. by limiting documentation) and to be able to respond
quickly to changing requirements without excessive rework.

6
The principles of agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the development
process. Their role is provide and prioritize new system requirements
and to evaluate the iterations of the system.

Incremental delivery The software is developed in increments with the customer specifying
the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own ways of
working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the system
to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in the
development process. Wherever possible, actively work to eliminate
complexity from the system.

7
SCRUM
SCRUM
• Scrum (the name is derived from an activity
that occurs during a rugby match) is a very
popular agile software development
method that was conceived by Jeff
Sutherland and his development team in
the early 1990s

• Further development on the Scrum

methods was performed by Ken Schwaber
SCRUM
• Scrum principles are consistent with the agile manifesto and are
used to guide development activities within a process that
incorporates the following framework activities: requirements,
analysis, design, evolution, and delivery.
• Within each framework activity, work tasks take place in a relatively
short time-boxed period called a sprint.
• The work conducted within a sprint (the number of sprints required
for each framework activity will vary depending on size of the
product and its complexity) is adapted to the problem at hand and
is defined and often modified in real time by the Scrum team.
SCRUM Framework
• Scrum is a framework within which people can address
complex adaptive problems, while productively and
creatively delivering products of the highest possible
value.
SCRUM Pillars
Transparency
• The emergent process and work must be visible to
those performing the work as well as those receiving the
work. With Scrum, important decisions are based on the
perceived state of its three formal artifacts. Artifacts that
have low transparency can lead to decisions that
diminish value and increase risk.

• Transparency enables inspection. Inspection without

transparency is misleading and wasteful.
SCRUM Pillars
Inspection
• The Scrum artifacts and the progress toward agreed
goals must be inspected frequently and diligently to
detect potentially undesirable variances or problems.
To help with inspection, Scrum provides cadence
(framework) in the form of its five events.

• Inspection enables adaptation. Inspection without

adaptation is considered pointless. Scrum events are
designed to provoke change.
SCRUM Pillars
Adaptation
• If any aspects of a process deviate outside acceptable limits or
if the resulting product is unacceptable, the process being
applied or the materials being produced must be adjusted.
The adjustment must be made as soon as possible to
minimize further deviation.

• Adaptation becomes more difficult when the people involved

are not empowered or self-managing. A Scrum Team is
expected to adapt the moment it learns anything new
through inspection.
SCRUM Artifacts
• In software development, the term “artifact” refers to
information that stakeholders and the scrum team use
to describe a product that's being developed.
• Scrum’s artifacts represent work or value. They are
designed to maximize transparency of key information
• Each artifact contains a commitment to ensure it provides
information that enhances transparency and focus against
which progress can be measured:
• For the Product Backlog it is the Product Goal.
• For the Sprint Backlog it is the Sprint Goal.
• For the Increment it is the Definition of Done
SCRUM Artifacts
• The product backlog is a prioritized list of product
requirements or features that provide business value
for the customer
• Items can be added to the backlog at any time with the
approval of the product owner and the consent of the
development team
• The product owner orders the items in the product
backlog to meet the most important goals of all
stakeholders
SCRUM Artifacts
• The Sprint Backlog is composed of the Sprint Goal
(why), the set of Product Backlog items selected for the
Sprint (what), as well as an actionable plan for
delivering the Increment (how)

• The Sprint Backlog is plan by and for the Developers. It is

a highly visible, real-time picture of the work that the
Developers plan to accomplish during the Sprint in order
to achieve the Sprint Goal
SCRUM Artifacts
• An Increment is a concrete stepping stone toward the
Product Goal
• Each Increment is additive to all prior Increments and
thoroughly verified, ensuring that all Increments work
together
• The union of all product backlog items completed in previous
sprints and all backlog items to be completed in the current
sprints
• The Definition of Done is a formal description of the state of the
Increment when it meets the quality measures required for the
product.
SCRUM Team
• The Scrum Team consists of one Scrum Master, one
Product Owner, and Developers (three to six people).
• Within a Scrum Team, there are no sub-teams or
hierarchies. It is a cohesive unit of professionals focused
on one objective at a time, the Product Goal.
• Scrum Teams are cross-functional (interdisciplinary),
meaning the members have all the skills necessary to
create value each Sprint. They are also self-managing,
meaning they internally decide who does what, when,
and how.
SCRUM Team
Developers
• Developers are the people in the Scrum Team that are
committed to creating any aspect of a usable increment
each Sprint.
• The specific skills needed by the Developers are often
broad and will vary with the domain of work. However, the
Developers are always accountable for:
• Creating a plan for the Sprint, the Sprint Backlog;
• Instilling quality by adhering to a Definition of Done;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.
SCRUM Team
Product Owner
• The Product Owner is accountable for maximizing the
value of the product resulting from the work of the
Scrum Team.
• The Product Owner is also accountable for effective
Product Backlog management, which includes:
• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and
understood.
SCRUM Team
Product Owner
• The Product Owner may do the above work or may
delegate the responsibility to others. Regardless, the
Product Owner remains accountable.
• For Product Owners to succeed, the entire organization
must respect their decisions.
• The Product Owner is one person, not a committee.
SCRUM Team
Scrum Master
• The Scrum Master is accountable for establishing
Scrum as defined in the Scrum Guide. They do this by
helping everyone understand Scrum theory and
practice, both within the Scrum Team and the
organization.
• The Scrum Master is accountable for the Scrum Team’s
effectiveness. They do this by enabling the Scrum Team
to improve its practices, within the Scrum framework.
SCRUM Team
Scrum Master
The Scrum Master serves the Scrum Team in several ways,
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.
SCRUM Team
Scrum Master
The Scrum Master serves the Product Owner in several ways,
including:
• 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; and,
• Facilitating stakeholder collaboration as requested or needed.
SCRUM Events
The Sprint
• Sprints are the heartbeat of Scrum
• They are fixed length events of one month or less to
create consistency. A new Sprint starts immediately
after the conclusion of the previous Sprint.
• All the work necessary to achieve the Product Goal,
including Sprint Planning, Daily Scrums, Sprint Review,
and Sprint Retrospective, happen within Sprints.
SCRUM Events
The Sprint
During the Sprint:
• No changes are made that would endanger the Sprint
Goal;
• Quality does not decrease;
• The Product Backlog is refined as needed; and,
• Scope may be clarified and renegotiated with the
Product Owner as more is learned.
SCRUM Events
Sprint Planning
• Sprint Planning initiates the Sprint by laying out the work
to be performed for the Sprint
• The product owner and the development team rank the
items in the product backlog by the importance of the
owner’s business needs and the complexity of the
software engineering tasks (programming and testing)
required to complete each of them
SCRUM Events
Sprint Planning
• Prior to starting each sprint, the product owner states his/her
development goal for the increment to be completed in the
upcoming sprint
• The Scrum master and the development team select the items to
move from to the sprint backlog
• The development team determines what can be delivered in the
increment within the constraints of the time-box allocated for the
sprint and, with the Scrum master, what work will be needed to
deliver the increment
• The development team decides which roles are needed and how
they will need to be filled.
SCRUM Events
Sprint Planning
SCRUM Events
Daily Scrum Meeting
• The daily Scrum meeting is a 15-minute event scheduled at the
start of each workday to allow team members to synchronize
their activities and make plans for the next 24 hours
• The Scrum master and the development team always attend the
daily Scrum
• The Scrum master leads the meeting and assesses the responses
from each person. It is the Scrum master’s task to clear obstacles
presented before the next Scrum meeting if possible
• The Scrum meeting helps the team to uncover potential
problems as early as possible
SCRUM Events
Sprint Review
• The sprint review occurs at the end of the sprint when the
development team has judged the increment complete
• The sprint review is often time-boxed as a 4-hour meeting for
a 4-week sprint
• The Scrum master, the development team, the product
owner, and selected stakeholders attend this review
• The primary activity is a demo of the software increment
completed during the sprint
SCRUM Events
Sprint Review
• The product owner may accept the increment as complete or
not
• If it is not accepted, the product owner and the stakeholders
provide feedback to allow a new round of sprint planning to
take place
• This is the time when new features may be added or removed
from the product backlog
• The new features may affect the nature of the increment
developed in the next sprint
SCRUM Events
Sprint Retrospective
• Ideally, before beginning another sprint planning meeting,
the Scrum master will schedule a 3-hour meeting (for a 4-
week sprint) with the development team called a sprint
retrospective
• The Scrum master leads the meeting and encourages the
team to improve its development practices to become more
effective for the next sprint
• The team plans ways to improve product quality by adapting
its definition of done
SCRUM Events
Sprint Retrospective
• During this meeting the team discusses:
• What went well in the sprint
• What could be improved
• What the team will commit to improving in the next sprint
• At the end of this meeting, the team should have a good idea
about the improvements needed in the next sprint and be
ready to plan the increment at the next sprint planning
meeting
Extreme Programming (XP)
• The most widely used agile process, originally proposed
by Kent Beck
• XP Planning
• Begins with the creation of “user stories” by listening
• 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

36
Extreme Programming (XP)
• XP Design
• Encourage the use of CRC
cards
• For difficult design problems,
suggests the creation of
“spike solutions”—a design
prototype
• Encourages “refactoring”—
modifying/optimizing the
code in a way that does not
change the external behavior
of the software
37
Extreme Programming (XP)
• 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
38
Kanban
• The Kanban method is a lean methodology that
describes methods for improving any process or
workflow
• Kanban is focused on change management and service
delivery
• Change management defines the process through which
a requested change is integrated into a software-based
system
• Service delivery is encouraged by focusing on
understanding customer needs and expectations
39
Kanban
• The team members manage the work and are given the
freedom to organize themselves to complete it
• Policies evolve as needed to improve outcomes
• Kanban originated at Toyota as a set of industrial
engineering practices and was adapted to software
development by David Anderson

40
Kanban Core Practices
1. Visualizing workflow using a Kanban board. The
Kanban board is organized into columns representing
the development stage for each element of software
functionality.

41
Kanban Core Practices
2. Limiting the amount of work in progress (WIP) at any
given time. Developers are encouraged to complete
their current task before starting another. This reduces
lead time, improves work quality, and increases the
team’s ability to deliver software functionality
frequently to their stakeholders
3. Managing workflow to reduce waste by understanding
the current value flow, analyzing places where it is
stalled, defining changes, and then implementing the
changes

42
Kanban Core Practices
4. Making process policies explicit (e.g., write down your
reasons for selecting items to work on and the criteria
used to define “done”)
5. Focusing on continuous improvement by creating
feedback loops where changes are introduced based
on process data and the effects of the change on the
process are measured after the changes are made
6. Make process changes collaboratively and involve all
team members and other stakeholders as needed

43
Kanban Meetings
• The team meetings for Kanban are like those in the Scrum
framework
• The basis of the daily Kanban standup meeting is a task called
“walking the board.”
• Leadership of this meeting rotates daily. The team members
identify any items missing from the board that are being
worked on and add them to the board
• During the weekly retrospective meeting, process
measurements are examined. The team considers where
process improvements may be needed and proposes changes
to be implemented
44