Agile Software

Enginering

Presented by:
Dr. Yasmine Afify
yasmine.afify@cis.asu.edu.eg
Agenda

● T raditio nal develo p ment

● W h at’s/W h y Agile?
● Agile manifesto
● Plan-driven vs. agile develo p ment
● Agile Princip les
● Agile develo p ment ap p ro ach es
● S caling agile meth o ds
W aterfall M o del
G ame

The goal is to complete two identical tables by writing the letters a to j,

the numbers 1 to 10, and Roman numerals i to x.
One table is completed a row at a time, and the other is completed a
column at a time.

Alphabet Numbers Roman

Letters Numerals
W h ich ap p ro ach do yo u p refer?

Rows ( No wip / multitasking ) vs .columns ( WIP =1 / Focus on 1 project at a time)

- which one was faster ?

- with which one were you more focused?

- which one gives you more satisfaction?

- which one was more stressful?

- which one is more error occurrence?

- which one is more complex to work?

 W h at’s/W h y
01 Agile ?
W h at’s/W h y Agile?

● Agile is the ability to create and respond to change. It

is a way of dealing with, and ultimate succeeding in an
uncertain environment.

● Agile project management is an iterative

development methodology.
● Agile is a time boxed, iterative approach to software
delivery.
Deviatio n fro m G o al
W h at’s/W h y Agile?
02 Agile M anifesto
M anifesto F o r Agile
 M anifesto F o r Agile

1. Individuals and interactions over processes and tools

This value of the Agile manifesto focuses on giving
importance to communication with the clients. There are
several things a client may want to ask, and it is the
responsibility of the team members to ensure that all
questions and suggestions of the clients are promptly dealt
with.

2. Working product over comprehensive documentation

In the past, more focus used to be on proper documentation
of every aspect of the project. There were several times
when this was done at the expense of the final product. The
Agile values dictate that the first and foremost duty of the
project team is completing the final deliverables as
identified by the customers.
 M anifesto F o r Agile

3. Customer collaboration over contract negotiation

Agile principles require customers to be involved in all phases of the
project. The Waterfall/traditional methodologies only allow customers to
negotiate before and after the project. This used to result in wastage of
both time and resources. If the customers are kept in the loop during the
development process, team members can ensure that the final product
meets all the requirements of the client.

4. Responding to change over following a plan

Contrary to the management methodologies of the past, Agile values are
against using elaborate plans before the start of the project and continue
sticking to them no matter what. Circumstances change and sometimes
customers demand extra features in the final product that may change the
project scope. In these cases, project managers and their teams must
adapt quickly to deliver a quality product and ensure 100% customer
satisfaction.
R ap id so ftw are develo p ment

R ap id develo p ment and delivery is no w o ften th e mo st

imp o rtant req uirement fo r so ftw are systems
B usinesses o p erate in a fast – ch anging req uirement and it
is p ractically imp o ssible to p ro duce a set o f stable
so ftw are req uirements
S o ftw are h as to evo lve q uickly to reflect ch anging
business needs.
R ap id so ftw are develo p ment
o S p ecificatio n,design and imp lementatio n are inter-
leaved
o S ystem is develo p ed as a series o f versio ns w ith
stakeh o lders invo lved in versio n evaluatio n
o U ser interfaces are o ften develo p ed using an IDE and
grap h ical to o lset.
Agile meth o ds
Dissatisfactio n w ith th e o verh eads invo lved in so ftw are design meth o ds o f
th e 1 9 8 0 s and 1 9 9 0 s led to th e creatio n o f agile meth o ds. T h ese meth o ds:

o F o cus o n th e co de rath er th an th e design

o Are based o n an iterative ap p ro ach to so ftw are develo p ment

o Are intended to deliver w o rking so ftw are q uickly and evo lve th is q uickly
to meet ch anging req uirements.

T h e aim o f agile meth o ds is to reduce o verh eads in th e so ftw are p ro cess

(e.g. by limiting do cumentatio n) and to be able to resp o nd q uickly to
ch anging req uirements w ith o ut excessive rew o rk.
03 Plan-driven vs
Agile Development
Plan-driven develo p ment

• Plan-driven develo p ment attemp t to p lan fo r and

anticip ate up fro nt all o f th e features a user migh t
w ant in th e end p ro duct, and to determine h o w best
to build th o se features.

• T h ey are o ften called seq uential p ro cesses because

p ractitio ners p erfo rm, in seq uence, a co mp lete
req uirements analysis fo llo w ed by a co mp lete
design fo llo w ed in turn by co ding/building and th en
testing.

• T h e better th e p lanning, th e better th e

understanding, and th erefo re th e better th e
executio n.
Plan-driven Ap p licability

• Plan-driven develo p ment w o rks w ell if yo u are

ap p lying it to p ro blems th at are w ell defined,
p redictable, and unlikely to undergo any significant
ch ange.

• T h e p ro blem is th at mo st p ro duct develo p ment

effo rts are anyth ing but p redictable, esp ecially at
th e beginning.

• S o , w h ile a p lan-driven p ro cess gives th e

imp ressio n o f an o rderly, acco untable, and
measurable ap p ro ach ,th at imp ressio n can lead to a
false sense o f security. After all, develo p ing a
p ro duct rarely go es as p lanned.
Agile Develo p ment

● Agile, o n th e o th er h and, is based o n a

different set o f beliefs— o nes th at do map
w ell to p ro blems w ith eno ugh uncertainty
to make h igh levels o f p redictability
difficult.
Agile ap p licability

Pro duct develo p ment w h ere a so ftw are co mp any

is develo p ing a small o r medium-sized p ro duct.

C usto m system develo p ment w ith in an

o rganizatio n, w h ere th ere is a clear co mmitment
fro m th e custo mer to beco me invo lved in th e
develo p ment p ro cess and w h ere th ere are no t a
lo t o f external rules and regulatio ns th at affect
th e so ftw are.
T ech nical,h uman,o rganizatio nal issues
M o st p ro jects include elements o f p lan-driven and agile
p ro cesses. Deciding o n th e balance dep ends o n:

• Is it imp o rtant to h ave a very detailed sp ecificatio n and design

befo re mo ving to imp lementatio n? If so , yo u p ro bably need to
use a p lan-driven ap p ro ach .

• Is an incremental delivery strategy, w h ere yo u deliver th e

so ftw are to custo mers and get rap id feedback fro m th em,
realistic? If so , co nsider using agile meth o ds.

• H o w large is th e system th at is being develo p ed? Agile

meth o ds are mo st effective w h en th e system can be develo p ed
w ith a small co -lo cated team w h o can co mmunicate info rmally.
T h is may no t be p o ssible fo r large systems th at req uire larger
develo p ment teams so a p lan-driven ap p ro ach may h ave to be
used.
T ech nical,h uman,o rganizatio nal issues
W h at typ e o f system is being develo p ed?
• Plan-driven ap p ro ach es may be req uired fo r systems
th at req uire a lo t o f analysis befo re imp lementatio n
(e.g. real-time system w ith co mp lex timing
req uirements).

W h at is th e exp ected system lifetime?

• Lo ng-lifetime systems may req uire mo re design
do cumentatio n to co mmunicate th e o riginal
intentio ns o f th e system develo p ers to th e sup p o rt
team.

W h at tech no lo gies are available to sup p o rt system

develo p ment?
• Agile meth o ds rely o n go o d to o ls to keep track o f an
evo lving design.
T ech nical,h uman,o rganizatio nal issues

H o w go o d are th e designers and p ro grammers in th e

develo p ment team?
• It is so metimes argued th at agile meth o ds req uire
h igh er skill levels th an p lan-based ap p ro ach es in
w h ich p ro grammers simp ly translate a detailed
design into co de.

Is th e system subject to external regulatio n?

• If a system h as to be ap p ro ved by an external
regulato r th en yo u w ill p ro bably be req uired to
p ro duce detailed do cumentatio n as p art o f th e
system safety case.
04 Princip les o f Agile
2
8
Agile
Princip les
Agile Princip les
E mp lo y Iterative and Incremental Develo p ment
o Iterative development is based on the
principle that we will probably get things wrong
before we get them right and that we will do
things poorly before we do them well. It is a
planned rework strategy. We use multiple
passes to improve what we are building so that
we can converge on a good solution.
o Incremental development is based on the
principle of “Build some of it before you build
all of it.” We break the product into smaller
pieces so that we can build some of it, learn
how each piece is to survive in the
environment in which it must exist, adapt
based on what we learn, and then build more
of it.
Agile Princip les

o Scrum (an Agile approach) leverages the benefits

of both iterative and incremental development,
while negating the disadvantages of using them
individually.
o Scrum does this by using both ideas in an adaptive
series of timeboxed iterations called sprints.
Agile Princip les

o During each sprint we perform all of the

activities necessary to create a working
product increment (some of the product,
not all of it).
o Some analysis, design, build, integration,
and test work is completed in each sprint.
o This all-at-once approach has the benefit
of quickly validating the assumptions that
are made when developing product
features.
Agile Princip les
Predictio n and Adap tatio n
o Never make a premature decision just
because a generic process would dictate that
now is the appointed time to make one.
o Instead, we favour a strategy of keeping our
options open. This principle is referred to as
the last responsible moment (LRM),
meaning that we delay commitment and do
not make important and irreversible decisions
until the last responsible moment. And when
is that? When the cost of not making a
decision becomes greater than the cost of
making a decision. At that moment, we make
the decision.
Agile Princip les
F avo r an Adap tive,E xp lo rato ry Ap p ro ach

o Exploration refers to times when we choose

to gain knowledge by doing some activity,
such as building a prototype, creating a proof
of concept, performing a study, or conducting
an experiment.
o In other words, when faced with uncertainty,
we buy information by exploring.
Agile Princip les
E mbrace C h ange in an E co no mically
S ensible W ay

o .
Agile Princip les
E mbrace C h ange in an E co no mically
S ensible W ay

o In Agile, we must be prepared to embrace

change. Goal is to keep the cost-of-change
curve flat for as long as possible—making it
economically sensible to embrace even late
change
Agile Princip les
B alance Predictive U p -F ro nt W o rk w ith Adap tive
J ust-in-T ime W o rk
o Being overly predictive would require us to make many
assumptions in the presence of great uncertainty.
o Being overly adaptive could cause us to live in a state of
constant change, making our work feel inefficient and
chaotic.
 Agile Development
05 Approaches
Agile Develo p ment Ap p ro ach es
R eq uirements scenario s

o User requirements are expressed as

scenarios or user stories.
o 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.
o The customer chooses the stories for
inclusion in the next release based on
their priorities and the schedule
estimates.
A ‘p rescribing medicatio n’sto ry
E xamp les o f task cards fo r p rescribing medicatio n
R efacto ring

o Programming team look for possible

software improvements and make these
improvements even where there is no
immediate need for them.
o This improves the understandability of the
software and so reduces the need for
documentation.
o Changes are easier to make because the
code is well-structured and clear.
o However, some changes requires
architecture refactoring and this is much
more expensive.
E xamp les o f R efacto ring

o Re-organization of a class hierarchy to

remove duplicate code.
o Tidying up and renaming attributes and
methods to make them easier to
understand.
o The replacement of inline code with
calls to methods that have been
included in a program library.
C usto mer Invo lvement

o Customer role in testing process is to help

develop acceptance tests for the stories that
are to be implemented in the next release of
the system.
o 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.
o However, people adopting the customer role
have limited time available and so cannot work
full-time with the development team. They may
feel that providing the requirements was
enough of a contribution and so may be
reluctant to get involved in the testing process.
Pro blems w ith Agile

o It can be difficult to keep th e interest o f custo mers

w h o are invo lved in th e p ro cess.

o T eam members may be unsuited to th e intense

invo lvement th at ch aracterizes agile meth o ds.

o Prio ritizing ch anges can be difficult w h ere th ere are

multip le stakeh o lders.

o M aintaining simp licity req uires extra w o rk.

o C o ntracts may be a p ro blem as w ith o th er

ap p ro ach es to iterative develo p ment.
 Scaling Agile
06 Methods
S caling Agile M eth o ds

o Agile methods have proved to be successful

for small and medium sized projects that
can be developed by a small co-located
team.
o It is sometimes argued that the success of
these methods comes because of improved
communications which is possible when
everyone is working together.
o Scaling up agile methods involves changing
these to cope with larger, longer projects
where there are multiple development
teams, perhaps working in different
locations.
 Large systems develo p ment

o 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.
o 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.
 Large systems develo p ment

o Large systems and their development processes

are often constrained by external rules and
regulations limiting the way that they can be
developed.
o 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.
o Large systems usually have a diverse set of
stakeholders. It is practically impossible to involve
all of these different stakeholders in the
development process.
 S caling o ut and scaling up

o ‘Scaling up’ is concerned with using agile

methods for developing large software
systems that cannot be developed by a small
team.
o ‘Scaling out’ is concerned with how agile
methods can be introduced across a large
organization with many years of software
development experience.
o When scaling agile methods, it is essential to
maintain agile fundamentals.
o Flexible planning, frequent system releases,
continuous integration, test-driven
development and good team communications.
 S caling up to large systems

o 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.
o Cross-team communication mechanisms involve
regular phone and video conferences between
team members and frequent, short electronic
meetings where teams update each other on
progress.
o 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.
 S caling o ut to large co mp anies

o Project managers who do not have experience of

agile methods may be reluctant to accept the risk of
a new approach.
o 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 methods.
o 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.
o There may be cultural resistance to agile methods,
especially in those organizations that have a long
history of using conventional engineering processes.
5
5

h ttp s://bit.ly/C areer-W eek-2 0 2 4

5
6