Chapter 3 – Agile

Software
Development
D R. S A L M A A L Z A H RA N I

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 1

Topics

AGILE METHODS AGILE DEVELOPMENT AGILE PROJECT SCALING AGILE

TECHNIQUES MANAGEMENT METHODS

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 2

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
Software has to evolve quickly to reflect changing business needs.
impossible to produce a set of stable software requirements

Plan-driven development is essential for some types of system but does not meet these business needs.

Agile development methods emerged in the late 1990s whose aim was to radically reduce the delivery
time for working software systems

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 3

Agile development
The system is developed as a
Program specification, design series of versions or
Frequent delivery of new
and implementation are inter- increments with stakeholders
versions for evaluation
leaved involved in version
specification and evaluation

Extensive tool support (e.g.

Minimal documentation –
automated testing tools) used
focus on working code
to support development.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 4

Plan-driven and agile development

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 5

 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.
Plan-driven • Not necessarily waterfall model – plan-driven,
and agile incremental development is possible
• Iteration occurs within activities.
developmen
t 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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 6

 Agile Method

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 7

What is Agile Method
Agile software development is a group of software
development methodologies based on iterative and
incremental development, where requirements and solutions
evolve through collaboration between self-organizing, cross-
functional teams.
◦ To move quickly
◦ to break obstacles
◦ to be creative
◦ to break the traditional paradigm
◦ to adopt change
◦ to work on what's on hand

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 8

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

 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

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 9

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through
this
Working workover
software we have come to value:
Individuals and interactions Customer collaboration over Responding to change over
comprehensive
over processes and tools contract negotiation following a plan
documentation

That is, while there is value in the items on the right, we value the items on the left more.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 10

 The principles of agile
methods
Principle Description
Customers should be closely involved throughout the development process. Their role
Customer involvement is to provide and prioritize new system requirements and to evaluate the iterations of
the system.
The software is developed in increments with the customer specifying the
Incremental delivery
requirements to be included in each increment.
The skills of the development team should be recognized and exploited. Team
People not process members should be left to develop their own ways of working without prescriptive
processes.
Expect the system requirements to change and so design the system to accommodate
Embrace change
these changes.
Focus on simplicity in both the software being developed and in the development
Maintain simplicity
process. Wherever possible, actively work to eliminate complexity from the system.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 11

 Product development where a software
company is developing a small or
medium-sized product for sale.

Agile
method
where there is a clear
Custom system commitment from the
customer to become involved in
development within an the development process

organization
where there are not a lot of
external rules and regulations
that affect the software.
applicabili
ty
Because of their focus on small, tightly-
integrated teams, there are problems in
scaling agile methods to large systems

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 12

Problems with agile methods
Team members may be
It can be difficult to Prioritizing changes
unsuited to the intense
keep the interest of can be difficult where
involvement that
customers who are there are multiple
characterizes agile
involved in the process. stakeholders.
methods.

Difficult for the company to move to a

Maintaining simplicity working model in which process are
requires extra work. informal and defined by development
teams.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 13

 Agile Development
Techniques

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 14

 Extreme programming
A very influential agile method, developed in the late 1990s, that introduced
a range of agile development techniques.
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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 15

The extreme programming release cycle

CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 06/23/2025 16

Extreme programming practices (a)

Principle or practice Description

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

The minimal useful set of functionality that provides business value is developed first.
Small releases
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 An automated unit test framework is used to write tests for a new piece of functionality
development before that functionality itself is implemented.
All developers are expected to refactor the code continuously as soon as possible code
Refactoring
improvements are found. This keeps the code simple and maintainable.

CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 06/23/2025 17

Extreme programming practices (b)

Developers work in pairs, checking each other’s work and providing the support to always do a good
Pair programming job.

The pairs of developers work on all areas of the system, so that no islands of expertise develop and all
Collective ownership 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 system must pass.

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

A representative of the end-user of the system (the customer) should be available full time for the use
On-site customer 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.

CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 06/23/2025 18

XP and agile principles
Incremental development is supported through small,
frequent system releases.
Customer involvement means full-time customer
engagement with the team.
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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 19

Influential XP practices
Extreme programming has a technical focus and is not easy
to integrate with management practice in most organizations.
Consequently, while agile development uses practices from
XP, the method as originally defined is not widely used.
Key practices
◦ User stories for specification
◦ Refactoring
◦ Test-first development
◦ Pair programming

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 20

User stories for requirements
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 user stories or scenarios.

• These are written on cards and 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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 21

 A
‘prescribi
ng
medicatio
n’ story

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 22

 Examples
of task
cards for
prescribing
medication

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 23

 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.
Example:
◦ 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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 24

 Test-First Development
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:
• Test-first development.
• Incremental test development from scenarios.
• User involvement in test development and validation.
• Automated test harnesses are used to run all component tests each time that a new release is
built.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 25

Test Case Description for Dose Checking

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 26

Customer Involvement
The role of the customer in the testing process is to help develop acceptance tests for the
stories that are to be implemented in the next release of the system.

The customer who is part of the team writes tests as development proceeds. All new code is
therefore validated to ensure that it is what the customer needs.

However, people adopting the customer role They may feel that providing the requirements was enough of
have limited time available and so cannot work a contribution and so may be reluctant to get involved in the
full-time with the development team. testing process.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 27

 Test Automation
Test automation means that tests are As testing is automated, there is always a
written as executable components before set of tests that can be quickly and easily
the task is implemented executed
• These testing components should be • Whenever any functionality is added to
stand-alone, should simulate the the system, the tests can be run and
submission of input to be tested and problems that the new code has
should check that the result meets the introduced can be caught immediately.
output specification. An automated test
framework (e.g. Junit) is a system that
makes it easy to write executable tests
and submit a set of tests for execution.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 28

 Test-Driven Development
Writing tests before code clarifies the requirements to
be implemented.

Tests are written as programs rather than data so that • Usually relies on a testing
they can be executed automatically. The test includes a framework such as Junit.
check that it has executed correctly.

All previous and new tests are run automatically when

new functionality is added, thus checking that the new
functionality has not introduced errors.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 29

 Problems with TEST-FIRST
Development
Programmers prefer programming to testing and
sometimes they take short cuts when writing tests.
For example, they may write incomplete tests that do
not check for all possible exceptions that may occur.

• For example, in a complex user interface, it is often

Some tests can be very difficult to write difficult to write unit tests for the code that implements
incrementally. the ‘display logic’ and workflow between screens.

It difficult to judge the completeness of a set of tests.

Although you may have a lot of system tests, your test
set may not provide complete coverage.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 30

 Pair Programming

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 31

Pair Programming

The driver has control of

Two software engineers The navigator watches
the keyboard and mouse
work on one task at one the driver’s
and creates the
computer. implementation.
implementation.

Identifies defects and The roles of driver and

participates in on- observer are periodically
demand brainstorming. rotated.

• Driver – 1st SW-Engineer, the one who is writing a code

• Observer/navigator – 2nd SW-Engineer, who follow the implementation process of the 1st SW-Engineer

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 32

 Pair Programming

This helps develop common It serves as an informal review It encourages refactoring as the
ownership of code and spreads process as each line of code is whole team can benefit from this.
knowledge across the team. looked at by more than 1 person.

 Pair programming is not necessarily inefficient and there is some evidence

that suggests that a pair working together is more efficient than 2
programmers working separately.

CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 33

Pair Programming
In pair programming, programmers sit together at the same computer 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 that happens during pair programming is very important
as it reduces the overall risks to a project when team members leave.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 34

 Agile Project
Management

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 35

3. Agile Project Management
The principal responsibility of software project managers is to manage the project so that the software is
delivered on time and within the planned budget for the project.

The standard approach to project management is plan-driven. Managers draw up a plan for the project
showing what should be delivered, when it should be delivered and who will work on the development of
the project deliverables.

Agile project management requires a different approach, which is adapted to incremental development
and the particular strengths of agile methods.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 36

 Scrum is an agile method that focuses on managing
Scrum iterative development rather than specific agile practices.

There are three phases in Scrum.

The project closure phase wraps

The initial phase is an outline up the project, completes
This is followed by a series of
planning phase where you required documentation such as
sprint cycles, where each cycle
establish the general objectives system help frames and user
develops an increment of the
for the project and design the manuals and assesses the
system.
software architecture. lessons learned from the
project.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 37

Scrum Terminology (a)
Scrum term Definition
A self-organizing group of software developers, which should be no more than 7 people.
Development team
They are responsible for developing the software and other essential project documents.

The software increment that is delivered from a sprint. The idea is that this should be
‘potentially shippable’ which means that it is in a finished state and no further work, such
Potentially shippable
as testing, is needed to incorporate it into the final product. In practice, this is not always
product increment
achievable.

This is a list of ‘to do’ items which the Scrum team must tackle. They may be feature
definitions for the software, software requirements, user stories or descriptions of
Product backlog supplementary tasks that are needed, such as architecture definition or user
documentation.

An individual (or possibly a small group) whose job is to identify product features or
requirements, prioritize these for development and continuously review the product
Product owner backlog to ensure that the project continues to meet critical business needs. The Product
Owner can be a customer but might also be a product manager in a software company or
other stakeholder representative.
Scrum Terminology (b)
Scrum term Definition
A daily meeting of the Scrum team that reviews progress and prioritizes work
Scrum to be done that day. Ideally, this should be a short face-to-face meeting that
includes the whole team.
The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
ScrumMaster
responsible for interfacing with the rest of the company and for ensuring that
the Scrum team is not diverted by outside interference.
Sprint A development iteration. Sprints are usually 2-4 weeks long.
An estimate of how much product backlog effort that a team can cover in a
single sprint. Understanding a team’s velocity helps them estimate what can
Velocity
be covered in a sprint and provides a basis for measuring improving
performance.
Scrum Sprint Cycle
06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 40
The Scrum Sprint Cycle
Sprints are fixed length, normally 2–4 weeks.

The starting point for planning is the product backlog, which is the list of work to be done on
the project.

The selection phase involves all of the project team who work with the customer to select the
features and functionality from the product backlog to be developed during the sprint.

January May

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 41

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

At the end of the sprint, the work

The role of the Scrum master is to
done is reviewed and presented to
protect the development team from
stakeholders. The next sprint cycle
external distractions.
then begins.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 42

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 (Scrums) where all team 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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 43

Scrum Benefits

The whole team have

The product is broken down visibility of everything and
Unstable requirements do
into a set of manageable and consequently team
not hold up progress.
understandable chunks. communication is
improved.

Customers see on-time Trust between customers and developers is

delivery of increments and established and a positive culture is
gain feedback on how the created in which everyone expects the
product works. project to succeed.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 44

 Distribut
ed
Scrum

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 45

Multi-Team Scrum
Role replication

• Each team has a Product Owner for their work component and Scrum Master.

Product architects

• Each team chooses a product architect and these architects collaborate to design and evolve the overall system
architecture.

Release alignment

• The dates of product releases from each team are aligned so that a demonstrable and complete system is produced.

Scrum of Scrums

• There is a daily Scrum of Scrums where representatives from each team meet to discuss progress and plan work to
be done.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 46

 Scaling Agile
Methods

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 47

4. Scaling Agile Methods
Agile methods 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 comes because of improved
communications which is possible when everyone is working together.

Scaling up agile methods involves changing these to cope with larger, longer projects
where there are multiple development teams, perhaps working in different locations.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 48

 ‘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

Scaling
can be introduced across a large organization with
many years of software development experience.
Out and
Scaling Up
Flexible planning, frequent
When scaling agile methods system releases, continuous
it is important to maintain integration, test-driven
development and good team
agile fundamentals: communications.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 49

Agile Methods for Large Systems
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 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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 50

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

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 51

Factors in Large Systems

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 52

IBM’s agility at scale model

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 53

Scaling Up to Large Systems
A completely incremental approach to requirements engineering is impossible.

There cannot be a single product owner or customer representative.

For large systems development, it is not possible to focus only on the code of the system.

Cross-team communication mechanisms have to be designed and used.

Continuous integration is practically impossible. However, it is essential to maintain frequent system builds and regular
releases of the system.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 54

Practical Problems with Agile
Methods
The informality of agile development is incompatible with the legal approach to contract definition that
is commonly used in large companies.

Agile methods are most appropriate for new software development rather than software maintenance.
Yet the majority of software costs in large companies come from maintaining their existing software
systems.

Agile methods are designed for small co-located team yet much software development now involves
worldwide distributed teams.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 55

Contractual Issues
Most software contracts for custom systems are based around a specification, which
sets out what has to be implemented by the system developer for the system customer.

However, this precludes interleaving specification and development as is the norm in

agile development.

However, this is seen as a high risk by many legal

A contract that pays for developer time
departments because what has to be delivered cannot
rather than functionality is required. be guaranteed.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 56

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.

Are systems that are developed using an agile approach maintainable, given the
emphasis in the development process of minimizing formal documentation?
Two key issues:
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.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 57

Agile maintenance

Key problems are:

Keeping customers involved in Maintaining the continuity of the
Lack of product documentation
the development process development team

Agile development relies on the development team knowing and understanding what has to be done.

For long-lifetime systems, this is a real problem as the original developers will not always work on the
system.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 58

Agile and Plan-Driven Methods
Most projects 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 • This may not be possible for large systems that
system can be developed with a small co- require larger development teams so a plan-
located team who can communicate informally. driven approach may have to be used.

CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 59

Agile and Plan-Based Factors
06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 60
System Issues
How large is the system • Agile methods are most effective a relatively small co-located
being developed? team who can communicate informally.

What type of system is • Systems that require a lot of analysis before implementation
being developed? need a fairly detailed design to carry out this analysis.

What is the expected • Long-lifetime systems require documentation to communicate

system lifetime? the intentions of the system developers to the support team.

Is the system subject to • If a system is regulated you will probably be required to produce
external regulation? detailed documentation as part of the system safety case.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 61

People and teams
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.

How is the development team organized?

• Design documents may be required if the team is distributed.

What support technologies are available?

• IDE support for visualisation and program analysis is essential if design documentation is not
available.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 62

 Agile Principles and Organizational
Practice
Principle Practice

• This depends on having a customer who is willing and able to spend time with the development team and who can
represent all system stakeholders. Often, customer representatives have other demands on their time and cannot
Customer involvement play a full part in the software development.
• Where there are external stakeholders, such as regulators, it is difficult to represent their views to the agile team.

Prioritizing changes can be extremely difficult, especially in systems for which there are many stakeholders. Typically, each
Embrace change stakeholder gives different priorities to different changes.

Rapid iterations and short-term planning for development does not always fit in with the longer-term planning cycles of business
Incremental delivery planning and marketing. Marketing managers may need to know what product features several months in advance to prepare an
effective marketing campaign.

Maintain simplicity Under pressure from delivery schedules, team members may not have time to carry out desirable system simplifications.

Individual team members may not have suitable personalities for the intense involvement that is typical of agile methods, and
People not process therefore may not interact well with other team members.
Organizational Issues
Traditional engineering organizations have a culture of plan-based development, as this
is the norm in engineering.

Is it standard organizational practice to develop a detailed system specification?

Will customer representatives be available to provide feedback of system increments?

Can informal agile development fit into the organizational culture of detailed
documentation?

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 64

Agile Methods Across
Organizations
Large organizations often have quality
Project managers who do not have procedures and standards that all
experience of agile methods may be projects are expected to follow and,
reluctant to accept the risk of a new because of their bureaucratic nature,
approach. these are likely to be incompatible with
agile methods.

Agile methods seem to work best when There may be cultural resistance to
team members have a relatively high agile methods, especially in those
skill level. However, within large organizations that have a long history
organizations, there are likely to be a of using conventional systems
wide range of skills and abilities. engineering processes.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 65

Key points

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 66

Key points
Agile methods are incremental development methods that focus on rapid
software development, frequent releases of the software, reducing process
overheads by minimizing documentation and producing high-quality code.

Agile development practices include

Customer participation
User stories for system Frequent releases of the Continuous software
Test-first development in the development
specification software, improvement
team.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 67

Key points
It is centred round a set of sprints, which are fixed
Scrum is an agile method that provides time periods when a system increment is
a project management framework. developed.

Many practical development methods are a mixture of plan-based and agile

development.

Large systems need up-front design and some

Scaling agile methods for large systems documentation and organizational practice may
is difficult. conflict with the informality of agile approaches.

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 68

 End of Lecture – 05

06/23/2025 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 69