Your SlideShare is downloading. ×
  • Like
Agile Methods - 2 day workshop
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agile Methods - 2 day workshop

  • 539 views
Published

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). …

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

Learn how to improve your Software Development or Business Intelligence processes using modern Agile project management in a fun, friendly and effective way!

Traditional software project management is based on hierarchically driven, fixed outcome systems and processes. Agile project management, however, is an iterative planning & development approach that can be applied, day-to-day, to improve overall quality and customer satisfaction.

This two day course covers the basic concepts of Agile project management and how these methodologies can be used within your organisation. This course aims to provide the tools for software managers and teams to improve customer satisfaction through the rapid and continuous delivery of useful software. We also look at how to use the best of traditional (or waterfall) processes within Agile techniques.

Published in Education , Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
539
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
18
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Add ABM/GDAC logo
  • Let’s finish off by looking at our original definition of business growth; Business growth comes from applying profitability to customer growth. Profitability comes from delivering services to your customers, accurately and efficiently. Over the last 15 minutes we have looked at some of the mechanisms from the lean and agile traditions that we can apply for adaptable businesses and sustainable business growth. And I’ll leave you on that note. Any questions.
  • Add ABM/GDAC logo
  • Let’s finish off by looking at our original definition of business growth; Business growth comes from applying profitability to customer growth. Profitability comes from delivering services to your customers, accurately and efficiently. Over the last 15 minutes we have looked at some of the mechanisms from the lean and agile traditions that we can apply for adaptable businesses and sustainable business growth. And I’ll leave you on that note. Any questions.
  • Add ABM/GDAC logo
  • Let’s finish off by looking at our original definition of business growth; Business growth comes from applying profitability to customer growth. Profitability comes from delivering services to your customers, accurately and efficiently. Over the last 15 minutes we have looked at some of the mechanisms from the lean and agile traditions that we can apply for adaptable businesses and sustainable business growth. And I’ll leave you on that note. Any questions.
  • Add ABM/GDAC logo
  • Let’s finish off by looking at our original definition of business growth; Business growth comes from applying profitability to customer growth. Profitability comes from delivering services to your customers, accurately and efficiently. Over the last 15 minutes we have looked at some of the mechanisms from the lean and agile traditions that we can apply for adaptable businesses and sustainable business growth. And I’ll leave you on that note. Any questions.

Transcript

  • 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
  • 56. USERS WILL USE THE SOFTWARE, IDENTIFY ISSUES & PROVIDE FEEDBACK
  • 57. USERS CAN BE THERE ARE NO TYPICAL USERS
  • 58. USERS DO NOT SET SCOPE OR TEST WORK
  • 59. CUSTOMERSWILL DEFINE, START& END THE PROJECT
  • 60. CUSTOMERSCAN BE INTERNAL MANAGERS OR EXTERNAL CLIENTS
  • 61. CUSTOMERS DO NOT DIRECT WORK
  • 62. THE PRODUCT OWNER WILL MANAGE THE PRODUCT BACKLOG, SET THE SCOPE & APPROVE RELEASES
  • 63. THE PRODUCT OWNER CAN BE PROJECT MANAGER, PRODUCT MANAGER OR CUSTOMER
  • 64. THE PRODUCTOWNER DOES NOT MANAGE THE TEAM
  • 65. THE SCRUM MASTER WILL MANAGE THE AGILE PROCESS & REPORT ON PROGRESS
  • 66. THE SCRUM MASTER CAN BE PROJECT MANAGER, TEAM LEADER OR TEAM MEMBER
  • 67. THE SCRUM MASTER DOES NOT PRIORITISE FEATURES
  • 68. DEVELOPERS WILL DEVELOP FEATURES, AND RESOLVE ISSUES
  • 69. DEVELOPERS CAN BE DEVELOPERS, DESIGNERS, WRITERS, OR ADMINISTRATORS CROSS FUNCTIONAL
  • 70. DEVELOPERS DO NOT PRIORITISE FEATURES
  • 71. TESTERS WILL TEST, APPROVE OR REJECT FEATURES FOR RELEASE
  • 72. TESTERS CAN BE EXISTING DEVELOPERS OR DEDICATED TESTERS
  • 73. TESTERS DO NOT TEST THEIR OWN CODE
  • 74. 7 +/- 2 TYPICALTEAM SIZE
  • 75. HAS AN INTEREST IN THE WORK & IS KEPT UP TO DATE INVOLVED PARTIES (CHICKENS)
  • 76. COMMITTED PARTIES (PIGS) "DO" THE WORK & ARE RESPONSIBLE FOR THE RELEASE
  • 77. VALUE STREAM MAPPING DEFINES THE „AS-IS‟ STEPS & ROLES FOR EACH TASK
  • 78. TO LEARN MORE, CHECK OUT DIRECTING THE AGILE ORGANISATIONBY EVAN LEYBOURN AVAILABLE AT AMAZON AND ALL GOOD BOOK STORES CLICK HERE TO DISCOVER MORE
  • 79. EVAN LEYBOURN EVAN@THEAGILEDIRECTOR.COM AGILE METHODS PART 3: PROJECT INITIATION
  • 80. Evan Leybourn Lean / Agile Business Leader and Author Melbourne,Australia @eleybourn http://theagiledirector.com CLICK TO DISCOVER MORE
  • 81. ALSO KNOWNAS FEASIBILITY, SPRINT 0 (SCRUM) OR ITERATION 0 (XP)
  • 82. REDUCE RISK & UNCERTAINTY BY DEFININGTHE HIGH LEVELSCOPE
  • 83. ALIGN TO STRATEGIC GOALS, & TECHNICAL FRAMEWORKS SKILLS GAPANALYSIS & RECRUITMENT
  • 84. BEGINNINGTHE PROCESS AGILE PROJECTS HAVE MINIMAL INITIATION
  • 85. THE DEVELOPMENTTEAM SHOULD BE ENGAGED DURING INITIATION
  • 86. CUSTOMER IS FULLY AWARE OF THEIR RESPONSIBILITIES CUSTOMERSSHAREACCOUNTABILITYFOR DELIVERY
  • 87. REMOVEANY POTENTIALIMPEDIMENTS ADD TRAINING TASKS TO THE BACKLOG
  • 88. “Friends don’t let friends use Microsoft Project”
  • 89. CREATE THE INITIAL PRODUCT BACKLOG (IN LOW DETAIL) ALLOW CUSTOMERSTO SLOWLYDEFINETHEIR NEEDS
  • 90. ESTIMATE THE PRODUCT BACKLOG FIRSTORDER ESTIMATE- USING STORYPOINTS
  • 91. 1, 2, 3, 5, 8, 13, 20, 40, 100 FIBONACCISEQUENCE
  • 92. EXPERT OPINION THE TEAM MEMBER WITH SPECIFIC DOMAIN KNOWLEDGE E.G.ADBAESTIMATING DATABASETASKS.
  • 93. COMPARISON COMPARING A TASK TO ANOTHER, ESTIMATED, TASK. E.G.TASKAISABOUTTWICETHE EFFORTOF TASKB
  • 94. COMPONENTS BREAK A LARGE TASK INTO SMALL SUB-TASKS E.G. BREAK USER MANAGEMENT INTO INTERFACE, LOGIN,ACCESS CONTROL, ETC.
  • 95. PLANNING POKER EACH TEAM MEMBER PLAYS A CARD REPRESENTING THEIR ESTIMATE EVERYONE PARTICIPATESTO REACH CONSENSUS
  • 96. Estimates must not be mentioned during planning discussion to avoid anchoring
  • 97. STAFF OVERHEAD: NON PROJECTTIME ESTIMATED LEAVE, ILLNESS, BREAKS, MEETINGS ETC. GENERIC INDUSTRYMODIFIER:25%
  • 98. DURATION CALCULATION STORY COST X (OVERHEAD + 1) X (ESTIMATE RISK + 1) ESTIMATE RISK IS OPTIONAL
  • 99. FOR EXAMPLE 4 X (25% + 1) X (50%+ 1) = 4 X 1.25 X 1.5 = 5 TO 7.5 HOURS
  • 100. ITERATIONS SHOULD BE BETWEEN 1 & 4 WEEKS SHORTER ITERATIONS PROVIDE MORE OPPORTUNITIES TO INSPECT &ADAPT
  • 101. - “How much is this going to cost?” - “As much as you’re willing to spend.”
  • 102. - “How long is this going to take?” - “As long as is necessary.”
  • 103. - “What am I going to get?” - “Whatever you tell us you want.”
  • 104. WORK IN PRIORITY ORDER, RELEASE QUICKLY & MONITOR BURN RATE FIXED COST
  • 105. WORK IN PRIORITY ORDER & ENFORCE ITERATION LENGTH FIXEDTIME
  • 106. FIXED SCOPE FOCUS ON BACKLOG DEFINITION AND ESTIMATION
  • 107. FIXED COSTAND TIME CALCULATE TOTAL COST AS COST PER ITERATION
  • 108. FIXED COSTAND SCOPE INCREASE THE ESTIMATE RISK DURING ITERATION 0
  • 109. FIXEDTIMEAND SCOPE PRE-ASSIGN WORK TO ITERATIONS & PAD SCHEDULE WITH EXTRA ITERATIONS
  • 110. FIXED COST,TIMEAND SCOPE CANCEL THE PROJECT
  • 111. TO LEARN MORE, CHECK OUT DIRECTING THE AGILE ORGANISATIONBY EVAN LEYBOURN AVAILABLE AT AMAZON AND ALL GOOD BOOK STORES CLICK HERE TO DISCOVER MORE
  • 112. EVAN LEYBOURN EVAN@THEAGILEDIRECTOR.COM AGILE METHODS PART 4: ITERATIONS
  • 113. Evan Leybourn Lean / Agile Business Leader and Author Melbourne,Australia @eleybourn http://theagiledirector.com CLICK TO DISCOVER MORE
  • 114. CONVERT THE BACKLOG INTO A REALISTIC GOAL ITERATION PLANNING
  • 115. THIS IS A CREATIVE PROCESS: PREPARE BEFOREHAND SUPPLYPAPER,AWHITEBOARDAND INTERNETACCESS.
  • 116. PRIORITISE THE PRODUCT BACKLOG BEFORETHE PLANNING WORKSHOP
  • 117. DEFINE THE BUSINESS GOAL FOR THE ITERATION PART 1: BUSINESS PLANNING
  • 118. ENCOURAGEASTABLE & CONSISTENTWORKFLOW ITERATION SCOPE IS LIMITED BY TEAM VELOCITY
  • 119. PART 2:TECHNICALPLANNING DECOMPOSE USER STORIES INTO TASKS (< 1 DAY)
  • 120. CREATE THE ITERATION BACKLOG (IN HIGH DETAIL) OWNED & MAINTAINED BYTHE DEVELOPERS
  • 121. PLAN, DESIGN & ESTIMATE TASKS TECHNICALSPECIFICATIONS
  • 122. GET HIGHEST PRIORITY FEATURE ALLOW DEVELOPERSTO CHOOSETHEIR TASKS
  • 123. KANBAN (かんばん) WORKFLOW MONITORING& VISUALISATION
  • 124. CAN BE AS SIMPLE OR COMPLEX AS REQUIRED THE FLOW OF VALUE THROUGHTHE SYSTEM
  • 125. KANBAN: CLASS OF SERVICE EXPEDITE FIXED DELIVERY STANDARD CLASS INTANGIBLE CLASS
  • 126. TEST– DRIVEN DEVELOPMENT
  • 127. TEST COVERAGE FUNCTIONS, BOUNDARY CASES, USER INTERFACE & PERFORMANCE
  • 128. TESTTYPES DEFECT, USABILITY, FUNCTIONALITY & DATA
  • 129. PAIR PROGRAMMING: CODER + REVIEWER BUILD
  • 130. CODE STANDARDS: A COMMON CODING STYLE BUILD
  • 131. SYSTEM METAPHOR: CLEAR NAMING STANDARDS BUILD
  • 132. REGULAR COMMITS VERSION CONTROL
  • 133. AUTOMATED: UNIT TESTING, COVERAGE, DOCUMENTATION, STANDARDS & BUILD CONTINUOUS INTEGRATION
  • 134. WHAT DID YOU DO YESTERDAY? DAILYSCRUM
  • 135. WHAT WILL YOU DO TODAY? DAILYSCRUM
  • 136. ARE THERE ANY ISSUES? DAILYSCRUM
  • 137. SCRUM OF SCRUMS FOR LARGETEAMS
  • 138. CUSTOMERS CAN ALWAYS SEE PROGRESS PROMOTINGTRANSPARENCYTHROUGHTHE SCRUMSAND BACKLOG
  • 139. VIEW PROGRESSAGAINSTTHE RELEASE IMPROVE FUTURE ESTIMATES
  • 140. PROGRESS MONITORING BURNUP CHARTS BURNDOWN CHARTS CUMULATIVE FLOW STATISTICAL RUN
  • 141. EFFORTVISUALISATION PLOT DELIVERED FUNCTIONALITY AGAINST VELOCITY
  • 142. BURNUP CHART
  • 143. BURNDOWN CHART
  • 144. VELOCITY HOW MUCH WORK CAN BE DELIVERED PER ITERATION
  • 145. DON'TMANAGE BY NUMBERS IDENTIFY PROBLEM TRENDS EARLY
  • 146. DISCOVERY
  • 147. SCOPE CREEP
  • 148. PLATEAU
  • 149. TOO MANY FEATURES
  • 150. TRACKING EPICS
  • 151. PLOT DELIVERED FUNCTIONALITY AGAINST DURATION EFFORT VISUALISATION
  • 152. CUMULATIVE FLOW DIAGRAM
  • 153. AVERAGE TIME TO COMPLETE A TASK FROM START CYCLETIME
  • 154. AVERAGE TIME TO COMPLETE A TASK FROM REQUEST LEAD TIME
  • 155. DON'TMANAGE BY NUMBERS IDENTIFY PROBLEM TRENDS EARLY
  • 156. BOTTLENECK
  • 157. POOR FLOW
  • 158. LARGE WIP LIMIT
  • 159. LONG LEAD TIME
  • 160. PLATEAU
  • 161. PLOT CYCLE TIME AGAINST AVERAGE DURATION VISUALISATION
  • 162. CYCLE TIME RUN CHARTS
  • 163. DON'TMANAGE BY NUMBERS IDENTIFY PROBLEM TRENDS EARLY
  • 164. PROCESS TREND
  • 165. PROCESS SHIFT
  • 166. EXTREME PROCESS VARIATION
  • 167. DIFFERS BY ORGANISATION WHAT DOES “DONE” MEAN?
  • 168. DEFINITION OF “DONE” DOCUMENTATION? UAT? BUILT / COMPILED?
  • 169. WHAT DOES “NOT DONE” MEAN? REMEMBERTHE PRIMARYMEASURE OF PROGRESS
  • 170. PER ITERATION OR ACROSS ITERATIONS DEPLOY
  • 171. PRESENT & REVIEW COMPLETED WORK TO THE CUSTOMER ITERATION REVIEW
  • 172. RETROSPECTIVE & KAIZEN (改善) CONTINUOUS IMPROVEMENT
  • 173. WHAT WENT WELL? ITERATION RETROSPECTIVE
  • 174. ADDACTIONABLETASKS TO THE PRODUCT BACKLOG WHAT COULD BE IMPROVED?
  • 175. KAIZEN EMPHASISES TEAMWORK, DISCIPLINE & MORALE
  • 176. TO LEARN MORE, CHECK OUT DIRECTING THE AGILE ORGANISATIONBY EVAN LEYBOURN AVAILABLE AT AMAZON AND ALL GOOD BOOK STORES CLICK HERE TO DISCOVER MORE