If you like the ideas raised in this presentation, don't forget to check out my latest book, Directing the Agile Organisation (http://theagiledirector.com/book).

1. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
INTRO TO SCRUM
PART 1: HISTORY &
CORE CONCEPTS

2. Evan Leybourn
Lean / Agile Business Leader and Author
Melbourne, Australia
@eleybourn
http://theagiledirector.com

3. WHAT DOES BEING
“AGILE”
ACTUALLY MEAN?
THE AGILE MANIFESTO

4. Waterfall
Agile

5. Waterfall (Incrementing)
Agile (Iterating)
Images with thanks from Jeff Patton: http://www.agileproductdesign.com/

6. INDIVIDUALS AND
INTERACTIONS
OVER PROCESSES AND TOOLS

7. WORKING
SOFTWARE
OVER COMPREHENSIVE DOCUMENTATION

8. CUSTOMER
COLLABORATION
OVER CONTRACT NEGOTIATION

9. RESPONDING TO
CHANGE
OVER FOLLOWING A PLAN

10. 1. Our highest priority is to satisfy
the customer through early
and continuous delivery of
valuable software.

11. 2. Welcome changing
requirements, even late in
development. Agile processes
harness change for the
customer's competitive
advantage.

12. 3. Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the shorter
timescale.

13. 4. Business people and
developers must work together
daily throughout the project.

14. 5. Build projects around
motivated individuals. Give
them the environment and
support they need, and trust
them to get the job done.

15. 6. The most efficient and effective
method of conveying
information to and within a
development team is face-to-face
conversation.

16. 7. Working software is the
primary measure of progress.

17. 8. Agile processes promote
sustainable development. The
sponsors, developers, and
users should be able to
maintain a constant pace
indefinitely.

18. 9. Continuous attention to
technical excellence and good
design enhances agility.

19. 10.Simplicity--the art of
maximizing the amount of work
not done--is essential.

20. 11.The best architectures,
requirements, and designs
emerge from self-organizing
teams.

21. 12.At regular intervals, the team
reflects on how to become
more effective, then tunes and
adjusts its behaviour
accordingly.

22. INSPECT ADAPT INSPECT
HOW DOES
“AGILE”
WORK

23. WORKFLOW AND PROJECT MANAGEMENT
AUP, CRYSTAL
CLEAR, DSDM,
KANBAN, RUP,
SCRUM

24. SCRUM
* Iterative Product Development
* 1-4 week Sprints
* Formal Roles (Product Owner &
Scrum Master)
* Timeboxed Meetings

25. DEVELOPMENT METHODS
BDD, FDD, RAD,
LEAN SOFTWARE,
XP

26. Extreme Programming
Activities
Writing the Software
Testing the Software
Listening to the Customer
Designing & Refactoring
Development
Pair Programming
Common Code Standards
Clear System Metaphor

27. QUALITY METHODS
TEST DRIVEN
DEVELOPMENT

28. Test-Driven Development
1. Create a test
2. Add the test to the test catalogue
3. Write the code
4. Run the tests (all of them)
5. Clean up the code as required.
(Refactor)

29. 1. AGILE MEANS NO
DOCUMENTATION
COMMON AGILE MISTAKES

30. 2. NOT MEASURING,
MONITORING OR
CORRECTING
COMMON AGILE MISTAKES

31. COMMON AGILE MISTAKES
3. ASSUMING YOU
CAN DO MORE
WITH LESS

32. COMMON AGILE MISTAKES
4. SKIMPING ON
TRAINING AND
EDUCATION

33. COMMON AGILE MISTAKES
5. LACKING AN
EXECUTIVE
SPONSOR

34. COMMON AGILE MISTAKES
6. THINKING AGILE IS
FASTER OR
EASY

35. 7. START WITH A
TOOL
COMMON AGILE MISTAKES

36. 8. FAILING TO SCALE
COMMON AGILE MISTAKES

37. 9. ASSUMING
AGILE = SCRUM
COMMON AGILE MISTAKES

38. TO LEARN MORE, CHECK OUT
DIRECTING THE AGILE
ORGANISATION
BY EVAN LEYBOURN
AVAILABLE AT AMAZON AND ALL
GOOD BOOK STORES
CLICK HERE TO DISCOVER MORE

39. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
INTRO TO SCRUM
PART 2: ROLES &
RESPONSIBILITIES

40. Evan Leybourn
Lean / Agile Business Leader and Author
Melbourne, Australia
@eleybourn
http://theagiledirector.com
CLICK TO DISCOVER MORE

42. USERS WILL
USE THE SOFTWARE,
IDENTIFY ISSUES &
PROVIDE FEEDBACK

43. USERS CAN BE
THERE ARE NO
TYPICAL USERS

44. USERS DO NOT
SET SCOPE OR
TEST WORK

45. CUSTOMERS WILL
DEFINE, START&
END THE PROJECT

46. CUSTOMERS CAN BE
INTERNAL
MANAGERS OR
EXTERNAL CLIENTS

47. CUSTOMERS DO NOT
DIRECT WORK

48. THE PRODUCT OWNER WILL
MANAGE THE
PRODUCT BACKLOG,
SET THE SCOPE &
APPROVE RELEASES

49. THE PRODUCT OWNER CAN BE
PROJECT MANAGER,
PRODUCT MANAGER
OR CUSTOMER

50. THE PRODUCT OWNER DOES NOT
MANAGE THE TEAM

51. THE SCRUM MASTER WILL
MANAGE THE AGILE
PROCESS & REPORT
ON PROGRESS

52. THE SCRUM MASTER CAN BE
PROJECT MANAGER,
TEAM LEADER OR
TEAM MEMBER

53. THE SCRUM MASTER DOES NOT
PRIORITISE
FEATURES

54. DEVELOPERS WILL
DEVELOP
FEATURES, AND
RESOLVE ISSUES

55. DEVELOPERS CAN BE
DEVELOPERS,
DESIGNERS, WRITERS,
OR ADMINISTRATORS
CROSS FUNCTIONAL

56. DEVELOPERS DO NOT
PRIORITISE
FEATURES

57. TESTERS WILL
TEST, APPROVE OR
REJECT FEATURES
FOR RELEASE

58. TESTERS CAN BE
EXISTING
DEVELOPERS OR
DEDICATED TESTERS

59. TESTERS DO NOT
TEST THEIR OWN
CODE

60. 7 +/- 2
TYPICAL TEAM SIZE

61. HAS AN INTEREST IN
THE WORK & IS
KEPT UP TO DATE
INVOLVED PARTIES (CHICKENS)

62. COMMITTED PARTIES (PIGS)
"DO" THE WORK &
ARE RESPONSIBLE
FOR THE RELEASE

64. TO LEARN MORE, CHECK OUT
DIRECTING THE AGILE
ORGANISATION
BY EVAN LEYBOURN
AVAILABLE AT AMAZON AND ALL
GOOD BOOK STORES
CLICK HERE TO DISCOVER MORE

65. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
INTRO TO SCRUM
PART 3: SPRINT 0

66. Evan Leybourn
Lean / Agile Business Leader and Author
Melbourne, Australia
@eleybourn
http://theagiledirector.com
CLICK TO DISCOVER MORE

67. ALSO KNOWN AS
FEASIBILITY,
PROJECT INITIATION
OR ITERATION 0 (XP)

68. REDUCE RISK &
UNCERTAINTY
BY DEFINING THE HIGH LEVEL SCOPE

69. ALIGN TO STRATEGIC
GOALS, & TECHNICAL
FRAMEWORKS
SKILLS GAP ANALYSIS & RECRUITMENT

70. BEGINNING THE PROCESS
AGILE PROJECTS
HAVE MINIMAL
INITIATION

71. THE DEVELOPMENT TEAM SHOULD BE
ENGAGED DURING
INITIATION

72. CUSTOMER IS FULLY
AWARE OF THEIR
RESPONSIBILITIES
CUSTOMERS SHARE ACCOUNTABILITY FOR DELIVERY

73. REMOVE ANY POTENTIAL IMPEDIMENTS
ADD TRAINING
TASKS TO THE
BACKLOG

74. “Friends don’t let friends use
Microsoft Project”

75. CREATE THE INITIAL
PRODUCT BACKLOG
(IN LOW DETAIL)
ALLOW CUSTOMERS TO SLOWLY DEFINE THEIR NEEDS

77. ESTIMATE THE
PRODUCT BACKLOG
FIRST ORDER ESTIMATE -USING STORY POINTS

79. 1, 2, 3, 5, 8, 13, 20, 40, 100
FIBONACCI SEQUENCE

80. EXPERT OPINION
THE TEAM MEMBER
WITH SPECIFIC
DOMAIN KNOWLEDGE
E.G. A DBA ESTIMATING DATABASE TASKS.

81. COMPARISON
COMPARING A TASK
TO ANOTHER,
ESTIMATED, TASK.
E.G. TASK A IS ABOUT TWICE THE EFFORT OF TASK B

82. COMPONENTS
BREAK A LARGE
TASK INTO SMALL
SUB-TASKS
E.G. BREAK USER MANAGEMENT INTO
INTERFACE, LOGIN, ACCESS CONTROL, ETC.

83. PLANNING POKER
EACH TEAM MEMBER
PLAYS A CARD
REPRESENTING THEIR
ESTIMATE
EVERYONE PARTICIPATES TO REACH CONSENSUS

84. Estimates must not be mentioned
during planning discussion to
avoid anchoring

85. STAFF OVERHEAD: NON PROJECT TIME
ESTIMATED LEAVE,
ILLNESS, BREAKS,
MEETINGS ETC.
GENERIC INDUSTRY MODIFIER: 25%

86. DURATION CALCULATION
STORY COST X
(OVERHEAD + 1) X
(ESTIMATE RISK + 1)
ESTIMATE RISK IS OPTIONAL

87. FOR EXAMPLE
4 X (25% + 1) X (50%+ 1)
= 4 X 1.25 X 1.5
= 5 TO 7.5 HOURS

88. SPRINTS SHOULD
BE BETWEEN 1 & 4
WEEKS
SHORTER SPRINTS PROVIDE MORE
OPPORTUNITIES TO INSPECT & ADAPT

89. - “How much is this going to cost?”
- “As much as you’re willing to
spend.”

90. - “How long is this going to take?”
- “As long as is necessary.”

91. - “What am I going to get?”
- “Whatever you tell us you want.”

92. WORK IN PRIORITY
ORDER, RELEASE
QUICKLY & MONITOR
BURN RATE
FIXED COST

93. WORK IN PRIORITY
ORDER & ENFORCE
SPRINT LENGTH
FIXED TIME

94. FIXED SCOPE
FOCUS ON BACKLOG
DEFINITION AND
ESTIMATION

95. FIXED COST AND TIME
CALCULATE TOTAL
COST AS COST PER
SPRINT

96. FIXED COST AND SCOPE
INCREASE THE
ESTIMATE RISK
DURING SPRINT 0

97. FIXED TIME AND SCOPE
PRE-ASSIGN WORK
TO SPRINTS & PAD
SCHEDULE WITH
EXTRA SPRINTS

98. FIXED COST, TIME AND SCOPE
CANCEL THE
PROJECT

99. TO LEARN MORE, CHECK OUT
DIRECTING THE AGILE
ORGANISATION
BY EVAN LEYBOURN
AVAILABLE AT AMAZON AND ALL
GOOD BOOK STORES
CLICK HERE TO DISCOVER MORE

100. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
INTRO TO SCRUM
PART 4: SPRINTS

101. Evan Leybourn
Lean / Agile Business Leader and Author
Melbourne, Australia
@eleybourn
http://theagiledirector.com
CLICK TO DISCOVER MORE

102. CONVERT THE
BACKLOG INTO A
REALISTIC GOAL
SPRINT PLANNING

103. THIS IS A CREATIVE
PROCESS: PREPARE
BEFOREHAND
SUPPLY PAPER, A WHITEBOARD AND INTERNET ACCESS.

104. PRIORITISE THE
PRODUCT BACKLOG
BEFORE THE PLANNING WORKSHOP

105. DEFINE THE
BUSINESS GOAL
FOR THE SPRINT
PART 1: BUSINESS PLANNING

106. ENCOURAGE A STABLE & CONSISTENT WORKFLOW
SPRINT SCOPE IS
LIMITED BY TEAM
VELOCITY

107. PART 2: TECHNICAL PLANNING
DECOMPOSE USER
STORIES INTO
TASKS (< 1 DAY)

108. CREATE THE SPRINT
BACKLOG (IN HIGH
DETAIL)
OWNED & MAINTAINED BY THE DEVELOPERS

109. PLAN, DESIGN &
ESTIMATE TASKS
TECHNICAL SPECIFICATIONS

111. GET HIGHEST
PRIORITY FEATURE
ALLOW DEVELOPERS TO CHOOSE THEIR TASKS

112. TEST –DRIVEN DEVELOPMENT

113. TEST COVERAGE
FUNCTIONS,
BOUNDARY CASES,
USER INTERFACE &
PERFORMANCE

114. TEST TYPES
DEFECT, USABILITY,
FUNCTIONALITY &
DATA

115. PAIR PROGRAMMING:
CODER + REVIEWER
BUILD

116. CODE STANDARDS:
A COMMON CODING
STYLE
BUILD

117. SYSTEM METAPHOR:
CLEAR NAMING
STANDARDS
BUILD

118. REGULAR COMMITS
VERSION CONTROL

119. AUTOMATED: UNIT
TESTING, COVERAGE,
DOCUMENTATION,
STANDARDS & BUILD
CONTINUOUS INTEGRATION

120. WHAT DID YOU DO
YESTERDAY?
DAILY SCRUM

121. WHAT WILL YOU DO
TODAY?
DAILY SCRUM

122. ARE THERE ANY
ISSUES?
DAILY SCRUM

123. SCRUM OF SCRUMS
FOR LARGE TEAMS

124. CUSTOMERS CAN
ALWAYS SEE
PROGRESS
PROMOTING TRANSPARENCY THROUGH THE
SCRUMS AND BACKLOG

125. VIEW PROGRESS AGAINST THE RELEASE
IMPROVE FUTURE
ESTIMATES

126. PROGRESS MONITORING
BURNUP CHARTS
BURNDOWN CHARTS
CUMULATIVE FLOW
STATISTICAL RUN

127. EFFORT VISUALISATION
PLOT DELIVERED
FUNCTIONALITY
AGAINST VELOCITY

128. BURNUP CHART

129. BURNDOWN CHART

130. VELOCITY
HOW MUCH WORK
CAN BE DELIVERED
PER SPRINT

131. DON'T MANAGE BY NUMBERS
IDENTIFY PROBLEM
TRENDS EARLY

132. DISCOVERY

133. SCOPE CREEP

134. PLATEAU

135. TOO MANY FEATURES

136. TRACKING EPICS

137. DIFFERS BY ORGANISATION
WHAT DOES
“DONE”
MEAN?

138. DEFINITION OF “DONE”
DOCUMENTATION?
UAT?
BUILT / COMPILED?

139. WHAT DOES
“NOT DONE”
MEAN?
REMEMBER THE PRIMARY MEASURE OF PROGRESS

140. PER SPRINT OR
ACROSS SPRINTS
DEPLOY

141. PRESENT & REVIEW
COMPLETED WORK
TO THE CUSTOMER
SPRINT REVIEW

142. RETROSPECTIVE &
KAIZEN (改善)
CONTINUOUS IMPROVEMENT

143. WHAT WENT WELL?
SPRINT RETROSPECTIVE

144. ADD ACTIONABLE TASKS TO THE PRODUCT
BACKLOG
WHAT COULD BE
IMPROVED?

145. KAIZEN EMPHASISES
TEAMWORK,
DISCIPLINE &
MORALE

146. TO LEARN MORE, CHECK OUT
DIRECTING THE AGILE
ORGANISATION
BY EVAN LEYBOURN
AVAILABLE AT AMAZON AND ALL
GOOD BOOK STORES
CLICK HERE TO DISCOVER MORE