Chapter 3 – Agile Software Development

30/10/2014 Chapter 3 Agile Software Development 1

Topics covered

 Agile Manifesto

 Agile methods

 Agile user story

 Scaling Scrum

30/10/2014 Chapter 3 Agile Software Development 2

History

 Dissatisfaction in software industry 1980-1990

 Developed late 1990 to overcome problems in old methods
 Refactoring
 Pair programming
 Scrum
 XP
 CI
 Agile manifesto 2001
 TDD
 BDD
 Clean Code
3
Agile in a nutshell

 Rapid development and delivery

 Frequent delivery
 Incremental versions
 Minimal documentation
 Extensive tool support
 Interleaved activities
 Respond to changes quickly
 Reduced process overhead
30/10/2014 Chapter 3 Agile Software Development 4
 Agile methods

30/10/2014 Chapter 3 Agile Software Development 5

30/10/2014 Chapter 3 Agile Software Development 6
Agile manifesto & Values

 We are uncovering better ways of developing software

by doing it and helping others do it. Through this work
we have come to value:
1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

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

30/10/2014 Chapter 3 Agile Software Development 7

The 12 principles of agile methods

1. Customer satisfaction by early and continuous delivery of

valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months).
4. Close, daily cooperation between business people and
developers
5. Projects are built around motivated individuals, who should be
trusted
6. Face-to-face conversation is the best form of communication
(co-location)
30/10/2014 Chapter 3 Agile Software Development 8
The 12 principles of agile methods

7. Working software is the primary measure of progress

8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not
done—is essential
11. Best architectures, requirements, and designs emerge from
self-organizing teams
12. Regularly, the team reflects on how to become more effective,
and adjusts accordingly

30/10/2014 Chapter 3 Agile Software Development 9

Agile principles in a nutshell

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.

30/10/2014 Chapter 3 Agile Software Development 10

When Agile is applicable

 Small/medium size products.

 Customer is available and involved

 Cross functional team

 Organization mindset

30/10/2014 Chapter 3 Agile Software Development 11

 Agile development techniques

30/10/2014 Chapter 3 Agile Software Development 12

eXtreme Programming

30/10/2014 Chapter 3 Agile Software Development 13

The extreme programming release cycle

30/10/2014 Chapter 3 Agile Software Development 14

Extreme programming practices (a)

Principle or practice Description

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

Small releases The minimal useful set of functionality that provides business
value is developed first. 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 development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
30/10/2014 Chapter 3 Agile Software Development 15
Extreme programming practices (b)

Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all 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.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use 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.
30/10/2014 Chapter 3 Agile Software Development 16
How to map XP practices to Agile?

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

30/10/2014 Chapter 3 Agile Software Development 17

Influential XP practices

 Difficult to integrate with management strategy in most

organizations.
 Used practices
 User stories for specification

 Refactoring

 Test-first development

 Pair programming

30/10/2014 Chapter 3 Agile Software Development 18

User stories for requirements

30/10/2014 Chapter 3 Agile Software Development 19

User story template

30/10/2014 Chapter 3 Agile Software Development 20

Sample user story

30/10/2014 Chapter 3 Agile Software Development 21

Sample user story
Sample user story

30/10/2014 Chapter 3 Agile Software Development 23

User story details

30/10/2014 Chapter 3 Agile Software Development 24

Levels of requirements

30/10/2014 Chapter 3 Agile Software Development 25

Done definition

30/10/2014 Chapter 3 Agile Software Development 26

Sample test case description

30/10/2014 Chapter 3 Agile Software Development 27

Refactoring

 Remove duplicate code.

 Logical naming for attributes and methods.

 Replace inline with method calls.

 Enhancing performance

 Documenting complex functions

 Re-architecture

30/10/2014 Chapter 3 Agile Software Development 29

TDD: Test Driven 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.

30/10/2014 Chapter 3 Agile Software Development 30

Practice: Red-Green-Refactor

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

30/10/2014 Chapter 3 Agile Software Development 31

Pair programming

 Pairs: developing code together

 Collective ownership

 Considered as informal review process.

 It encourages refactoring as the whole team can benefit

from improving the system code.

 Knowledge sharing

30/10/2014 Chapter 3 Agile Software Development 32

 Agile project management

30/10/2014 Chapter 3 Agile Software Development 33

Manger role

 Manage the project

 Delivery on time
 Within the budget
 What should be delivered
 When should be delivered
 Who will develop the deliverables
 Agile project management requires a different approach,
which is adapted to incremental development and the
practices used in agile methods.
30/10/2014 Chapter 3 Agile Software Development 34
Scrum

 A lightweight agile software development framework for

managing product and application development

 Phases
 Discovery: specs, plan & design
 Implementation: series of sprint cycles
 Closure: user manuals, project retrospective, lessons
learnt

30/10/2014 Chapter 3 Agile Software Development 35

Scrum terminology (a)

Scrum term Definition

Development team A self-organizing group of software developers, which should be no more than
7 people. They are responsible for developing the software and other
essential project documents.
Potentially shippable The software increment that is delivered from a sprint. The idea is that this
product increment should be ‘potentially shippable’ which means that it is in a finished state and
no further work, such as testing, is needed to incorporate it into the final
product. In practice, this is not always achievable.

Product backlog 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 supplementary tasks that are needed, such as architecture
definition or user documentation.

Product owner 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 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.
30/10/2014 Chapter 3 Agile Software Development 36
 Scrum terminology (b)

Scrum term Definition

Scrum A 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 that includes the whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum processis
followed and guides the team in the effective use of Scrum. He or sheis
responsible for interfacing with the rest of the company and for ensuring
that the Scrum team is not diverted by outside interference. The Scrum
developers are adamant that the ScrumMaster should not be thought of
as a project manager. Others, however, may not always find it easy to
see the difference.

Sprint A development iteration. Sprints are usually 2-4 weekslong.

Velocity 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 be covered in a sprint and provides a basis for measuring
improving performance.

30/10/2014 Chapter 3 Agile Software Development 37

Scrum overview

30/10/2014 Chapter 3 Agile Software Development 38

The Scrum sprint cycle

30/10/2014 Chapter 3 Agile Software Development 39

Product Backlog

30/10/2014 Chapter 3 Agile Software Development 40

Product backlog vs iteration backlog

30/10/2014 Chapter 3 Agile Software Development 41

Release vs Sprint

30/10/2014 Chapter 3 Agile Software Development 42

The Sprint cycle

 Team committed to develop the selected stories

 Team is isolated from the customer

 External communication thru ‘Scrum master’.

 At the end of the sprint, the work done is reviewed and

presented to stakeholders. The next sprint cycle then
begins.

30/10/2014 Chapter 3 Agile Software Development 43

Inside a sprint – little of everything all time

30/10/2014 Chapter 3 Agile Software Development 44

Scrum benefits

 The product is broken down into a set of manageable

and understandable chunks.
 Unstable requirements do not hold up progress.
 The whole team have visibility of everything and
consequently team communication is improved.
 Customers see on-time delivery and provide early
feedback.
 Trust between customers and developers is established

30/10/2014 Chapter 3 Agile Software Development 45

 User story estimation

30/10/2014 Chapter 3 Agile Software Development 46

Estimation

 Relative estimation is better than absolute

 Fibonacci numbers are mostly used

 No point of discussing one point difference

 The range has more lower value numbers

 Story point estimation

30/10/2014 Chapter 3 Agile Software Development 47

Story point

 Units of relative size

 Combination of a story’s [Complexity/Difficulty –

Relative time – Uncertainty]

 Estimation don’t expire

 Mapped to hours when assigned to developer

30/10/2014 Chapter 3 Agile Software Development 48

Story point

30/10/2014 Chapter 3 Agile Software Development 49

Planning Poker

 For each user story

 The Product Owner explains the story along with its conditions

 Team member assigns Fibonacci number to the story using cards

 All the estimates are revealed at the same time

 If estimates are not equal then, the highest and lowest estimators

should mainly discuss and share their reasons

30/10/2014 Chapter 3 Agile Software Development 50

Done Definition

30/10/2014 Chapter 3 Agile Software Development 51

Release planning

30/10/2014 Chapter 3 Agile Software Development 52

Velocity

 Metric for measure of progress

𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑡𝑜𝑟𝑦 𝑝𝑜𝑖𝑛𝑡𝑠

𝑣 =
𝑠𝑝𝑟𝑖𝑛𝑡

𝑏𝑎𝑐𝑘𝑙𝑜𝑔 𝑠𝑖𝑧𝑒
 𝑝𝑟𝑜𝑗𝑒𝑐𝑡 𝑑𝑢𝑟𝑎𝑡𝑖𝑜𝑛 =
𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦

30/10/2014 Chapter 3 Agile Software Development 53

Velocity estimation

30/10/2014 Chapter 3 Agile Software Development 54

Velocity estimation (Historical data)

30/10/2014 Chapter 3 Agile Software Development 55

Velocity estimation (Historical data)

1 2

30/10/2014 Chapter 3 Agile Software Development 56

Velocity estimation (pilot sprint)

30/10/2014 Chapter 3 Agile Software Development 57

Velocity estimation (dry run)

30/10/2014 Chapter 3 Agile Software Development 58

Velocity (Estimated – Planned - Actual)

30/10/2014 Chapter 3 Agile Software Development 59

 Agile project tracking & control

30/10/2014 Chapter 3 Agile Software Development 60

Tracking Agile project

30/10/2014 Chapter 3 Agile Software Development 61

Release tracking: Burn-down chart

30/10/2014 Chapter 3 Agile Software Development 62

Release tracking: Burn-up chart

30/10/2014 Chapter 3 Agile Software Development 63

Iteration tracking: Burn-down chart

30/10/2014 Chapter 3 Agile Software Development 64

Iteration tracking: Burn-up chart

30/10/2014 Chapter 3 Agile Software Development 65

Would you take corrective action?

30/10/2014 Chapter 3 Agile Software Development 66

What about this one?

30/10/2014 Chapter 3 Agile Software Development 67

Conclusion

 Agile is NOT a silver bullet

 Agile is NOT a process, rather, methodologies and mind-set
 Agile implementations are NOT document-less
 Agile teams are NOT constantly under pressure
 An Agile environment is NOT chaotic and free of discipline

Chapter 3 Agile Software Development 68

Questions

1. What is the difference between agile values, principles and

techniques?

2. based on your understanding, summarize the agile manifesto

(values).

3. Agile philosophy is to welcome changes. Discuss!

4. Simplicity is essential. Discuss!

5. What is the difference between micro-managed and self-managed

team? which is best?

Chapter 3 Agile Software Development 69
Questions

6. Based on your understanding, discuss the following terms

Incremental planning

Test driven development

Customer involvement

Continous integration

Pair programming

7. Mention some benefits of pair programming.

Chapter 3 Agile Software Development 70

Questions

8. Mention the different level of requirements in Agile requirement

specification activity

9. What is user story? what are the main components of user story?

10. What is the difference between user story and epic?

11. What is the Definition of Done? who is responsible to put such

definition?

12. Mention some items that would be valid in the definition of done.

Chapter 3 Agile Software Development 71

Questions

13. a good user story is the one that is indepedent, valuable,

estimatable and negotiable. Discuss!

14. What is the difference between TDD and Code-first development?

15. What is Agile Scrum? what is it used for?

16. What is the role product owner and scrum master in Agile team?

17. Whtat is the difference between spring & release?

16. What is meant by: product backlog, velocity, potentially shippable

product?
Chapter 3 Agile Software Development 72
Questions

17. What is the measurement metric for user stories?

18. How do you estimate the velocity of the team for a new project?

mention the methods used of quantifying team velocity.

19. What is burn-down chart? what is it used for?

Chapter 3 Agile Software Development 73