What is Agile Software Development? The Agile Manifesto The Twelve Principles of Agile Software Agile Methodologies Scrum Extreme Programming (XP) Lean Software Development Kanban Software Development User Story Definition of Done Relative Sizing & Story Points Planning Poker Estimation Technique Velocity

1. INTRODUCTION TO AGILE
SOFTWARE DEVELOPMENT
Ahmed Aboul-Kheir

2. WHAT IS AGILE SOFTWARE DEVELOPMENT?
In the late 1990’s several methodologies began to get increasing public
attention.
Each had a different combination of old ideas, new ideas, and transmuted
old ideas but they all emphasized:
• close collaboration between the programmer team and business
experts
• face-to-face communication (as more efficient than written
documentation)
• frequent delivery of new deployable business value
• tight, self-organizing teams
• ways to craft the code and the team such that the inevitable
requirements churn was not a crisis.

3. THE AGILE MANIFESTO
The Agile Manifesto was written in February of 2001, at a summit of
seventeen independent-minded practitioners of several programming
methodologies.
The participants didn't agree about much, but they found consensus
around four main values.
Supplementing the Manifesto, the Twelve Principles further explicate what
it is to be Agile.

5. THE TWELVE PRINCIPLES OF AGILE SOFTWARE
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.

6. THE TWELVE PRINCIPLES OF AGILE SOFTWARE (CONT’D)
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is
essential.
11. The best architectures, requirements, and designs emerge from self-
organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

7. WHAT IS AGILE?
Agile is a mindset
[that in the software world is]
• Established through 4 values
• Grounded by 12 principles
• Manifested through many many different practices

8.  Doing Agile
Learning the practices and applying them
without know the mindset and principles
to know when to tailor and how to select
the appropriate practices
 Being Agile
Internalizing the Mindset, values, and
principles then applying the right
practices and tailoring them to different
situations as they arise

9. WHAT IS SHU – HA – RI?
ShuHaRiDojo is a Japanese Martial Arts form. Shu Ha Ri are three kanji
which describe the cycle of training, or perhaps more properly the cycle of
progress of a student.
SHU: Follow the rule
HA: Break the rule
RI: Be the rule

10. AGILE METHODOLOGIES
The various agile methodologies share much of the same philosophy,
characteristics and practices.
But from an implementation standpoint, each has its own recipe of
practices, terminology, and tactics.
• Scrum
• Extreme Programming (XP)
• Lean Software Development
• Kanban Software Development
• Crystal
• Dynamic Systems Development Method (DSDM)
• Feature-Driven Development (FDD)

11. SCRUM
Scrum is a lightweight agile project management
framework.
Formally introduced as a software development
framework by Jeff Sutherland and Ken Schwaber in 1995.
Scrum has garnered increasing popularity in the agile
software development community due to its:
• Simplicity
• Proven productivity
• Ability to act as a wrapper for various engineering
practices promoted by other agile methodologies

13. EXTREME PROGRAMMING (XP)
A revolutionary software development method, started to appear in 1996
by Kent Beck.
XP is a disciplined approach to delivering high-quality software quickly
and continuously.
The “Customer” works very closely with the development team to define
and prioritize granular units of functionality referred to as “User Stories”.
The development team estimates, plans, and delivers the highest priority
user stories in the form of working, tested software on an iteration-by-
iteration basis.
Introduced some revolutionary practices and ideas.

14. XP PRACTICES

15. LEAN SOFTWARE DEVELOPMENT
Lean Software Development is an iterative agile methodology originally
developed by Mary and Tom Poppendieck.
Lean Software Development owes much of its principles and practices to the
Lean Enterprise movement, and the practices of companies like Toyota.
The main principles of Lean methodology include:
• Eliminating Waste
• Amplifying Learning
• Deciding as Late as Possible
• Delivering as Fast as Possible
• Empowering the Team
• Building Integrity In
• Seeing the Whole

16. KANBAN SOFTWARE DEVELOPMENT
Kanban is Japanese for “visual signal” or “card.”
Toyota line-workers used a kanban (i.e., an actual card) to signal steps in their
manufacturing process.
Kanban does the same for software teams by matching the amount of work in
progress to the team's capacity.
Kanban gives teams more flexible planning options, faster output, clear focus,
and transparency throughout the development cycle.
Kanban core properties:
• Visualize the workflow
• Limit WIP
• Manage flow
• Make Process Policies Explicit
• Improve Collaboratively

17. DEFINITIONS
Release
• Deployable software package that is the culmination of several
iterations
Iteration
• Timeboxed development cycle within a release that outputs a
potentially shippable product increment
Timebox
• Previously agreed period of time during which a person or a team
works steadily towards completion of some goal

18. USER STORY
• Captures a description of a software feature from an end-user
perspective
• Describes the type of user, what they want and why
• Helps to create a simplified description of a requirement

19. DEFINITION OF DONE
• Shared understanding of expectations that software must
live up to in order to be releasable into production
• Managed by the Development Team

20. RELATIVE SIZING & STORY POINTS
• Studies show that we are better in estimating relatively than estimating
absolute values
• Relative estimation doesn’t require all the details and still provides
reasonable accuracy
• Relative estimation is fast (easier to reach consensus)
• Story points are units of relative size
• Fibonacci sequence recommended to represent points
• Combination of a story’s [Complexity/Difficulty – Relative Time –
Uncertainty]
• Enables the relative comparison of user stories without knowing precisely
how long each of them will take
• Story points estimates don’t expire
• The team doesn’t have to worry who will eventually implement the story

21. PLANNING POKER ESTIMATION TECHNIQUE
• The Product Owner explains the story along with its conditions
• Each team member assigns an estimate value to the story using one of
the 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
• Additional estimation rounds are conducted each story until consensus
is reached

22. VELOCITY
• Number of size units covered by the team during an iteration
• Metric
• Measure of progress
• Variable
• Size / Velocity = Duration (number of Iterations)

23.  Burn-down Chart
Showing the evolution of remaining effort
against time.
 Burn-up Chart
Showing the evolution of completed
effort against time.

24. SCRUM TEAM
Development Team
• Responsible for delivering a potentially releasable Increment of “Done”
product at the end of each Sprint
• Self-organizing
• Cross Functional
Product Owner
• Responsible for maximizing the value of a product
• Owns Product Backlog
Scrum Master
• Responsible for ensuring Scrum is understood and enacted
• Servant-leader for the Scrum Team
• Remove impediments to the Development Team’s progress
• Facilitating Scrum events as requested or needed

25. SCRUM EVENTS
• Prescribed events are used in Scrum to create regularity and to
minimize the need for meetings not defined in Scrum
• All events are time-boxed events, such that every event has a
maximum duration

26. SPRINT
• Timebox of one month or less during which a “Done”, useable, and
potentially releasable product Increment is created
• During the Sprint no changes are made that would endanger the Sprint
Goal

27. SPRINT PLANNING
• Timeboxed to a maximum of eight hours for a one-month Sprint
during which The work to be performed in the Sprint is planned
• This plan is created by the collaborative work of the entire Scrum Team
• What can be delivered in the Increment resulting from the upcoming
Sprint?
• How will the work needed to deliver the Increment be achieved?

28. DAILY SCRUM
15-minute time-boxed event for the Development Team to synchronize
activities and create a plan for the next 24 hours
Inspecting the work since the last Daily Scrum
Forecasting the work that could be done before the next one
Held at the same time and place each day to reduce complexity
• What did I do yesterday that helped the Development Team meet the
Sprint Goal?
• What will I do today to help the Development Team meet the Sprint
Goal?
• Do I see any impediment that prevents me or the Development Team
from meeting the Sprint Goal?

29. SPRINT REVIEW
• Held at the end of the Sprint to inspect the Increment and adapt the
Product Backlog if needed
• The Scrum Team and stakeholders collaborate about what was done in
the Sprint
• Collaborate on the next things that could be done to optimize value
• Presentation of the Increment is intended to elicit feedback and foster
collaboration
• Four-hour time-boxed meeting for one-month Sprints

30. SPRINT RETROSPECTIVE
• Occurs after the Sprint Review and prior to the next Sprint Planning
• Three-hour time-boxed meeting for one-month Sprints
• Inspect how the last Sprint went with regards to people, relationships,
process, and tools
• Identify and order the major items that went well and potential
improvements
• Create a plan for implementing improvements to the way the Scrum
Team does its work

31. SCRUM ARTIFACTS
Product Backlog
• An ordered list of the work to be done in order to create, maintain and
sustain a product
• Managed by the Product Owner
Sprint Backlog
• Set of Product Backlog items selected for the Sprint
• A plan for delivering the product Increment and realizing the Sprint Goal
• A forecast by the Development Team about what functionality will be in
the next Increment
Increment
• A piece of working software that adds to previously created Increments,
where the sum of all Increments -as a whole - form a product