The document discusses Agile development principles and practices. It provides 3 key points: 1. Agile development puts the product owner, representing the customer or business, in control of determining what features are developed. This allows customers to change priorities and react quickly to changing market needs. 2. Agile provides transparency into the development process for customers. It engages customers throughout development to provide better understanding and reduce feelings of helplessness. 3. Agile puts the development team in control of how features are developed. Teams are self-organizing to determine the best approaches.

1. WeBeAgile.com

2. 2

5. Agile/Lean
Development
Delivering early and
often, giving ourselves
the best opportunity to
beat the competition to
market, realize revenue
and discover insights
that we can use to help
us improve
5

6. The actualization and effectively dealing with -
More Success + Greater Speed + Fewer Resources +
Constant Uncertainty + Increased Competition +
Quicker Time to Market
1. Agile puts the Product Owner (aka “the business” or customer representative) in
the driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a
limited capacity. They get to define a scope up-front, but then any changes they deem necessary are
change ordered back to them. This practice assumes that the customer knows exactly what they want up
front and penalizes them for changing their minds later in the development process.
2. Agile allows the business to quickly react to changing market conditions and
needs – The only thing constant in today‟s economy is change. Businesses need to be able to make
quick course corrections in order to survive.
3. Agile provides visibility into the development process – For many customers software
development is a dark art. They don‟t have the background in order to understand the technical details
and in most cases the development team prefers it this way. The customer is left feeling helpless and
Agile engages them throughout the development lifecycle, providing enhanced visibility.
4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is
responsible for “what” is to be developed the Development Team is self-directing and self-organizing as to
“how” to develop the system-software product

7. 1. Selecting Stories from the
Product Backlog based on
the team’s velocity
2. Identifying the tasks to
realize a selected Story
3. Estimating the hours
required to complete the
task
4. ScrumMaster validates total
estimated work against
total team capacity during a
Sprint (# of people *
productive hours/day * # of
days for the Sprint)
Copyright © 2008 Russell Pannone. All rights reserved. 7

8. 1. Selecting identified
tasks to complete
2. Completing them per
the team's definition of
done
3. This cycle repeats until
all Story points for the
Sprint are earned
and/or Sprint is
complete
Copyright © 2008 Russell Pannone. All rights reserved. 8

9. Copyright © 2008 Russell Pannone. All rights reserved.
9

10. SS Agile SS Agile
10

11. Copyright © 2008 Russell Pannone. All rights reserved. 11

12. Our highest priority is to satisfy the customer through early and The most efficient and effective method of conveying information to and
continuous delivery of valuable software. within a development team is face-to-face conversation.
Welcome changing requirements, even late in development. Agile processes promote sustainable development. The sponsors,
Agile processes harness change for the customer's competitive developers, and users should be able to maintain a constant pace
advantage. indefinitely.
Deliver working software frequently, from a couple of weeks to a Continuous attention to technical excellence and good design enhances
couple of months, with a preference to the shorter timescale. agility.
Business people and developers must work together daily Simplicity--the art of maximizing the amount of work not done--is
throughout the project. essential.
Build projects around motivated individuals. Give them the The best architectures, requirements, and designs emerge from self-
environment and support they need, and trust them to get the job organizing teams.
done. At regular intervals, the team reflects on how to become more effective,
Working software is the primary measure of progress. then tunes and adjusts its behavior accordingly. 12

13. Delivering early and often,
giving ourselves the best
opportunity to beat the
competition to market,
realize revenue and
discover insights that we
can use to help us improve
Copyright © 2009 Russell Pannone. All rights reserved. 13

14. Conceptualize Realize Operationalize
• Select the • Plan • Deployment
Customer • Test • Servicing
• Understand the • Develop
Customer • Deliver
• Express Feature • Inspect
Set
• Adapt
Copyright © 2009 Russell Pannone. All rights reserved. 14

15. By delivering early and
often we give ourselves
the best opportunity to
beat the competition to
market, realize revenue
and discover insights
that we can use to help
us improve

16. Scrum Explained
“The… „relay race‟ approach to
product development…may conflict
with the goals of maximum speed
and flexibility. Instead a holistic or
‘rugby’ approach—where a team
tries to go the distance as a unit,
passing the ball back and forth—
may better serve today’s
competitive requirements.”- Hirotaka
Takeuchi and Ikujiro Nonaka, “The New New Product Development
Game”, Harvard Business Review, January 1986
In Scrum you work in iterations
delivering value-adding results
incrementally
Copyright © 2008 Russell Pannone. All rights reserved. 16

17. Scrum Roles & Definitions
(continued on next slide)
Copyright © 2005 Mountain Goat Software.
Copyright © 2008 Russell Pannone. All rights reserved. 17

18. Scrum Roles & Definitions
(continued on next slide)
Copyright © 2005 Mountain Goat Software.
Copyright © 2008 Russell Pannone. All rights reserved. 18

19. Scrum Roles & Definitions
(continued from previous slide)
Copyright © 2005 Mountain Goat Software.
Copyright © 2008 Russell Pannone. All rights reserved. 19

20. Problem / Feedback
Opportunity
Traditional Development
All  implied sequential “waterfall”
 time delay in obtaining feedback
Planning
All
Requirements
All
Design
All
Development
All
Validation
All
Implementation
Iterative & Incremental
Development and Delivery
US Airways Confidential – Do not distribute or duplicate

21. Copyright © 2008 Russell Pannone. All rights reserved. 21

22. Kanban Board
Pending WIP Done
Story Story
Story
Story Story
Story
Define Story
Story Story Story
Story
Story Story
Story
Story Story Story
Story Story
Story
Story Build & Story
Test Design
Implement
Story Story
Story Story
Story Story Story
Story
Story
Story
Story Story
Code
Story Story
Copyright © 2008 Russell Pannone. All rights reserved.

23. Candidate Practices
23

24. Usage scenario
– When a project team wants to “be” agile they
self-organize & self-direct around the 9 practices
– The team then selects 1 or more practice to
apply to their work at hand
Benefits
– Iterative & Incremental adoption of “being”
agile
– Gives team a context and narrow focus to rally
around
– Provides a non-threatening easy way for team
to learn together, “be” agile, apply an iterative
and incremental approach, and get better at
what we do
24

25. The actualization and effectively dealing with -
More Success + Greater Speed + Fewer Resources +
Constant Uncertainty + Increased Competition +
Quicker Time to Market
1. Agile puts the Product Owner (aka “the business” or customer representative) in
the driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a
limited capacity. They get to define a scope up-front, but then any changes they deem necessary are
change ordered back to them. This practice assumes that the customer knows exactly what they want up
front and penalizes them for changing their minds later in the development process.
2. Agile allows the business to quickly react to changing market conditions and
needs – The only thing constant in today‟s economy is change. Businesses need to be able to make
quick course corrections in order to survive.
3. Agile provides visibility into the development process – For many customers software
development is a dark art. They don‟t have the background in order to understand the technical details
and in most cases the development team prefers it this way. The customer is left feeling helpless and
Agile engages them throughout the development lifecycle, providing enhanced visibility.
4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is
responsible for “what” is to be developed the Development Team is self-directing and self-organizing as to
“how” to develop the system-software product

26. Copyright@ 2008 Russell Pannone. All rights reserved.

27. Copyright © 2008 Russell Pannone. All rights reserved.

28. User Stories Business Story Points
Priority
Story A 1 5
Story B 2 8
Story C 3 1
Story D 4 8
Story E 5 2
Story F 6 2
Story G 7 2
Story H 8 8
Story I 9 5
Story J 10 1
Copyright@ 2008 Russell Pannone. All rights reserved. 28

29. Copyright@ 2008 Russell Pannone. All rights reserved. 29

30. The Product Owner/Customer tells us they want an implement for writing,
drawing, or marking that is easy to keep sharp, is comfortable to hold, and when
they want to they can easily make a correction.
We collaborate more with the Product Owner/Customer on their needs or
requirements and define the implement’s features and corresponding
benefit/value, as depicted in the table below. Take notice that we have benefits
that influence the implement’s functionality and constrain its design and final
form.
Features Benefits/Value
Is made of wood Easy to sharpen and smells good
Has a specific diameter Comfortable
Surface to be coated Won’t get splinters
Contains a lead composite filler Creates an impressive line
Has an eraser at the end Makes correcting easy
Copyright © 2008 Russell Pannone. All rights reserved. 30

31. • As an implement user I want an implement that is made of
wood so it is easy to sharpen and smells good when
sharpening
• As an implement user I want an implement that has a specific
diameter so it is comfortable to hold
• As an implement user I want the surface of the implement to
be coated so I won’t get splinters when I use it
• As an implement user I want the implement to contain a lead
composite filler so I can create an impressive line
• As an implement user I want to have at the end of the
implement an eraser so I can easily make a correction
Copyright © 2008 Russell Pannone. All rights reserved.
31

32. A story is a “placeholder”
for a requirement formulated as a
brief description written in the
everyday language of the customer
or user describing desired
functionality; containing just
enough information so that the
product team can produce a
reasonable estimate of the effort to
implement it
Copyright@ 2008 Russell Pannone. All rights reserved. 32

33. Samples Stories
As a vacation planner, I
want to see photos of the
hotels to help me
determine if it meets my
needs
As a user, I want to cancel As a frequent flier, I want
a reservation to rebook a past trip, so
that I save time booking
trips I take often
33

34. Where Are the Details?
As a user, I can cancel a reservation
Does the user get a full or partial refund?
Is the refund to her credit card or is it site
credit?
How far ahead must the reservation be cancelled?
Is that the same for all hotels?
For all site visitors? Can frequent travelers
cancel later?
Is a confirmation provided to the user?
How?
34

35. Copyright@ 2008 Russell Pannone. All rights reserved. 35

36. Details as Conditions-of-Satisfaction
The product owner‟s conditions of satisfaction
can be added to a story
 These are essentially acceptance tests
As a user, I can cancel a
Verify that a premium member
reservation
can cancel the same day without a
fee.
Verify that a non-premium
member is charged 10% for a same-
day cancellation.
Continued next page Verify that an email confirmation
is sent.
Verify that the hotel is notified
of any cancellation.
36

37. Another Example of Details as Conditions-of-Satisfaction
Story - As an eligible user, I can pay the one-time registration fee of $10, so that I can access my driver’s
record in the future
Conditions-of Satisfaction:
• verify that a payment can be made
• verify that once a payment is made, the user can view their record (with any subsequent fees)
• verify that payment option is not available if registration has already been paid
Story - As an eligible user, I can create a unique user name and password so that my access is limited to
my record and to track activity and payment
Conditions-of Satisfaction:
• verify that a user account can be created
• verify that a user name that is already in use (assigned) is not accepted and the user notified then
prompted for a different user name
• verify that the user name conforms to naming convention (length, caps, etc.)
• verify that the password conforms to naming convention (length, caps, symbols, etc.)
• verify that the legal compliance conditions and consequences of use are displayed and accepted
• verify that if the user does not accept the legal compliance conditions and consequences than no
user name is created
Story - As an eligible user, I can access my record, so that I can verify that it is correct
Conditions-of Satisfaction:
• verify that the user‟s record is displayed
• verify that the user cannot access records other than his/her own (or dependents)
• verify that user is charged $10 for the first access and $5 for subsequent accesses.
• verify that the user is limited to three record access each year.
• verify that the system displays user profile information including: names, addresses, email
addresses, credit cards, and PayPal.
• verify that records for any nonresident individual with a driving record in the state can be accessed
37
(by March 1)

38. INVESTing in Good Stories
Independent
- Dependencies lead to problems estimating and prioritizing
- Can ideally select a story to work on without pulling in 18 other stories
Negotiable
- Stories are not contracts
- Leave or imply some flexibility
Valuable
- To users or customers, not developers
- Rewrite developer stories to reflect value to users or customers
Estimatable
- Because plans are based on user stories, we need to be able to estimate them
Sized appropriately
- Complex stories are intrinsically large
- Compound stories are multiple stories in one
Testable
- Stories need to be testable
Bill Wake, xp123.com
38

39. Sometimes You
Have to See the
Big Picture
Optional
to Know How the
Optional
Pieces
Fit Best
Together
Optional
Optional
Bus
Strategy
Use Cases
Business
Model
System Requirements
Functional
&
Non-Functional
Solution/IT-Services
Copyright © 2008 Russell Pannone. All rights reserved. 39

40. Five factors to consider when prioritizing
1.The commercial or operational value of having the story
2.Degree of uncertainty - the amount and significance of learning and new
knowledge gained by developing the story; focused on requirements
and technology
3.The amount of risk removed by developing and delivering the story –
focused on schedule, budget, scope, operation, technology
4.Dependencies – stories that must be developed together and are
delivered together to provide value to the customer
5.The cost of developing and delivering the story
Copyright © 2008 Russell Pannone. All rights reserved. 40

41. User Stories Business Story Points
Priority
Story A 1 5
Story B 2 8
Story C 3 1
Story D 4 8
Story E 5 2
Story F 6 2
Story G 7 2
Story H 8 8
Story I 9 5
Story J 10 1
Copyright@ 2008 Russell Pannone. All rights reserved. 41

42. Story Points: Relative Measure of the
Size of a Story
42

43. 1. Selecting Stories from the
Product Backlog based on
the team’s velocity
2. Identifying the tasks to
realize a selected Story
3. Estimating the hours
required to complete the
task
4. ScrumMaster validates total
estimated work against
total team capacity during a
Sprint (# of people *
productive hours/day * # of
days for the Sprint)
Copyright © 2008 Russell Pannone. All rights reserved. 43

44. 1. Selecting identified
tasks to complete
2. Completing them per
the team's definition of
done
3. This cycle repeats until
all Story points for the
Sprint are earned
and/or Sprint is
complete
Copyright © 2008 Russell Pannone. All rights reserved. 44

46. Roadmap to “being” agile
 Collaboratively and adaptively develop value-
adding product increments in a continuous flow
from requirements to deployment
Agile
 Be objective and see things as a whole Coaching &
Training
 Be value-driven not plan/task-driven
 Identify and continually discuss individual, team
and enterprise strengths, weaknesses,
opportunities and challenges Agile Scrum
Cultural Transition Coaching &
 Put together a coalition to lead by example and Renewal Training
Program
teach
 Create a vision to help direct change
 Use every vehicle possible to constantly
communicate the vision and strategies Organizational
Change
Management
 Get rid of barriers to being agile
 Generate short-term wins
 Develop people who can implement the change
 Anchor being agile in the culture
46