This document provides an overview of agile project iterations in 3 parts. It discusses iteration planning, including prioritizing the backlog, estimating tasks, and creating an iteration backlog. It describes daily activities like scrums, testing, and continuous integration during the build phase. Metrics like burnup/down charts and cycle time are covered for monitoring progress. Retrospectives and continuous improvement are emphasized for inspecting and adapting between iterations.

1. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
AGILE METHODS
PART 1: HISTORY &
CORE CONCEPTS

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

3. SHU-HA-RI
THE STAGES OF LEARNING

4. 守: SHU(BEGINNER)
FOLLOW PRECISELYWITHOUTMODIFICATION

5. 破:HA (PROFICIENT)
SHIFTING BETWEEN TECHNIQUES

6. 離: RI (MASTERY)
UNCONSCIOUS CREATION OF NEW TECHNIQUES

7. WHAT DOES BEING
“AGILE”
ACTUALLY MEAN?
THEAGILE MANIFESTO

8. Waterfall
Agile

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

10. INDIVIDUALS AND
INTERACTIONS
OVER PROCESSESAND TOOLS

11. WORKING
SOFTWARE
OVER COMPREHENSIVE DOCUMENTATION

12. CUSTOMER
COLLABORATION
OVER CONTRACT NEGOTIATION

13. RESPONDING TO
CHANGE
OVER FOLLOWINGAPLAN

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

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

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

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

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

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

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

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

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

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

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

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

26. Business change via sustained
effort across the organisation
Change
Change
Change
Images shamelessly stolen from Ahmed Sidky (ICAgile)

27. INSPECT ADAPT INSPECT
HOW DOES
“AGILE”
WORK

28. WORKFLOWAND PROJECT MANAGEMENT
AUP, CRYSTAL CLEAR,
DSDM, KANBAN, RUP,
SCRUM

29. KANBAN
1. Visualise (Card Wall)
2. Limit WIP
3. Manage Flow
4. Make Policies Explicit
5. Feedback Loops
6. Improve Collaboratively

30. LIMIT WIP
REDUCE LEAD
TIME, IDENTIFY
BLOCKS & CLEAR
BOTTLENECKS

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

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

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

34. QUALITY METHODS
TEST DRIVEN
DEVELOPMENT

35. Test-DrivenDevelopment
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)

36. MURA: UNEVENNESS
MURI: OVERBURDEN
MUDA: WASTE
UNDERSTANDINGWASTE

37. TRANSPORTATION
THE 7 WASTES

38. INVENTORY
THE 7 WASTES

39. MOTION
THE 7 WASTES

40. WAITING
THE 7 WASTES

41. OVER PRODUCTION
THE 7 WASTES

42. OVER PROCESSING
THE 7 WASTES

43. DEFECTS
THE 7 WASTES

44. 1. AGILE MEANS NO
DOCUMENTATION
COMMONAGILE MISTAKES

45. 2. NOT MEASURING,
MONITORING OR
CORRECTING
COMMONAGILE MISTAKES

46. COMMONAGILE MISTAKES
3. ASSUMING YOU
CAN DO MORE
WITH LESS

47. COMMONAGILE MISTAKES
4. SKIMPING ON
TRAINING AND
EDUCATION

48. COMMONAGILE MISTAKES
5. LACKING AN
EXECUTIVE
SPONSOR

49. COMMONAGILE MISTAKES
6. THINKING AGILE
IS FASTER OR
EASY

50. 7. START WITH A
TOOL
COMMONAGILE MISTAKES

51. 8. FAILING TO
SCALE
COMMONAGILE MISTAKES

52. 9. ASSUMING
AGILE = SCRUM
COMMONAGILE MISTAKES

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

54. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
AGILE METHODS
PART 2: ROLES &
RESPONSIBILITIES

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

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

58. USERS CAN BE
THERE ARE NO
TYPICAL USERS

59. USERS DO NOT
SET SCOPE OR
TEST WORK

60. CUSTOMERSWILL
DEFINE, START&
END THE PROJECT

61. CUSTOMERSCAN BE
INTERNAL
MANAGERS OR
EXTERNAL CLIENTS

62. CUSTOMERS DO NOT
DIRECT WORK

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

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

65. THE PRODUCTOWNER DOES NOT
MANAGE THE TEAM

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

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

68. THE SCRUM MASTER DOES NOT
PRIORITISE
FEATURES

69. DEVELOPERS WILL
DEVELOP
FEATURES, AND
RESOLVE ISSUES

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

71. DEVELOPERS DO NOT
PRIORITISE
FEATURES

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

73. TESTERS CAN BE
EXISTING
DEVELOPERS OR
DEDICATED TESTERS

74. TESTERS DO NOT
TEST THEIR OWN
CODE

75. 7 +/- 2
TYPICALTEAM SIZE

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

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

79. VALUE STREAM MAPPING
DEFINES THE „AS-IS‟
STEPS & ROLES
FOR EACH TASK

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

83. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
AGILE METHODS
PART 3: PROJECT
INITIATION

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

85. ALSO KNOWNAS
FEASIBILITY,
SPRINT 0 (SCRUM)
OR ITERATION 0 (XP)

86. REDUCE RISK &
UNCERTAINTY
BY DEFININGTHE HIGH LEVELSCOPE

87. ALIGN TO STRATEGIC
GOALS, & TECHNICAL
FRAMEWORKS
SKILLS GAPANALYSIS & RECRUITMENT

88. BEGINNINGTHE PROCESS
AGILE PROJECTS
HAVE MINIMAL
INITIATION

89. THE DEVELOPMENTTEAM SHOULD BE
ENGAGED DURING
INITIATION

90. CUSTOMER IS FULLY
AWARE OF THEIR
RESPONSIBILITIES
CUSTOMERSSHAREACCOUNTABILITYFOR DELIVERY

91. REMOVEANY POTENTIALIMPEDIMENTS
ADD TRAINING
TASKS TO THE
BACKLOG

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

93. CREATE THE INITIAL
PRODUCT BACKLOG
(IN LOW DETAIL)
ALLOW CUSTOMERSTO SLOWLYDEFINETHEIR NEEDS

95. ESTIMATE THE
PRODUCT BACKLOG
FIRSTORDER ESTIMATE- USING STORYPOINTS

97. 1, 2, 3, 5, 8, 13, 20, 40, 100
FIBONACCISEQUENCE

98. EXPERT OPINION
THE TEAM MEMBER
WITH SPECIFIC
DOMAIN KNOWLEDGE
E.G.ADBAESTIMATING DATABASETASKS.

99. COMPARISON
COMPARING A TASK
TO ANOTHER,
ESTIMATED, TASK.
E.G.TASKAISABOUTTWICETHE EFFORTOF TASKB

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

101. PLANNING POKER
EACH TEAM MEMBER
PLAYS A CARD
REPRESENTING THEIR
ESTIMATE
EVERYONE PARTICIPATESTO REACH CONSENSUS

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

103. STAFF OVERHEAD: NON PROJECTTIME
ESTIMATED LEAVE,
ILLNESS, BREAKS,
MEETINGS ETC.
GENERIC INDUSTRYMODIFIER:25%

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

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

106. ITERATIONS SHOULD
BE BETWEEN 1 & 4
WEEKS
SHORTER ITERATIONS PROVIDE MORE OPPORTUNITIES
TO INSPECT &ADAPT

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

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

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

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

111. WORK IN PRIORITY
ORDER & ENFORCE
ITERATION LENGTH
FIXEDTIME

112. FIXED SCOPE
FOCUS ON BACKLOG
DEFINITION AND
ESTIMATION

113. FIXED COSTAND TIME
CALCULATE TOTAL
COST AS COST PER
ITERATION

114. FIXED COSTAND SCOPE
INCREASE THE
ESTIMATE RISK
DURING ITERATION 0

115. FIXEDTIMEAND SCOPE
PRE-ASSIGN WORK TO
ITERATIONS & PAD
SCHEDULE WITH
EXTRA ITERATIONS

116. FIXED COST,TIMEAND SCOPE
CANCEL THE
PROJECT

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

118. EVAN LEYBOURN
EVAN@THEAGILEDIRECTOR.COM
AGILE METHODS
PART 4: ITERATIONS

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

120. CONVERT THE
BACKLOG INTO A
REALISTIC GOAL
ITERATION PLANNING

121. THIS IS A CREATIVE
PROCESS: PREPARE
BEFOREHAND
SUPPLYPAPER,AWHITEBOARDAND INTERNETACCESS.

122. PRIORITISE THE
PRODUCT BACKLOG
BEFORETHE PLANNING WORKSHOP

123. DEFINE THE
BUSINESS GOAL
FOR THE ITERATION
PART 1: BUSINESS PLANNING

124. ENCOURAGEASTABLE & CONSISTENTWORKFLOW
ITERATION SCOPE IS
LIMITED BY TEAM
VELOCITY

125. PART 2:TECHNICALPLANNING
DECOMPOSE USER
STORIES INTO
TASKS (< 1 DAY)

126. CREATE THE
ITERATION BACKLOG
(IN HIGH DETAIL)
OWNED & MAINTAINED BYTHE DEVELOPERS

127. PLAN, DESIGN &
ESTIMATE TASKS
TECHNICALSPECIFICATIONS

129. GET HIGHEST
PRIORITY FEATURE
ALLOW DEVELOPERSTO CHOOSETHEIR TASKS

130. KANBAN (かんばん)
WORKFLOW MONITORING& VISUALISATION

131. CAN BE AS SIMPLE
OR COMPLEX AS
REQUIRED
THE FLOW OF VALUE THROUGHTHE SYSTEM

138. KANBAN: CLASS OF SERVICE
EXPEDITE
FIXED DELIVERY
STANDARD CLASS
INTANGIBLE CLASS

139. TEST– DRIVEN DEVELOPMENT

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

141. TESTTYPES
DEFECT, USABILITY,
FUNCTIONALITY &
DATA

142. PAIR PROGRAMMING:
CODER + REVIEWER
BUILD

143. CODE STANDARDS:
A COMMON CODING
STYLE
BUILD

144. SYSTEM METAPHOR:
CLEAR NAMING
STANDARDS
BUILD

145. REGULAR COMMITS
VERSION CONTROL

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

147. WHAT DID YOU DO
YESTERDAY?
DAILYSCRUM

148. WHAT WILL YOU DO
TODAY?
DAILYSCRUM

149. ARE THERE ANY
ISSUES?
DAILYSCRUM

150. SCRUM OF SCRUMS
FOR LARGETEAMS

151. CUSTOMERS CAN
ALWAYS SEE
PROGRESS
PROMOTINGTRANSPARENCYTHROUGHTHE
SCRUMSAND BACKLOG

152. VIEW PROGRESSAGAINSTTHE RELEASE
IMPROVE FUTURE
ESTIMATES

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

154. EFFORTVISUALISATION
PLOT DELIVERED
FUNCTIONALITY
AGAINST VELOCITY

155. BURNUP CHART

156. BURNDOWN CHART

157. VELOCITY
HOW MUCH WORK
CAN BE DELIVERED
PER ITERATION

158. DON'TMANAGE BY NUMBERS
IDENTIFY PROBLEM
TRENDS EARLY

159. DISCOVERY

160. SCOPE CREEP

161. PLATEAU

162. TOO MANY FEATURES

163. TRACKING EPICS

164. PLOT DELIVERED
FUNCTIONALITY
AGAINST DURATION
EFFORT VISUALISATION

165. CUMULATIVE FLOW DIAGRAM

166. AVERAGE TIME TO
COMPLETE A TASK
FROM START
CYCLETIME

167. AVERAGE TIME TO
COMPLETE A TASK
FROM REQUEST
LEAD TIME

168. DON'TMANAGE BY NUMBERS
IDENTIFY PROBLEM
TRENDS EARLY

169. BOTTLENECK

170. POOR FLOW

171. LARGE WIP LIMIT

172. LONG LEAD TIME

173. PLATEAU

174. PLOT CYCLE TIME
AGAINST AVERAGE
DURATION VISUALISATION

175. CYCLE TIME RUN CHARTS

176. DON'TMANAGE BY NUMBERS
IDENTIFY PROBLEM
TRENDS EARLY

177. PROCESS TREND

178. PROCESS SHIFT

179. EXTREME PROCESS VARIATION

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

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

182. WHAT DOES
“NOT DONE”
MEAN?
REMEMBERTHE PRIMARYMEASURE OF PROGRESS

183. PER ITERATION OR
ACROSS ITERATIONS
DEPLOY

184. PRESENT & REVIEW
COMPLETED WORK
TO THE CUSTOMER
ITERATION REVIEW

185. RETROSPECTIVE &
KAIZEN (改善)
CONTINUOUS IMPROVEMENT

186. WHAT WENT WELL?
ITERATION RETROSPECTIVE

187. ADDACTIONABLETASKS TO THE PRODUCT
BACKLOG
WHAT COULD BE
IMPROVED?

188. KAIZEN EMPHASISES
TEAMWORK,
DISCIPLINE &
MORALE

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