Agile Methods

• Agile methods
• Examples of Agile Methods
• Extreme programming
• Scrum

1
Agile Methods

• Rationale
• Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements
• Software has to evolve quickly to reflect changing business needs.
• Specification, design and implementation are inter-leaved
• System is developed as a series of versions with stakeholders
involved in version evaluation

2
Agile methods …

• Agile 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.
• The 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.

3
Agile manifesto

❖Individuals and interactions over processes and tools

❖Working software over comprehensive documentation
❖Customer collaboration over contract negotiation
❖Responding to change over following a plan

• That is, while there is value in the items on the right, we

value the items on the left more.

4
Agile methods Principles
There are 12 principles. Five of them are provided below

Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
5
Agile Methods Example: XP (Extreme
Programming)
• XP is an agile software methodology
• Higher priority on adaptability (“empirical process control
model”) than on predictability (“defined process control model”)
• Change in the requirements is normal during software
development
• Software developer must be able react to changing
requirements at any point during the project
• XP prescribes a set of day-to-day practices for managers and
developers to address this problem.

6
XP Day-to-Day Practices

1. Rapid feedback
• Confronting issues early results in more time for
resolving issues. This applies both to client feedback
and feedback from testing
2. Simplicity
• The design should focus on the current requirements
• Simple designs are easier to understand and change
than complex ones
3. Incremental change
• One change at a time instead of many concurrent
changes
• One change at a time should be integrated with the
current baseline.

7
XP day-to-day …

4. Embracing change
• Change is inevitable and frequent in XP projects
• Change is normal and not an exception that needs to
be avoided
5. Quality work
• Focus on rapid projects where progress is
demonstrated frequently
• Each change should be implemented carefully and
completely.

8
How much planning in XP?

• Planning is driven by requirements and their

relative priorities
• Requirements are elicited by writing stories with the
client (called user stories)
• User stories are high-level scenarios or use cases
that encompass a set of coherent features
• Developers decompose each user story in terms of
development tasks that are needed to realize the
features required by the story
• Developers estimate the duration of each task in terms
of days
• If a task is planned for more than a couple of weeks, it
is further decomposed into smaller tasks.

9
How much planning in XP? …

• Stacks
• The user stories are organized into stacks of related
functionality
• Prioritization of stacks
• The client prioritizes the stacks so that essential
requirements can be addressed early and optional
requirements last
• Release Plan
• Specifies which story will be implemented for which
release and when it will be deployed to the end user
• Schedule
• Releases are scheduled frequently (e.g., every 1–2
months) to ensure rapid feedback from the end users.

10
Team Organization in XP

• Production code is written in pairs (pair

programming)
• Individual developers may write prototypes for
experiments or proof of concepts, but not
production code
• Moreover, pairs are rotated often to enable a
better distribution of knowledge throughout the
project.

11
How much modeling in XP?

• No explicit analysis/design models

• Minimize the amount of documentation
• Fewer deliverables reduce the duplication of issues
• Models are only communicated among
participants
• The client is the “walking specification”
• Source Code is the only external model
• The system design is made visible in the source code
by using descriptive naming schemes
• Refactoring is used to improve the source code
• Coding standards are used to help developers
communicate using only the source code.

12
How much process in XP?

• Iterative life cycle model with 5 activities:

planning, design, coding, testing and integration
• Planning occurs at the beginning of each iteration
• Design, coding, and testing are done incrementally
• Source code is continuously integrated into the main
branch, one contribution at the time
• Unit tests for all integrated units; regression testing
• Constraints on these activities
• Test first. Unit tests are written before units. They are
written by the developer
• When defects are discovered, a unit test is created to
reproduce the defect
• Refactor before extending the source code.

13
How much control in XP?

• Reduced number of formal meetings

• Daily stand up meeting for status communication
• No discussions to keep the meeting short
• No inspections and no peer reviews
• Pair programming is used instead
• Production code is written in pairs, review during
coding.
• Self-organizing system with a leader:
• The Leader communicates the vision of the system
• The leader does not plan, schedule or budget
• The leader establishes an environment based on
collaboration, shared information, and mutual trust
• The leader ensures that a product is shipped.

14
Scrum (adapted from Marty Stepp)
• Is an agile, lightweight process
• Can manage and control software and product
development
• Uses iterative, incremental practices
• Has a simple implementation
• Embraces adaptive systems development
• Embraces the opposite of the waterfall approach…

15
Scrum at a Glance

24 hours
Daily Scrum
Meeting

Backlog tasks 30 days

expanded
Sprint Backlog by team

Potentially Shippable
Product Backlog Product Increment
As prioritized by Product Owner

16
Sequential vs. Overlap

Requirements Design Code Test

Rather than doing all of one

thing at a time...
...Scrum teams do a little of
everything all the time

17
Scrum Framework

Roles
•Product owner
•Scrum Master
•Team Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts 18
Scrum Roles

• Product Owner
• Possibly a Product Manager or Project Sponsor
• Decides features, release date, prioritization, $$$

• Scrum Master
• Typically, a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Remove impediments / politics, keeps everyone
productive

• Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• Membership should change only between sprints

19
Daily Scrum Meeting

• Parameters
• Daily, ~15 minutes, Stand-up

• Not for problem solving

• Only team members, Scrum Master, product owner, can
talk
• Helps avoid other unnecessary meetings

• Three questions answered by each team member:

1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?

20
Scrum's Artifacts

• Scrum has remarkably few artifacts

• Product Backlog
• Sprint Backlog
• Burndown Charts

• Can be managed using just an Excel

spreadsheet
• More advanced / complicated tools exist:
• Expensive
• Web-based – no good for Scrum Master/project
manager who travels
• Still under development

21
Product Backlog

• The requirements

• A list of all desired work

on project

• Ideally expressed as a list

of user stories along with
"story points", such that
each item has value to
users or customers of the
This is the product
product backlog
• Prioritized by the product
owner

• Reprioritized at start of
each sprint
22
User Stories

• Instead of Use Cases, Agile project owners do

"user stories"
• Who (user role) – Is this a customer, employee,
admin, etc.?
• What (goal) – What functionality must be
achieved/developed?
• Why (reason) – Why does user want to accomplish
this goal?

As a [user role], I want to [goal], so I can

[reason].

• Example:
• "As a user, I want to log in, so I can access subscriber
content."
23
Sample Product Backlog

Backlog item Estimate

Allow a guest to make a reservation 3 (story points)

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-

8
per-available-room)

Improve exception handling 8

... 30

... 50
24
Sprint Backlog

• Individuals sign up for work of their own

choosing
• Work is never assigned
• Estimated work remaining is updated daily

• Any team member can add, delete change sprint

backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item
with a larger amount of time and break it down
later
• Update work remaining as more becomes known

25
Sample Sprint backlog

Tasks Mon Tue Wed Thu Fri

Code the user interface 8 4 8
Code the middle tier 16 12 10 4
Test the middle tier 8 16 16 11 8
Write online help 12
Write the Foo class 8 8 8 8 8
Add error logging 8 4

26
Sprint Burndown Chart

• A display of what work has been completed

and what is left to complete
• one for each developer or work item
• updated every day
• (make best guess about hours/points completed each
day)

• variation: Release burndown chart

• shows overall progress
• updated at end of each sprint

27
Sample Burndown Chart
Hours

28
 Tasks Mon Tue Wed Thu Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50
40
30
Hours

20
10
0
Mon Tue Wed Thu Fri

29
 Burndown Example 1

No work being performed

Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint

30
 Burndown Example 2

Work being performed, but not fast enough

Sprint 1 Burndown

49

48

47

46
Hours remaining

45

44

43

42

41

40
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint

31
 Burndown Example 3

Work being performed, but too fast!

Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint

32
The Sprint Review

• Team presents what it accomplished during the

sprint
• Typically takes the form of a demo of new
features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates

33
Problems with agile methods

• It can be difficult to keep the interest of customers who

are involved in the process.
• Team members may be unsuited to the intense
involvement that characterizes agile methods.
• Prioritising changes can be difficult where there are
multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches
to iterative development.

34
Agile methods and software maintenance

• Most organizations spend more on maintaining existing

software than they do on new software development.
So, if agile methods are to be successful, they have to
support maintenance as well as original development.
• Two key issues:
• Are systems that are developed using an agile approach
maintainable, given the emphasis in the development process
of minimizing formal documentation?
• Can agile methods be used effectively for evolving a system in
response to customer change requests?
• Problems may arise if original development team
cannot be maintained.

35