Chapter 3 – Agile Software Development

Dr. Adem Tekerek

Subject
 Agile methods
 Çevik geliştirme teknikleri
 Agile project management
 Scaling agile methods

 Plan-driven and agile development

 Extreme programming

13.02.2025 2
Rapid Software Development

 Rapid development and delivery are now often the most

important requirement for software systems
 Businesses operate with a rapidly changing requirement and it is
almost impossible to produce a set of stable software
requirements.
 Software must evolve rapidly to reflect changing business needs.
 Plan-driven development is necessary for some types of
systems, but does not meet these business requirements.
 Agile development methods emerged in the late 1990s,
aiming to radically reduce delivery time for working
software systems.

13.02.2025 3
Agile Development

 Program features, design and implementation are

interrelated
 The system is developed as a series of releases or
increments with stakeholders involved in the release
specification and evaluation.
 Frequent delivery of new versions for evaluation
 Extensive tool support used to support development
(e.g. automated testing tools).
 Minimal documentation – focus on working code

13.02.2025 4
Plan-driven and Agile Development

13.02.2025 5
Plan-driven and Agile Development

 Plan-driven Development
 A plan-driven approach to software engineering is based on
separate development phases, with the outputs to be produced
in each of these phases planned in advance.
 Waterfall model not mandatory – plan-driven, gradual
development possible
 Iteration occurs within activities.
 Agile Development
 Specification, design, implementation and testing are dropped
one after the other, and the outputs from the development
process are determined through a process of negotiation
throughout the software development process.

6
 Agile Methods

13.02.2025 7
Agile Methods

 Dissatisfaction with the overhead involved in the

software design methods of the 1980s and 1990s led to
the creation of agile methods. These methods:
 Focus on code instead of design
 Based on an iterative approach to software development
 It is intended to deliver working software quickly and evolve it
rapidly to meet changing requirements.
 The goal of agile methods is to reduce overhead in the
software process (for example, by limiting
documentation) and to be able to respond quickly to
changing requirements without excessive rework.

13.02.2025 8
Agile Manifesto

 By doing this and helping others do it, we uncover better

ways to develop software. Thanks to this work, we
gained value:
 Interactions between individuals and processes and tools
Working software over comprehensive documentation Customer
collaboration over contract negotiation Responding to change
over following a plan

13.02.2025 9
Principles Of Agile Methods

Principles Descriptions
Customer Customers should be closely involved throughout the
Engagement development process. Their role is to ensure and prioritize new
system requirements and evaluate iterations of the system.
Incremental The software is developed in increments with the customer
Delivery specifying the requirements to be included in each increment.
People Not The skills of the development team should be recognized and
Transactions leveraged. Team members should be left to develop their own
working methods without cover letter processes.

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

Keep It Simple Focus on simplicity, both in the software being developed and
in the development process. It works effectively to remove
complexity from the system wherever possible..

13.02.2025 10
Agile Method Applicability

 Product development, in which a software company

develops a small or medium-sized product for sale.
 Almost all software products and applications are now
developed using an agile approach
 Custom system development within an organization
where there is a clear commitment from the customer to
be involved in the development process and few external
rules and regulations affecting the software.

13.02.2025 11
 Agile Development Techniques

13.02.2025 12
Ekstreme Programming (XP)

 Effective agile method developed in the late 1990s and

introducing a set of agile development techniques.
 Extreme Programming (XP) takes an 'Extreme' approach
to iterative development.
 New versions can be created several times a day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for each build, and the build is accepted
only if the tests run successfully.

13.02.2025 13
Extreme Programming Broadcast Cycle

13.02.2025 14
Extreme Programming Practices (A)

principle or practice Explanation

incremental planning Requirements are recorded on story cards, and the stories
included in a release are determined by available time and their
relative priority. Developers divide these stories into
development 'Tasks'.
minor versions First, a minimal set of useful functionality that provides business
value is developed. Releases of the system are frequent and
gradually add functionality to the initial release.
simple design Adequate design has been achieved to meet current
requirements and no more.
Test-first development Automated unit testing framework is used to write tests for a new
piece of functionality before the functionality itself is
implemented.
Refactoring All developers are expected to continually refactor code as soon
as possible code improvements are found. This keeps the code
simple and maintainable.

13.02.2025 15
 Extreme Programming Practices (B)

Pair Programming Developers work in pairs, checking each other's work and providing
support to always do a good job.
Collective Ownership Pairs of developers work on all areas of the system, so that no
islands of expertise are created and all developers take
responsibility for the entire code. Anyone can change everything.
Continuous Integration As soon as work on a task is completed, it is integrated into the
entire system. After such integration, all unit tests in the system
should pass.
Sustainable Tempo Large amounts of overtime are unacceptable as the net effect is
often to reduce code quality and medium-term productivity.

Onsite Customer A representative of the end user (customer) of the system must be
available full time for use by the XP team. In the extreme
programming process, the customer is a member of the
development team and is responsible for bringing the system
requirements to the team for implementation.

13.02.2025 16
XP and Agile Principles

 Incremental development is supported by small, frequent

system releases.
 Customer engagement means full-time customer
interaction with the team.
 People do not transact through a process that eschews
pair programming, collective ownership, and long
working hours.
 Change supported through regular system releases.
 Maintaining simplicity through constant refactoring of
code.

13.02.2025 17
Influential XP practices

 Extreme programming has a technical focus and is not

easy to integrate with management practices in most
organizations.
 As a result, while agile development uses practices in
XP, the method as originally defined is not widely used.
 Basic applications
 User stories for specification
 Refactorin – Refactoring
 Test-first development
 pair programming

13.02.2025 18
User Stories for Requirements

 In XP, a customer or user is part of the XP team and is

responsible for making decisions about requirements.
 User requirements are expressed as user stories or
scenarios.
 These are written on cards and the development team
breaks them down into implementation tasks. These
tasks form the basis of schedule and cost estimates.
 The customer selects stories to include in the next
release based on their priorities and schedule estimates.

13.02.2025 19
A ‘Prescribing Medication’ Story

13.02.2025 20
Examples of task cards for prescribing
medication

13.02.2025 21
Refactoring

 Conventional wisdom in software engineering is to

design for change. Anticipating changes is worth the time
and effort as this reduces costs later in the life cycle.
 However, XP argues that this is not valuable because
changes cannot be reliably expected.
 Instead, it recommends continuous code improvement
(refactoring) to make it easier when changes need to be
implemented.

13.02.2025 22
Refactoring

 The programming team searches for possible software

improvements and makes them even where there is no
immediate need.
 This increases the understandability of the software and
thus reduces the need for documentation.
 It is easier to make changes because the code is well
structured and clear.
 However, some changes require architectural refactoring
and this is much more expensive.

13.02.2025 23
Examples of Refactoring

 Reorganization of class hierarchy to remove duplicate

code.
 Rounding up and renaming attributes and methods to
make them easier to understand.
 Replacing line code with calls to methods in the program
library.

13.02.2025 24
Test-first Development

 Testing is at the heart of XP, and XP has developed an

approach where the program is tested after each change
is made.
 XP testing features:
 Test-first development.
 Incremental test development from scenarios.
 User involvement in test development and validation.
 Automated test runs are used to run all component tests when a
new version is created.

13.02.2025 25
Test-Driven Development

 Writing tests before the code describes the requirements

to be implemented.
 Tests are written as programs rather than data so that
they can be executed automatically. Testing includes a
properly executed audit.
 It is usually based on a testing framework like Junit.
 All previous and new tests are automatically run when
new functionality is added, checking that the new
functionality does not introduce errors.

13.02.2025 26
Customer Involvement

 The customer's role in the testing process is to help

develop acceptance tests for stories that will be
implemented in the next version of the system.
 The customer, as part of the team, writes tests as
development progresses. Therefore, all new code is
validated to ensure that this is what the customer needs.
 However, people who adopt the customer role have
limited time and therefore cannot work full-time with the
development team. They may feel that providing the
requirements is a sufficient contribution and therefore
may be reluctant to engage in the testing process.

13.02.2025 27
Test Case Description For Dose
Checking

13.02.2025 28
Test Automation

 Test automation means that tests are written as

executable components before the task is implemented.
 These test components should be standalone, simulate sending
the input to be tested and check whether the result conforms to
the output specification. An automated testing framework (e.g.
Junit) is a system that makes it easy to write executable tests
and submit a set of tests for execution.
 Since testing is automated, there is always a set of tests
that can be executed quickly and easily.
 Whenever any functionality is added to the system, tests can be
run and any issues introduced by the new code can be caught
immediately.

13.02.2025 29
Problems With Test-First Development

 Programmers prefer testing to programming and

sometimes take shortcuts when writing tests. For
example, they may write incomplete tests that do not
check for all possible exceptions that may occur.
 Some tests can be very difficult to write in stages. For
example, in a complex user interface, it is often difficult
to write unit tests for code that implements 'display logic'
and workflow between screens.
 It is difficult to evaluate the completeness of a battery of
tests. Even if you have a large number of system tests,
your test set may not provide complete coverage.

13.02.2025 30
Pair Programming

 Pair programming involves programmers working in pairs

and developing code together.
 This helps develop shared ownership of the code and
spreads knowledge throughout the team.
 Since each line of code is looked at by more than 1
person, it serves as an informal review process.
 It encourages refactoring because the entire team can
benefit from improving the system code.

13.02.2025 31
Pair Programming

 In pair programming, programmers may sit together at

the same computer to develop software.
 Pairs are dynamically created so that all team members
work with each other during the development process.
 The information sharing that takes place during pair
programming is crucial as it reduces the overall risks of
the project when team members leave.
 Pair programming is not necessarily inefficient, and there
is some evidence to suggest that a pair working together
is more productive than 2 programmers working
separately.
13.02.2025 32
 Agile Project Management

13.02.2025 33
Agile Project Management

 The primary responsibility of software project managers

is to manage the project so that the software is delivered
on time and within the budget planned for the project.
 The standard approach to project management is plan-
oriented. Managers create a plan for the project that
outlines what must be delivered, when it must be
delivered, and who will work on developing project
deliverables.
 Agile project management requires a different approach
adapted to incremental development and the practices
used in agile methods.

13.02.2025 34
Scrum

 Scrum is an agile method that focuses on managing

iterative development rather than specific agile practices.
 There are three phases in Scrum.
 The first phase is an outline planning phase, where you establish
the overall goals of the project and design the software
architecture.
 This is followed by a series of sprint cycles in which each cycle
develops an increment of the system.
 The project closure phase completes the project, completes
necessary documentation such as system help frameworks and
user guides, and evaluates lessons learned from the project.

13.02.2025 35
Scrum Terminology (a)

Scrum term Definition

Development team A self-organized group of software developers of no more than 7 people.

They are responsible for the development of the software and other key
project documentation.

Potentially shippable Software increment from a sprint. The idea is that it should be “potentially
product increase shippable”; This means it is finished and no further work, such as testing, is
required to incorporate it into the final product. In practice, this is not always
achievable.

Product Backlog This is a list of 'to do' items that the Scrum team must tackle. They can be
feature descriptions for the software, software requirements, user stories, or
descriptions of complementary tasks needed, such as architecture definition
or user documentation.

Product Owner An individual (or possibly a small group) whose job it is to identify product
features or requirements, prioritize them for development, and continually
review the product backlog to ensure that the project continues to meet
critical business needs. The Product Owner may be a customer, but may also
be a product manager or other stakeholder representative in a software
company.

13.02.2025 36
 Scrum Terminology (b)

Scrum term Definition

Scrum Daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting involving the entire team.
ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He is
responsible for interacting with the rest of the company and ensuring that
the Scrum team is not driven by external interference. Scrum developers
are adamant that the ScrumMaster should not be thought of as a project
manager. But others may not always find it easy to see the difference.
Sprint A development iteration. Sprints typically last 2-4 weeks.

Velocity - An estimate of how much product backlog effort a team can handle in a
Hız single sprint. Understanding a team's velocity helps them estimate what
can be addressed in a sprint and provides a basis for measuring
performance improvement.

13.02.2025 37
Scrum Sprint Cycle

13.02.2025 38
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 the entire project team
working with the customer to select features and
functions from the product backlog to be developed
during the sprint.

13.02.2025 39
Sprint Cycle

 Once these are accepted, the team organizes

themselves to develop the software.
 At this stage the team is isolated from the customer and
the organization and all communication is done through
the 'Scrum master'.
 The scrum master role is to protect the development
team from external distractions.
 At the end of the sprint, the work done is reviewed and
presented to stakeholders. The next sprint cycle then
starts.

13.02.2025 40
Scrum’da Team Work

 The 'scrum master' is a facilitator who organizes daily

meetings, monitors the backlog of work to be done,
records decisions, measures progress on the backlog,
and communicates with customers and management
outside the team.
 The entire team participates in short daily meetings
(Scrums) where all team members share information,
describe their progress since the last meeting, problems
that have arisen, and problems planned for the next day.
 This means everyone on the team knows what's going on and, if
problems arise, can reschedule short-term work to deal with
them.

13.02.2025 41
Scrum Advantages

 The product is divided into manageable and

understandable parts.
 Unstable requirements do not stop progress.
 The entire team has visibility of everything and team
communication is improved as a result.
 Customers see on-time delivery of increments and gain
feedback on how the product works.
 Trust is established between customers and developers,
creating a positive culture where everyone expects the
project to be successful.

13.02.2025 42
Distributed Scrum

13.02.2025 43
 Scaling Agile Methods

13.02.2025 44
Scaling Agile Methods

 Agile methods have proven successful in small and

medium-sized projects that can be developed by a small
collaborative team.
 They sometimes argue that the success of these
methods is due to the improved communication possible
when everyone works together.
 Scaling up agile methods involves modifying them to
deal with larger, longer projects, perhaps with multiple
development teams working in different locations.

13.02.2025 45
Scaling and Enlarging

 “Scaling up” is about using agile methods to develop

large software systems that cannot be developed by a
small team.
 “Scaling” is about how agile methods can be applied to a
large organization with years of software development
experience.
 When scaling agile methods, it is important to maintain
the agile fundamentals:
 Flexible scheduling, frequent system releases, continuous
integration, test-driven development and good team
communication.

13.02.2025 46
Problems Encountered In Practice With
Agile Methods
 The informality of agile development is incompatible with
the legal approach to contract definition commonly used
in large companies.
 Agile methods are best suited for new software
development rather than software maintenance.
However, in large companies, the majority of software
costs come from the maintenance of existing software
systems.
 Agile methods were designed for teams with small
partners, but now distributed teams around the world are
also developing a lot of software development software.

13.02.2025 47
Contract Issues

 Most software contracts for custom systems are based

on guidelines that specify what must be implemented by
the system developer for the customer.
 However, this prevents interleaving essentials and
development, as is the norm in agile development.
 A contract that pays for the developer's time rather than
functionality is required.
 However, this is considered a high risk for many of my legal
departments because deliverables cannot be guaranteed.

13.02.2025 48
Agile Methods and Software Maintenance
 Most organizations spend more maintaining existing
software than they do developing new software. So if agile
methods are to be successful, they need to support
maintenance as well as original development.
 Two main problems:
 Given the emphasis in the development process on minimizing
formal documentation, are systems developed using an agile
approach sustainable?
 Can agile methods be used effectively to improve a system in
response to customer demands for change?
 Problems may arise if the original development team is not
maintained.

13.02.2025 49
Agile Maintenance

 Önemli sorunlar şunlardır:

 Ürün belgelerinin eksikliği
 Müşterilerin geliştirme sürecine dahil tutulması
 Geliştirme ekibinin sürekliliğini korumak
 Çevik geliştirme, geliştirme ekibinin yapılması
gerekenleri bilmesine ve anlaması üzerinedir.
 Orijinal geliştiriciler her zaman sistem üzerinde çalışmaz
gibi uzun ömürlü sistemler için, bu gerçek bir sorundur.

13.02.2025 50
 Agile and Plan-Oriented Methods

 Most projects include elements of plan-driven and agile

processes. Deciding on balance depends on:
 Is it important to have a very detailed specification and design before
implementation? If so, you probably need to use a plan-driven
approach.
 Is a phased delivery strategy where you deliver software to
customers and get rapid feedback from them realistic? If so, consider
using agile methods.
 How big is the system under development? Agile methods are most
effective when the system can be developed with a small team that
can communicate informally. This may not be possible for larger
systems that require larger development teams, so a plan-driven
approach may need to be used.

13.02.2025 51
Agile principles and organizational
practice
Principle Application
customer engagement This depends on having a client who is willing and able to spend
time with the development team and represent all system
stakeholders. Often, customer representatives have other
demands on their time and cannot play a full role in software
development.
Where there are external stakeholders, such as regulators, it is
difficult to present their views to the Agile team.
embracing change Prioritizing changes can be extremely difficult, especially in
systems with many stakeholders. Often, each stakeholder gives
different priorities to different changes.

incremental delivery Short-term planning for rapid iterations and development does
not always mesh with the long-term planning cycles of business
planning and marketing. Marketing managers may need to know
the product's features several months in advance to prepare an
effective marketing campaign.

13.02.2025 52
Agile principles and organizational
practice

Principle Application
Keep it simple Under the pressure of delivery schedules, team members may not
have time to implement desired system simplifications.
People not transactions Individual team members may not have the appropriate personalities
for the intense involvement typical of agile methods and therefore may
not interact well with other team members.

13.02.2025 53
Agile and plan-based factors

13.02.2025 54
 System problems
 How big is the system developed?
 Agile methods are most effective in a relatively small team that can
communicate informally.
 What kind of system is being developed?
 Systems that require a lot of analysis before implementation need a
fairly detailed design to perform this analysis.
 What is the expected system lifespan?
 Long-lived systems need documentation to communicate the system
developers' intentions to the support team.
 Is the system subject to external regulation?
 If a system is regulated, you will probably need to prepare detailed
documentation as part of the system security posture.
13.02.2025 55
People and teams

 How good are the designers and programmers on the

development team?
 It is sometimes argued that agile methods require higher skill
levels than blueprint-based approaches, where programmers
translate a detailed design into code.
 How is the development team organized?
 Design documentation may be required if the team is distributed.
 What support technologies are available?
 If design documentation is not available, IDE support for
visualization and program analysis is essential.

13.02.2025 56
Organizasyonel sorunlar

 Traditional engineering organizations have a plan-based

development culture because it is the norm in
engineering.
 Is it standard corporate practice to develop a detailed
system specification?
 Will customer representatives be available to provide
feedback on system increments?
 Can informal agile development fit into an organizational
culture of detailed documentation?

13.02.2025 57
Agile methods for large systems

 Large systems are often collections of separate,

communicating systems where separate teams develop
each system. Often these teams work in different
locations, sometimes in different time zones.
 Large systems are “brownfield systems,” meaning they
include and interact with a number of existing systems.
Most of the system requirements are related to this
interaction and therefore do not really compromise
themselves on flexibility and incremental development.
 Where several systems are integrated to form one
system, a significant part of the development relates to
system configuration rather than original code
development.
13.02.2025 58
Developlemt of large systems

 Large systems and development processes are often

constrained by external rules and regulations that limit
the way they are developed.
 Large systems have a long lead and development time.
It is difficult to create cohesive teams that know the
system during that period, as people inevitably move on
to other jobs and projects.
 Large systems often have a variety of stakeholders. It is
almost impossible to involve all these different
stakeholders in the development process.

13.02.2025 59
Factors in large systems

13.02.2025 60
IBM's agility in scale model

13.02.2025 61
Scaling up to large systems

 A purely incremental approach to requirements engineering is

impossible.
 There cannot be a single product owner or customer
representative.
 For large system development, it is not possible to focus only
on the code of the system.
 Inter-team communication mechanisms should be designed
and used.
 Continuous integration is practically impossible. However, it is
very important to maintain frequent system installations and
regular releases of the system.

13.02.2025 62
Multi-team Scrum

 Role duplication
 Each team has a Product Owner for the business component
and a ScrumMaster.
 Product architects
 Each team selects a product architect, and these architects
collaborate to design and develop the overall system
architecture.
 free alignment
 Product release dates from each team are aligned to produce a
provable and complete system.
 Scrum of Scrums
 There are daily Scrum scrums where representatives from each
13.02.2025 team meet to discuss progress and plan work to be done. 63
Agile methods across organizations

 Project managers who lack experience with 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 adhere to, and due
to their bureaucratic structure, these are likely to be
incompatible with Agile methods.
 Agile methods work best when team members have a relatively
high skill level. However, within large organisations, there is
likely to be a wide range of skills and capabilities.
 There may be cultural resistance to agile methods, especially in
organizations that have a long history of using traditional
systems engineering processes.
13.02.2025 64
Key notes

 Agile methods are incremental development methods that focus on

reducing operational overhead through rapid software development,
frequent releases of software, minimizing documentation, and
producing high-quality code.
 Agile development practices,
 User stories for system definitions
 Frequent releases of software,
 Continuous software development
 Test-first development
 Customer participation in the development team.

13.02.2025 65
Key notes

 Scrum is an agile method that provides a project

management framework.
 When a system increment is developed, it is centered around a
series of sprints with fixed periods of time.
 Many practice development methods are a mix of plan-
based and agile development.
 Agile methods are difficult to scale for large systems.
 Large systems require preliminary design, and some
documentation and organizational practices may conflict with the
informality of Agile approaches.

13.02.2025 66