G51FSE

Introduction to Software Engineering

Module Code : G51FSE

Agile Software Development
Prepared by: Behrang Parhizkar (Hani)

Table of Contents

Traditional Approach
Waterfall Model & Spiral Model
Advantages & disadvantages
7 reasons to move to Agile methodology
Agile Software Development
Scrum

Lecture Goals Outline

Learn about Agile programming paradigm

Learn how Agile compares to Waterfall and Spiral

The popular agile methods

Scrum, Extreme Programming (XP), Kanban Crystal
Clear, and DSDM (Dynamic Systems Development
Methods)

Traditional approach
Requirements
Design
Implementation

Waterfall
method

Testing
Deployment &
Maintenance

Software develop in sequential order

No way back
finish this step before moving to the next

Traditional approach contd.

Advantages:

Very logical and well organized

Specialized professionals in
each domain
Tracking each step quite easier
It helps to find error easier
Easy to understand, easy to use
If everything goes well, splendid!
Documentation is produced at
every stage of a waterfall model
allowing people to understand
what has been done.

Disadvantages:

Only suitable for the small size

projects.
Difficult to estimate time and cost
for each stage
Constant testing of the design is
needed.
High amount of risk and
uncertainty
Not suitable to handle dynamic
changes in the requirements
Adjust scope during the life cycle
can kill a project

Where to Use Waterfall Model

Requirements

are very well known

Product definition is stable
Technology is understood
New version of existing product

Traditional approach contd.

Waterfall and Spiral are heavy top-down

approaches
Inflexible structure of product
Well-defined sequence of
independent development phases
Many problems with these approaches
A lot of waiting time for developers
Tons of documentation
Can result in costly unnoticed errors
and buggy code
Hard to incorporate new or changing
customer requirements

Issues of Traditional Software Development

Unclear requirements
Requirements change
Lack of involvement of the customers
Accuracy of estimation
Uneven loading of the resources
Last minute correction is very difficult
Not much time for testing
No time to fix test defects
Lot of documentation
Schedule and cost overruns
Customers not happy

Traditional approach contd.

Developers skills more important than attitudes

Customer almost out-of-the development loop

I.e. customers do not have a voice in the software

development process

They consume desired software only when over all

development processes have been completed (No early
prototype)

No way of receiving continuous feedback (from

customer/stakeholder)

As an example

Lets imagine that we want to create a blog engine; considering the

following method:
Create the blog display page; deliver it to the customer
Create the user management and membership feature; deliver it
to our customer
Add commenting capability and management; deliver it to the
customer
So on and so forth
It is a simple approach, but the customer sees the real progress of
his software and gives you immediate feedback on each new feature
It may be perfect or require tweaking, but you can quickly respond to
changes: a win-win situation

Texts source: net.tutsplus.com

10

7 Reasons to move to Agile

1.

Ambiguous Requirements
Assumption: Customers can (and shall) identify all
the requirements in the beginning
What we do: Ask customers what they want
When they really dont know
Ask them to sign off the requirements
How many of customers comfortable to sign off
the requirements form at the beginning ?
The Reality: Customers may not know all
requirements in the beginning
Result: Over production of features

What Standish Group Chaos Report Says

A survey has been conducted with customers about the

features (functions) used in traditional software

Features rarely
Or never used by
End user

Example

What is the most popular software product you have

ever used?
Excel ? Word ? Powerpoint ?
How many features are in MS Word ? (1264)
What percentage of the features of MS Word do you use
?
You might end up with less than 10% of the features.
Most of the software products have a lot of features
which are rarely or never used.
One of the reason could be: Freezing requirements at
the beginning.

Agile understand all requirements can not

be collected in the beginning of the project.
So, Requirements are collected throughout
the development cycle.
And the requirements are never frozen in
Agile .
Requirements are prioritized continuously
for the business value.

7 Reasons to move to Agile

2. Requirements Changes are Inevitable
Assumption: Cost of change increases during the
development, so freezing the requirements is absolutely
required in the beginning
What we do:
Freeze the requirements in the beginning
Penalize the customers for adding things later
Do strict change control
Reality: New ideas may emerge at any time, even just before
the major delivery.
Competitors released a new features so your clients
must do as well.
Result: changes anyway happen and both the development
team and the customers are unhappy with them

So what are the main Challenges ?

Software teams are building something that does not

exist in the beginning
The customers is attempting to describe what they
imagine this non-existent product should be.
Our developers then try to imagine what the customer is
describing and build the product they believe they heard
the customer describe.
Interestingly, the first opportunity anyone has to truly see
if the product built is one that customer really needs is
after development is complete.

Requirements Uncertainty Principle

For a new software

system, the
requirements will not be
completely known until
after the users have
used it.
Watts Huphrey

Father of Software quality

Requirements Changes are always welcome in Agile

Agile understand that requirements changes are

inevitable and they are for the competitive advantage
of the customer.

7 Reasons to move to Agile

3. Big, Upfront Planning is not Practical
Recall: Because we assume we can collect all the requirements in the
beginning and freeze the requirements, so we also assume we can plan
everything upfront.

Assumption:

What we do:

Software is so simple that development can be planned from

beginning to end.
All projects variables (scope, cost, resources, schedule, risk) can
be predicted in the beginning
Upfront planning is possible and enough
Prepare a detailed plan in the beginning
We strictly track the progress as per this plan

Reality: Big, upfront planning is difficult, planning shall also

evolve along with the requirements.
Result: Lets look at the standard industry survey result.

How Good are the Project Planning Executing?

Standish Group http://www.standishgroup.com

Failure Statistics from the Famous Standish Groups

Chaos Report:

365 respondents (from small, medium & large companies)

Major industry segments (banking, health, insurance, etc)
8380 software applications

Survey Result:
Project Success:

The project is completed on-time, on-budget, with all features

and functions as initially specified.

Project Challenged:

52.7%

The project is completed but over-budget, over the time

estimate, and offers fewer features and functions than
originally specified.

Project Impaired:

16.2%

31.1%

The project is canceled at some point during the

development cycle.

Standish Group: Project Success Factors

What were key factors for success ?

Standish Group: Project Challenged Factors

What were key factors for challenges?

Standish Group: Project Impaired Factors

What were key factors for impairment?

Failure Statistics

No significant improvements over time

What are the Success Factors?

Item

Percentage

Schedule

61.3 %

It is more important to deliver a system

when it is ready to be shipped than to
deliver it on time.

Scope

87.3 %

Meeting the actual needs of stakeholders

is more important than building the
system to specification.

Money

79.6 %

Providing the best return on investment

(ROI) is more important than delivering a
system under budget.

Quality

87.3 %

Delivering high quality is more important

than delivering on time and on budget.

Staff

75.8 %

Having a healthy, both mentally and

physically, workplace is more important
than delivering on time and on budget.

http://www.drdobbs.com/architecture-and-design/definingsuccess/202800777

 Big

, Upfront planning is not possible in the

software development as the requirements
are not complete.

Agile

In

focuses on Just in time planning

Agile, planning also evolves along

with the requirements.

7 Reasons to move to Agile

4. Reviewing the working software is better than reviewing
the documents.
Assumption:

What we do:

Ask the customers to sign off the requirements.

Reality:

Customers shall review the initial requirements and approve

them.

Most customers are not comfortable reviewing the documents

and approve them in the beginning.
Customers are rather happy in reviewing the working software.
If you show them a demo of software, they are happy, but if
you give them a bunch of documents, they are very
uncomfortable.

Result: The relationship starts in the unpleasant note.

 In

Agile, customers review actual

working software increments.

Customers

feedback on the working

software are incorporated in the
requirement development.

7 Reasons to move to Agile

5. Iterative and incremental development is better than
sequential waterfall development
Assumption: (Iterative & Incremental Development)

What we do:

Develop the software sequentially, with one big final delivery.

Reality:

Software development shall be done in sequence and step by

step manner.
Customers can wait until the completion of the project for getting
the final product.

When the customers actually get to see the final deliverables, it

may be very different from what they thought they would get.
It is too late to change anything.

Result: Most of the customers are unhappy with the

deliverables.

Look at this case

Assuming a one year project starting on January:

Analysis
Time

Design

If customer cancel the

Project at this stage

Coding

Testing
The cost of change increases

Do we have half of
the solutions now ?

In the best case, the customer get a nice requirement

Analysis document and a nice design document with
some codes with several bugs.

 In

Agile, software delivery is made to the

customers frequently in short iterations.

Customers

get small piece of prioritized

working software once in 2 to 4 weeks.

7 Reasons to move to Agile

6 . Delivery through small steps is better than a single huge
delivery at the end of delivery life cycle.
7. Frequent reflection by the project team is very important.

The reflection should happened almost every month in a one

year project rather than once at the end of the project.

Summary

Agile understand requirement will be always unclear.

Agile understand Customer may not know everything in
the beginning.
Agile starts with what customer currently know and
quickly show a demo of software based on the initial
customer requirements. (Requirements changes are
welcome in Agile)
Agile allow just in time planning throughout the project.
Agile show the working software to the customer as early
as possible and as often as possible.
Agile is based on iterative model and not sequential
order.

Surely there has to be another way?

Is it not possible to generate code in a unified yet flexible

manner?
Agile methods are a potential solution

There were a bunch of very talented and experienced

people developing some serious software
These developers observed other companies and
development teams, and how their processes made their
work easier
They compiled their observations to create the Agile
Manifesto

Texts source: net.tutsplus.com

34

http://agilemanifesto.org/

http://agilemanifesto.org/
35

Agile Software Development

Agile SD is a way of thinking about project management

Based on iterative and incremental development
Requirements as well as solutions evolve together
Collaboration between cross-functional, self-organising
teams
Teams kept small (5-9 people)

36

Principles of agile manifesto

1.
2.

3.
4.
5.

The agile manifesto has 12 main principles:

Customer satisfaction
Adapt to changing requirements
Deliver frequently
Work together frequently
Build projects with motivated individuals (It is important to provide an engaging atmosphere and
all the tools necessary to create good software. Companies lose their best workers mostly because they dont truly care
about them

6.
7.
8.

9.
10.
11.

12.

.)

Use Face to Face communication

Measure progress with working software
Maintain a constant pace (Agiles one of the advantages is the ability to precisely determine the amount of
time a project or feature will consume)
Pay attention to industrial progress
Simplicity is essential
Self organize
Reflect and adjust
37

Five main principles

The 12 main principles can be condensed to the

following five:
1.
2.
3.
4.
5.

Deliver Early and Often to Satisfy Customer

Welcome Changing Requirements
Face to Face Communication is Best
Measure Progress against Working Software
Simplicity is Essential

The art of maximizing the amount of work not done

38

Progress measure

Primary measure of progress is in terms of working

software, not lines of code.
Agile projects measure progress by the amount of
software that is currently meeting customer needs
They are 30% done when 30% of required
functionality is working AND deployed
Progress is not measured in terms of phases or
creating documents
Keeps on top of customer satisfaction and allows for
more realistic and updated estimation of costs

39

Keep it Simple

This refers to the art of maximizing the amount of work

NOT done
Agile projects always take the simplest path consistent
with their current goals
They do not try to anticipate tomorrows problems; they
only solve todays problems
High-quality work today should provide a simple and
flexible system that will be easy to change tomorrow if the
need arises
Only do the job the client wants, without any additional
functionalities and improvements, your work load will
lighten, and youll achieve your goals
Ultimately, that is all the customer cares about
40

Thats a bit Abstract!

The agile ethos is a bit abstract from the process of

actually applying the principles in a sound methodology
Different people interpret the manifesto in different
ways
The popular agile methods
Scrum, Extreme Programming (XP), Kanban, Crystal
Clear, and DSDM (Dynamic Systems Development
Methods)
The other methods available are Agile Unified Process
(AUP), Agile Modeling, Adaptive Software Development,
FDD (Feature Driven Development), and Lean Software
Development.
41

Scrum

A typical, but detailed, Agile methodology

One of the best Agile software development method
See http://www.youtube.com/watch?v=Q5k7a9YEoUI for
a very good 10 min. introduction

Manage a prioritized list of needs on a product backlog,

collaborate through daily standup meetings, exhibit the
product upon iteration completion, use retrospectives to
correct the process

42

Scrum
Rugby union:
A scrum is a way to
restart the game after an
interruption, where the
forwards of each side
come together in a tight
formation and struggle to
gain possession of the
ball when it is tossed in
among them

Image source: wikipedia.org

43

Product backlog

Product backlog contains all

user stories (requirements) of
features that the product
needs/could have

Product backlog is meant to

grow over time

44

Scrum Team

No. 1: Product owner

No. 2: The Scrum Team
No. 3: The Scrum Master

There are no roles in the team. Everyone should be able to

work on everything

45

Scrum Master

Scrum master is responsible for the Scrum process

Scrum Master is like a project manager
Three main roles:
1. Coach
2. Fixer
3. Gatekeeper
Two main tasks:
1. Protecting team from outside disturbances
2. Removing obstacles

46

Release planning

Team and customer pick features from product backlog

This creates a release backlog
Release backlog features are assigned priority
Release backlog features are assigned effort estimates
Release is split in a number of sprints

47

Scrum sprint

Sprints last approximately 3 30 days

Each release consists of 4-12 sprints
Duration of sprint is proportional to release interval
Sprint backlog lists features included per sprint

48

Monitoring progress

Per the Agile manifesto, progress is measured in terms

of functionality added

Time to complete features in active sprints drawn in a

burndown chart

Burndown chart is updated daily

Burndown velocity can be measured from chart

Team estimates daily how much time is required per

remaining feature
49

How to calculate Velocity

Scenario:
Our team delivers 3 user stories. The sum of the story
points equals 20. Our velocity is then 20.
If, in the next iteration, our team delivers 30 story
points, then our average velocity is 25, or
(20 SP + 30 SP) divided by 2 iterations = 25 SP.

Some concepts

Imagine you want to go to a trip. You know your trip will

be 1000 miles long. This is the size. Another variable
is the time. You want to pass this 1000 miles in 5 days.
This is a duration.
It is possible to calculate planned velocity as 1000 miles
per 5 day.
Velocity therefore defines how much of progress are
you able to do.
When we are talking about story points, we are talking
about the size.

Burndown chart

The burndown is a chart that shows how quickly you and your
team are burning through your customer's user stories.
It shows the total effort against the amount of work we deliver each
iteration
Image&Text source: http://www.agilenutshell.com/burndown

Burndown chart contd.

Image&Text source: http://www.agilenutshell.com/burndown

Burndown chart contd.

Image source: wikipedia.org

54

Burndown chart contd.

Projected line: is a straight line that connects the start point to the end point
At day 0 (the first day of the iteration), the remaining effort is at its highest because nothing has
been completed
At the end of the iteration (day 20), the sum should be 0 because there are no tasks left to
be completed

Image&Texts source: wikipedia.org

55

Burndown chart contd.

Actual Work Remaining Line: shows the actual work remaining

At the start point, the actual work remaining is the same as the ideal work remaining but as time
progresses, the actual work line fluctuates above and below the ideal line depending on how
effective the team is

Image&Texts source: wikipedia.org

56

Burndown chart contd.

If the actual remaining effort line is above the blue line for an extended period, then it means
adjustments have to be made to the project. This could mean dropping a task, assigning
additional resources, or working late, all of which can be unpleasant
What should be the correct Y-axis parameter to determine remaining effort
http://www.methodsandtools.com/archive/scrumburndown.php

Image&Texts source:inpointform.net

57

Bugs

Bugs traditionally wreak havoc to project planning

In scrum a defect backlog is maintained per sprint
Often dedicated bug kill sprints are introduced

58

The Scrum

Daily meeting

Meeting should be held standing

Keep people on their toes
Keep meetings short and to the point

Discusses what was done yesterday

Discusses what will be done today

Excellent tool to spot issues as they arise

59

The Scrum Questionnaire

(retrospectives )
Each Sprint ends with a retrospective. At this meeting, the
team reflects on its own process. They inspect their
behavior and take action to adapt it for future Sprints.
Every team member has to answer three question:
1. What have I done since last meeting?
2. What will I do until the next meeting?
3. What problems have I encountered?

During scrum meeting only team speaks.

60

Scrum Time!
Product: A web site that lets users search, compare, and
review apps for both Apple and Android platforms

Get together in teams of 5

Assign roles
Create a time planning:
Product backlog
1st release
Sprints of 1st release
Initialise burndown chart
Hold day-1 Scrum meeting
Present your time planning
61

Scrum for larger projects

We agree that Scrum is ideal for small sized project

What about when we need a very large team working on
a single project, or on closely related projects in a large
programme?
Possibly using Scrum of Scrums technique
Each team meets every day and holds their daily
Scrum as usual. One or two representatives from each
Scrum team attend a higher level Scrum to coordinate
across teams. And on very large teams, one or two
representatives from the higher level Scrum attends an
even higher level Scrum, and so on

62

Scrum Software Tools

Axosoft:

Scrum Software Tools

Scrumwise:

Scrum Software Tools

Targetprocess:

Extreme programming (XP)

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
Software should be tested frequently during development

Extreme programming advocates testing code literally every few

minutes, after every minor change

Extreme programming works best for relatively small projects with a

small number of good programmers

Text source: Ian Sommerville04 XP slides

66

XP values

Communication

Simplicity

From the system: Unit tests

From the customer: Acceptance tests
From the team: Estimate the time to implement new requirements

Courage

Extreme programming encourages starting with the simplest solution.

Extra functionality can then be added later

Feedback

Use simple designs and common metaphors, talk continuously with your
programmers and customers

Code for today, and not tomorrow

Refactor as appropriate
Be willing to throw code away

Respect

Trust your team members not to submit nonworking code

67

XP practices

The XP practices we will emphasize are:

Pair Programming
Teams of two people
Test Driven Development
Writing lots of tests, and writing them early
Continuous Integration
Putting code together as you write it, not at the last minute
Coding Standards
Learn and follow well-established conventions
Collective Code Ownership
You are responsible for your partners code
Simple Design
Stay away from confusion

Text source: Wikipedia.org

68

Pair programming
Pair programming is an agile software
development technique in which
two programmers
work together at one workstation.
One, the driver,
writes code while the other,
the observer or navigator,
reviews each line of code as it is typed in.
The two programmers switch roles frequently.
While reviewing, the observer also considers
the strategic direction of the work, coming up
with ideas for improvements and likely future
problems to address.
--Laurie Williams
North Carolina State University
Computer Science

Texts&Image source: wikipedia.org

69

Differences Between Scrum and XP

Scrum teams typically work in iterations (called sprints) that are

from two weeks to one month long. XP teams typically work in
iterations that are one or two weeks long.

Scrum teams do not allow changes into their sprints. Once the
sprint planning meeting is completed and a commitment made to
delivering a set of product backlog items, that set of items remains
unchanged through the end of the sprint. XP teams are much more
amenable to change within their iterations. As long as the team
hasnt started work on a particular feature, a new feature of
equivalent size can be swapped into the XP teams iteration in
exchange for the unstarted feature.

Text source: Mike Cohn , Mountain Goat Software

70

Summary

Agile software development is a software

development/project management approach
Agile projects incrementally create an evolving product
Agile uses small cross-functional teams with heavy
commitment of the customer
Scrum/XP Agile methodologies