Software Engineering

Agile Methods
Chapter 3
Introduction to Agile
Methodology

2
3
Agile Methodology
• Agileis a software development methodology to build
software incrementally using short iterations of 1 to 4
weeks so that the development process is aligned with
the changing business needs.

• Insoftware development, agile (sometimes

written Agile practices approach discovering
requirements and developing solutions through the
collaborative effort of self organization and cross
functional teams and their customers/end users
4
 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. 5
Rapid software development
• Rapiddevelopment 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.

6
Agility and the Cost of Change

7
 Agility and the Cost of Change
• Conventional wisdom is that the cost of change increases nonlinearly as a project
progresses.
• It is relatively easy to accommodate a change when a team is gathering
requirements early in a project.
 If there are any changes, the costs of doing this work are minimal.

• But if the middle of validation testing, a stakeholder is requesting a major functional

change.
 Then the change requires a modification to the architectural design, construction of new
components, changes to other existing components, new testing and so on. Costs escalate
quickly.

• A well-designed agile process may “flatten” the cost of change curve by coupling
incremental delivery with agile practices such as continuous unit testing and pair
programming. Thus team can accommodate changes late in the software project
without dramatic cost and time impact.
8
Agile manifesto
• Weare 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
• Thatis, while there is value in the items on the right,
we value the items on the left more.

9
Agile method applicability
• 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 and 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.
10
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 that characterizes agile methods.
• Prioritizing
changes can be difficult where there are
multiple stakeholders.
• Contracts may be a problem as with other approaches
to iterative development.

11
 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, given
the emphasis in the development process of minimizing formal
documentation?
 Can agile methods be used effectively for evolving a system in response to
customer change requests?

• Problems may arise if original development team cannot be

maintained.
12
Comparison between
agile and plan driven
methodology

13
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 and the outputs from the development process are decided
through a process of negotiation during the software
development process.
14
Plan-driven and agile specification

15
 Technical, human, organizational
issues
• Mostprojects include elements of plan-driven and agile
processes. Deciding on the balance depends on:
 Is it important to have a very detailed specification and design before
moving to implementation? If so, you probably need to use a plan-
driven approach.
 Is an incremental delivery strategy, where you deliver the software to
customers and get rapid feedback from them, realistic? If so, consider
using agile methods.
 How large is the system that is being developed? Agile methods are
most effective when the system can be developed with a small co-
located team who can communicate informally. This may not be
possible for large systems that require larger development teams so a
plan-driven approach may have to be used.
16
 Technical, human, organizational
issues
 What type of system is being developed?
 Plan-driven approaches may be required for systems that require a lot of
analysis before implementation (e.g. real-time system with complex
timing requirements).
 What is the expected system lifetime?
 Long-lifetime systems may require more design documentation to
communicate the original intentions of the system developers to the
support team.
 What technologies are available to support system
development?
 Agile methods rely on good tools to keep track of an evolving design
 How is the development team organized?
 If the development team is distributed or if part of the development is
being outsourced, then you may need to develop design documents to
communicate across the development teams. 17
 Technical, human, organizational
issues
 Are there cultural or organizational issues that may affect the
system development?
 Traditional engineering organizations have a culture of plan-based
development, as this is the norm in engineering.
 How good are the designers and programmers in the development
team?
 It is sometimes argued that agile methods require higher skill levels than
plan-based approaches in which programmers simply translate a detailed
design into code
 Is the system subject to external regulation?
 If a system has to be approved by an external regulator (e.g. the FAA
approve software that is critical to the operation of an aircraft) then you will
probably be required to produce detailed documentation as part of the
system safety case.
18
Extreme
Programming

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

20
Extreme programming

21
User stories example

22
User stories example

23
Extreme programming practices (a)
Principle or practice Description

Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and their
relative priority. The developers break these stories into development
‘Tasks’. See Figures 3.5 and 3.6.

Small releases The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and
incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements and no
more.
Test-first development An automated unit test framework is used to write tests for a new
piece of functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon
as possible code improvements are found. This keeps the code simple
and maintainable.
24
Extreme programming practices (b)
Principle or practice Description
Pair programming Developers work in pairs, checking each other’s work and providing
the support to always do a good job.

Collective ownership The pairs of developers work on all areas of the system, so that no
islands of expertise develop and all the developers take responsibility
for all of the code. Anyone can change anything.

Continuous integration As soon as the work on a task is complete, it is integrated into the
whole system. After any such integration, all the unit tests in the

Chapter 3 Agile software development

system must pass.

Sustainable pace Large amounts of overtime are not considered acceptable as the net
effect is often to reduce code quality and medium term productivity

On-site customer A representative of the end-user of the system (the customer) should
be available full time for the use of the XP team. In an extreme
programming process, the customer is a member of the development
team and is responsible for bringing system requirements to the team
for implementation.
25
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.

Chapter 3 Agile software development

• Changes are easier to make because the code is well-
structured and clear.

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

Chapter 3 Agile software development

• The replacement of inline code with calls to
methods that have been included in a program
library.

27
Pair programming
• In 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.

Chapter 3 Agile software development

• The sharing of knowledge that happens during pair
programming is very important as it reduces the overall
risks to a project when team members leave.
• Pair programming is not necessarily inefficient and there
is evidence that a pair working together is more efficient
than 2 programmers working separately.

28
Advantages of pair programming
• It supports the idea of collective ownership and responsibility
for the system.
 Individuals are not held responsible for problems with the code. Instead,
the team has collective responsibility for resolving these problems.

• It acts as an informal review process because each line of code

Chapter 3 Agile software development

is looked at by at least two people.
• It helps support refactoring, which is a process of software
improvement.
 Where pair programming and collective ownership are used, others benefit
immediately from the refactoring so they are likely to support the process.

29
Testing in XP
• Testing
is central to XP and XP has developed an
approach where the program is tested after every
change has been made.
• XP testing features:

Chapter 3 Agile software development

 Test-first development.
 Incremental test development from scenarios.
 User involvement in test development and validation.
 Automated testing is used to run all component tests
each time that a new release is built.

30
XP- Summary

33
XP- Summary

34
 A ‘prescribing medication’ story

Chapter 3 Agile software development

35
Examples of task cards for
prescribing medication

Chapter 3 Agile software development

36
Test case description for dose
checking

Chapter 3 Agile software development

37
 Scrum Model

Chapter 3 Agile software development

43
Scrum
• TheScrum approach is a general agile method but its
focus is on managing iterative development rather than
specific agile practices.
• There are three phases in Scrum.

Chapter 3 Agile software development

 The initial phase is an 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 system help frames and user
manuals and assesses the lessons learned from the project. 44
 The Scrum process

Chapter 3 Agile software development

45
The Sprint cycle
• Sprintsare fixed length, normally 2–4 weeks (typically
1 month). They correspond to the development of a
release of the system in XP.
• Thestarting point for planning is the product backlog,

Chapter 3 Agile software development

which is the list of work to be done on the project.
• Theselection phase involves all of the project team who
work with the customer to select the features and
functionality to be developed during the sprint.

46
The Sprint cycle
• Once these are agreed, the team organize themselves to develop
the software. During this stage the team is isolated from the
customer and the organization, with all communications
channelled through the so-called ‘Scrum master’.
• The role of the Scrum master is to protect the development team

Chapter 3 Agile software development

from external distractions.
• At the end of the sprint, the work done is reviewed and presented
to stakeholders. The next sprint cycle then begins.

47
Teamwork in Scrum
• The ‘Scrum master’ is 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.
• The whole team attends short daily meetings where all team

Chapter 3 Agile software development

members share information, describe their progress since the last
meeting, problems that have arisen and what is planned for the
following day.
 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.

48
Example
• Here’san example of how Scrum works: Bill meets with a
customer to discuss her company’s needs. Those needs are
the product backlog. Bill chooses the most important
tasks to work on in the next two weeks. His team meets in
a daily scrum to target work for the day ahead and
address roadblocks. At the end of the sprint, Bill delivers
the work, reviews the backlog, and sets the goal for the
next sprint. The cycle repeats until the software is
complete.

49
Agile Methodology Examples
• One real-time example of software developed using Agile methodology is the widely-used
project management tool Trello. Trello is a web-based application that allows users to
organize and manage tasks, projects, and workflows using a visual board format.
 Trello was developed using Agile methodology, specifically the Scrum framework. The
development team worked in sprints, with each sprint lasting two weeks. At the beginning of
each sprint, the team would meet to plan the work to be completed and prioritize the backlog of
user stories and features.
 Throughout the sprint, the team would hold daily stand-up meetings to discuss progress and any
issues that arose. At the end of each sprint, the team would hold a sprint review meeting to
demo the completed work to stakeholders and receive feedback.
 Using Agile methodology allowed the development team to quickly respond to changes in user
requirements and feedback. This resulted in a product that has been widely adopted by
businesses and individuals around the world.

• Another example of software developed using Agile methodology is Spotify, the popular
music streaming service. Spotify has a large development team that works in small, cross-
functional squads using Agile methodologies. This allows the team to quickly respond to
changes in user needs and deliver new features and updates in a timely manner

50
Scrum benefits
• The product is broken down into a set of manageable and
understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have visibility of everything and consequently

Chapter 3 Agile software development

team communication is improved.
• Customers see on-time delivery of increments and gain feedback
on how the product works.
• Trust between customers and developers is established and a
positive culture is created in which everyone expects the project to
succeed.
51
Scaling Up v.s
Scaling Out

52
Scaling agile methods
• Agilemethods have proved to be successful for small and
medium sized projects that can be developed by a small
co-located team.
• It
is sometimes argued that the success of these methods

Chapter 3 Agile software development

comes because of improved communications which is
possible when everyone is working together.
• Scalingup agile methods involves changing these to cope
with larger, longer projects where there are multiple
development teams, perhaps working in different
locations.
53
Large systems development
• Large systems are usually collections of separate, communicating
systems, where separate teams develop each system. Frequently,
these teams are working in different places, sometimes in different
time zones.
• Large systems are ‘brownfield systems’, that is they include and

Chapter 3 Agile software development

interact with a number of existing systems. Many of the system
requirements are concerned with this interaction and so don’t really
lend themselves to flexibility and incremental development.
• Where several systems are integrated to create a system, a
significant fraction of the development is concerned with system
configuration rather than original code development.
54
Large system development
• Large systems and their development processes are often
constrained by external rules and regulations limiting the way
that they can be developed.
• Large systems have a long procurement and development time. It
is difficult to maintain coherent teams who know about the

Chapter 3 Agile software development

system over that period as, inevitably, people move on to other
jobs and projects.
• Large systems usually have a diverse set of stakeholders. It is
practically impossible to involve all of these different
stakeholders in the development process.

55
Scaling out and scaling up
• ‘Scaling
up’ is concerned with using agile methods for
developing large software systems that cannot be
developed by a small team.
• ‘Scaling
out’ is concerned with how agile methods can be

Chapter 3 Agile software development

introduced across a large organization with many years of
software development experience.
• When scaling agile methods it is essential to maintain
agile fundamentals
 Flexible planning, frequent system releases, continuous
integration, test-driven development and good team
communications. 56
Scaling up to large systems
• For large systems development, it is not possible to focus only
on the code of the system. You need to do more up-front design
and system documentation
• Cross-team communication mechanisms have to be designed
and used. This should involve regular phone and video

Chapter 3 Agile software development

conferences between team members and frequent, short
electronic meetings where teams update each other on
progress.
• Continuous integration, where the whole system is built every
time any developer checks in a change, is practically
impossible. However, it is essential to maintain frequent
system builds and regular releases of the system.
57
 Scaling out to large companies
• Project managers who do not have experience of agile methods may
be reluctant to accept the risk of a new approach.
• Large organizations often have quality procedures and standards
that all projects are expected to follow and, because of their
bureaucratic nature, these are likely to be incompatible with agile

Chapter 3 Agile software development

methods.
• Agile methods seem to work best when team members have a
relatively high skill level. However, within large organizations,
there are likely to be a wide range of skills and abilities.
• There may be cultural resistance to agile methods, especially in
those organizations that have a long history of using conventional
systems engineering processes.
58
Key points
•A particular strength of extreme programming is the
development of automated tests before a program
feature is created. All tests must successfully execute
when an increment is integrated into a system.

Chapter 3 Agile software development

• The Scrum method is an agile method that provides a
project management framework. It is centred round a
set of sprints, which are fixed time periods when a
system increment is developed.
• Scaling
agile methods for large systems is difficult.
Large systems need up-front design and some
documentation. 59
Reading Assignment
• Chapter #3
• https://www.guru99.com/agile-scrum-extreme-
testing.html
• https://www.infoworld.com/article/3237508/what-
is-agile-methodology-modern-software-
development-explained.html
• https://www.geeksforgeeks.org/software-
engineering-agile-software-development/

60