LECTURE 4 & 5

AGILE SOFTWARE
DEVELOPMENT
Topics covered
• What is Agility
• Agile Process
• Agile methods
• Plan-driven and agile development
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
– Critical systems?
– Software has to evolve quickly to reflect changing business needs.
• Rapid software development processes are designed to
produce useful software quickly
• The software is not developed as a single unit but as a series
of increments, with each increment including new system
functionality
Rapid software development –
fundamental characteristics/ Agile Process
• Specification, design and implementation are inter-
leaved
– no detailed system specification, and design documentation
is minimized
– user requirements document only define important
characteristics of the system
• System is developed as a series of versions with
stakeholders involved in version evaluation
– propose changes to the software and new requirements
that should be implemented in a later version of the system
• User interfaces are often developed using an IDE and
graphical toolset.
Agile methods are incremental
development methods
• Increments are small and new releases of the
system are created and made available to
customers every two or three weeks
• Involve customers in the development
process
– get rapid feedback on changing requirements
• Minimize documentation
– By using informal communications rather than
formal meetings with written documents
 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.
Agile method applicability or when to use
Agile method
• Product development where a software company is
developing a small or medium-sized product for sale.
• Custom system development within an organization
– where there is a clear commitment from the customer to
become involved in the development process
– where there are not a lot of external rules and regulations
that affect the software.
• Because of their focus on small, tightly-integrated
teams, there are problems in scaling agile methods to
large systems.
Problems with agile methods
• It can be difficult to keep the interest of customers who are
involved in the process.
• Team members may be unsuited to the intense involvement
• Prioritizing changes can be difficult where there are multiple
stakeholders.
• Contracts may be a problem as with other approaches to
iterative development.
– As requirement document is part of contract between customer
and supplier
• Organizations have spent year in formalizing their process so
it is difficult for them to adopt informal process model
defined by development teams
Agile methods and software maintenance
• Most organizations spend more on maintaining existing
software than they do on new software development.
• So, if agile methods are to be successful, they have to support
maintenance as well as original development.
• Two key issues:
– Are systems that are developed using an agile approach maintainable?
– Key to implementing maintainable software is to produce high quality and well-
structured code instead of documentation
– Can agile methods be used effectively for evolving a system in
response to customer change requests?
• Incremental delivery, design for change and maintaining simplicity all make
sense when software is being changed which shows agile methods are used
effectively
• Problems may arise if original development team is broken up.
Plan-driven and agile development
• Plan-driven development
– A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced at
each of these stages planned in advance.
– Not necessarily waterfall model – plan-driven, incremental
development is possible
– Iteration occurs within activities.
• Agile development
– Specification, design, implementation and testing are inter-leaved
– Outputs from the development process are decided through a
process of negotiation during the software development process.
Plan-driven and agile specification
Agile vs. Plan-driven Methods
Agile methods Plan-driven methods
Low criticality High criticality
Senior developers Junior developers(?)
Requirements do not change
Requirements change often often
Small number of developers Large number of developers
Culture that responds to
change Culture that demands order
Agile Methods
• Well-known agile software development
methods and/or process frameworks include:
– Extreme programming (XP)
– Scrum
– Kanban
– DevOps
Extreme programming
• Perhaps the best-known and most widely
used agile method.
• Extreme Programming (XP) takes an
‘extreme’ approach to iterative development.
– New versions may be built several times per day;
– Increments are delivered to customers every 2
weeks;
– All tests must be run for every build and the build
is only accepted if tests run successfully.
XP and agile principles
• Incremental development is supported through small,
frequent system releases.
– Requirements are based on simple customer stories or
scenarios
• Customer involvement means full-time customer
engagement with the team.
– Responsible for defining acceptance tests for the system
• People, not process, through pair programming, collective
ownership and a process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of
code.
The extreme programming release cycle
Extreme programming
User Story
• A user story in Agile is a short, simple description
of a feature or functionality from the perspective
of the end user. It typically follows this format:
• As a [type of user], I want [a feature], so that
[benefit or reason].
Example of a User Story:
• As a customer, I want to receive email
notifications when my order is shipped, so that I
can track the delivery of my purchase.
Examples of task cards
Planning
• In XP, a customer or user is part of the XP team and is
responsible for making decisions on requirements.
• User requirements are expressed as scenarios or user
stories.
• These are written on cards
• The development team break them down into
implementation tasks.
– These tasks are the basis of schedule and cost estimates.
• The customer chooses the stories for inclusion in the next
release based on their priorities and the schedule
estimates.
 Design
• Provides implementation guidance for a story as it is written
• XP encourages the use of CRC (class-responsibility-
collaborator) cards
– Identify and organize the object oriented classes that are
relevant to the current software increment
• If a difficult design problem is encountered
– Immediately creation of an operational prototype of that portion
of the design called Spike
– Intent is to lower risk when true implementation starts
• Encourage refactoring
Refactoring
• Programming team look for possible software
improvements and make these improvements even
where there is no immediate need for them.
• This improves the understandability of the software
and so reduces the need for documentation.
• Changes are easier to make because the code is
well-structured and clear.
• However, some changes requires architecture
refactoring and this is much more expensive.
Examples of refactoring
• Re-organization of a class hierarchy to remove duplicate
code.
• Tidying up and renaming attributes and methods to make
them easier to understand.
• The replacement of inline code with calls to methods that
have been included in a program library.
– Eclipse include tools for refactoring which simplify the process
of finding dependencies between code sections and making
global code modifications
• In principle, software is easy to understand and change as
new stories are implemented
Coding
• After creating simple design team move to
developing tests instead of coding
– Develops unit test; the developer is better able to
focus on what must be implemented to pass the
test
• A key concept during the coding activity is
pair programming
Pair programming
• Programmers sit together at the same workstation to
develop the software.
• Pairs are created dynamically so that all team
members work with each other during the
development process.
• The sharing of knowledge between pairs reduces the
overall risks to a project when team members leave.
• A pair working together is more efficient than 2
programmers working separately.
Testing in XP
• XP testing features:
– Test-first development.
– Incremental test development from scenarios.
– User involvement in test development and
validation.
– Automated test are used to run all component
tests each time that a new release is built.
Test-first development
• Writing tests before code clarifies the
requirements to be implemented.
– Ambiguities have to clarify before actual
implementation
• Tests are written as programs so that they can be
executed automatically. The test includes a check
that it has executed correctly.
– Usually relies on a testing framework such as Junit.
• All previous and new tests are run automatically
when new functionality is added, thus checking
that the new functionality has not introduced
errors.
Test case Verify Email
Notification on Order
Shipment
Note
• The above test case covers
one task within the
broader user story.
• Specifically, it focuses on
verifying the functionality
of sending an email
notification when an order
is shipped, which is just
one part of the overall user
story.
Scrum
• The Scrum approach is a general agile method but
its focus is on managing iterative development
• There are three phases in Scrum.
– Outline planning phase where you establish the general
objectives for the project and design the software
architecture.
– This is followed by a series of sprint cycles, where each
cycle develops an increment of the system.
– The project closure phase wraps up the project,
completes required documentation
• such as user manuals and assesses the lessons learned from the
project.
The Scrum process
Planning and Architecture Design
• Planning includes
– Definition of the system being developed
– Definition of the project team, tools, risk assessment
– Requirements are prioritized and effort is estimated
– Product Backlog list
• Containing all requirements that are currently known
• Updated regularly with new and more detailed items
– At every iteration, the updated product Backlog is reviewed by the
Scrum Team
• Architecture Design
– High level design of the system including architecture is planned based
on current items in Product Backlog
– Design review meeting is held to go over the proposals for the
implementation
The Sprint cycle
• Sprints are fixed length, normally 2–4 weeks. They
correspond to the development of a release of the
system in XP.
• The Assess Phase
– Product backlog is reviewed, and priorities and risks are
assigned
– Customer is involved to introduce new requirements or tasks
at beginning of each sprint
• The Selection Phase
– Involves all of the project team who work with the customer
to select the features and functionality to be developed
during the sprint.
The Sprint cycle
• The Develop Phase
– The team organize themselves to develop the software.
– The team is isolated from the customer and the
organization
– All communication is channelled through the so-called
‘Scrum master’.
– The role of the Scrum master is to protect the
development team from external distractions.
• The Review Phase
– At the end of the sprint, the work done is reviewed and
presented to stakeholders.
– The next sprint cycle then begins.
Teamwork in Scrum
• The whole team attends short daily meetings
– 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?
• This means that everyone on the team knows
what is going on and, if problems arise, can
re-plan short term work to cope with them.
Roles and Responsibilities
• Scrum Master (a facilitator who arranges)
– Daily meetings, tracks the backlog of work to be done, records
decisions, measures progress against the backlog and communicates
with customers and management outside of the team.
• Product Owner
– Responsible for project, managing, controlling and making visible
Product Backlog list
– Makes final decisions of the tasks related to product Backlog
• Scrum Team
– It is project team
– Organize itself in order to achieve the goals of each Sprint
– Involved in effort estimation, creating Sprint Backlog, reviewing
Product Backlog list
Roles and Responsibilities
• Customer
– Participate in tasks related to product Backlog items
• Management
– In charge of final decision making
– Participate in setting of goals and requirements
– E.g. management is involved in selecting Product Owner
Kanban
• The Kanban method [And16] 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.
• The team members manage the work and are
given the freedom to organize themselves to
Kanban board
Kanban itself depends on six core
practices (1)
1. Visualizing workflow using a Kanban
board (an example is shown in Figure).
The Kanban board is organized into
columns representing the development
stage for each element of software
functionality. The cards on the board
might contain single user stories or
recently discovered defects on sticky
notes and the team would advance
them from “to do,” to “doing,” and
“done” as the project progresses.

2. Limiting the amount of work in Kanban board

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.
Kanban itself depends on six core
practices (2)
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.
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 Kanban board
after the changes are made.
6. Make process changes collaboratively
and involve all team members and
other stakeholders as needed.
Team Meetings in Kanban
• The team meetings for Kanban are like
those in the Scrum framework.
• If Kanban is being introduced to an
existing project, not all items will start in
the backlog column.
• Developers need to place their cards in
the team process column by asking
themselves:
– Where are they now?
– Where did they come from?
– Where are they going?
Walking the board
• 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.
• The team tries to advance any items they can
to “done.”
• The goal is to advance the high business value
items first.
• The team looks at the flow and tries to identify
any impediments to completion by looking at
workload and risks.
DevOps
• DevOps was created by Patrick DeBois [Kim16a] to
combine Development and Operations.
• DevOps attempts to apply agile and lean development
principles across the entire software supply chain.

Figure presents an overview of the DevOps workflow

Stages of DevOps(1)
The DevOps approach involves several stages that
loop continuously until the desired product exists:
• Continuous development. Software
deliverables are broken down and developed in
multiple sprints with the increments delivered to
the quality assurance14 members of the
development team for testing
• Continuous testing. Automated testing
tools15 are used to help team members test
multiple code increments at the same time to
ensure they are free of defects prior to
integration.
Stages of DevOps(2)
• Continuous integration. The code pieces with
new functionality are added to the existing code
and to the run-time environment and then
checked to ensure there are no errors after
deployment.
• Continuous deployment. At this stage the
integrated code is deployed (installed) to the
production environment, which might include
multiple sites globally that need to be prepared
to receive the new functionality.
• Continuous monitoring. Operations staff who
are members of the development team help to
improve software quality by monitoring its
performance in the production environment and
Case Study
Your team of software engineers is required
to develop a web-based software system
that allows the management of supplies and
distributions in a dried foods factory. Most of
the workers in that factory are not familiar
with the capabilities of a computerized
system. Suggest the appropriate software
process model to be used in the
development process and describe at least
two reasons of choosing that process model?
Possible Choices
• Rapid Prototyping: Marked 5/5
• Reason: (Best suited for quickly visualizing requirements and accommodating changes,
especially when users have difficulty articulating their needs.)
Incremental: Marked 4/5
• Reason: (Highly suitable for its iterative approach and ability to manage risks effectively,
allowing gradual adaptation based on user feedback.)
Agile: Marked 3/5
• Reason: (While highly flexible and adaptable, it may require more active involvement from
workers who are not familiar with computerized systems.)
Spiral: Marked 2/5
• Reason:(Can be suitable for its risk management, but may require careful consideration to
ensure workers' understanding and involvement, ranking lower due to its potential
complexity.
• Waterfall: Marked 1/5
• Reason: The Waterfall Model's 1 inflexible, sequential nature cannot accommodate the
evolving requirements and user feedback essential for developing software in an
environment where workers have limited computerized system familiarity, such as a dried
foods factory.