Agile Methods - 2 day workshop

1,324 views

Published on

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
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,324
On SlideShare
0
From Embeds
0
Number of Embeds
568
Actions
Shares
0
Downloads
53
Comments
0
Likes
3
Embeds 0
No embeds

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.
  • Agile Methods - 2 day workshop

    1. 1. EVAN LEYBOURN EVAN@THEAGILEDIRECTOR.COM AGILE METHODS PART 1: HISTORY & CORE CONCEPTS
    2. 2. Evan Leybourn Lean / Agile Business Leader and Author Melbourne,Australia @eleybourn http://theagiledirector.com
    3. 3. SHU-HA-RI THE STAGES OF LEARNING
    4. 4. 守: SHU(BEGINNER) FOLLOW PRECISELYWITHOUTMODIFICATION
    5. 5. 破:HA (PROFICIENT) SHIFTING BETWEEN TECHNIQUES
    6. 6. 離: RI (MASTERY) UNCONSCIOUS CREATION OF NEW TECHNIQUES
    7. 7. WHAT DOES BEING “AGILE” ACTUALLY MEAN? THEAGILE MANIFESTO
    8. 8. Waterfall Agile
    9. 9. Waterfall (Incrementing) Agile (Iterating) Images with thanks from Jeff Patton: http://www.agileproductdesign.com/
    10. 10. INDIVIDUALS AND INTERACTIONS OVER PROCESSESAND TOOLS
    11. 11. WORKING SOFTWARE OVER COMPREHENSIVE DOCUMENTATION
    12. 12. CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION
    13. 13. RESPONDING TO CHANGE OVER FOLLOWINGAPLAN
    14. 14. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    15. 15. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    16. 16. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    17. 17. 4. Business people and developers must work together daily throughout the project.
    18. 18. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    19. 19. 6. The most efficient and effective method of conveying information to and within a development team is face-to- face conversation.
    20. 20. 7. Working software is the primary measure of progress.
    21. 21. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    22. 22. 9. Continuous attention to technical excellence and good design enhances agility.
    23. 23. 10. Simplicity--the art of maximizing the amount of work not done--is essential.
    24. 24. 11. The best architectures, requirements, and designs emerge from self-organizing teams.
    25. 25. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
    26. 26. Business change via sustained effort across the organisation Change Change Change Images shamelessly stolen from Ahmed Sidky (ICAgile)
    27. 27. INSPECT ADAPT INSPECT HOW DOES “AGILE” WORK
    28. 28. WORKFLOWAND PROJECT MANAGEMENT AUP, CRYSTAL CLEAR, DSDM, KANBAN, RUP, SCRUM
    29. 29. KANBAN 1. Visualise (Card Wall) 2. Limit WIP 3. Manage Flow 4. Make Policies Explicit 5. Feedback Loops 6. Improve Collaboratively
    30. 30. LIMIT WIP REDUCE LEAD TIME, IDENTIFY BLOCKS & CLEAR BOTTLENECKS
    31. 31. SCRUM * Iterative Product Development * 1-4 week Sprints * Formal Roles (Product Owner & Scrum Master) * Timeboxed Meetings
    32. 32. DEVELOPMENT METHODS BDD, FDD, RAD, LEAN SOFTWARE, XP
    33. 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. 34. QUALITY METHODS TEST DRIVEN DEVELOPMENT
    35. 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. 36. MURA: UNEVENNESS MURI: OVERBURDEN MUDA: WASTE UNDERSTANDINGWASTE
    37. 37. TRANSPORTATION THE 7 WASTES
    38. 38. INVENTORY THE 7 WASTES
    39. 39. MOTION THE 7 WASTES
    40. 40. WAITING THE 7 WASTES
    41. 41. OVER PRODUCTION THE 7 WASTES
    42. 42. OVER PROCESSING THE 7 WASTES
    43. 43. DEFECTS THE 7 WASTES
    44. 44. 1. AGILE MEANS NO DOCUMENTATION COMMONAGILE MISTAKES
    45. 45. 2. NOT MEASURING, MONITORING OR CORRECTING COMMONAGILE MISTAKES
    46. 46. COMMONAGILE MISTAKES 3. ASSUMING YOU CAN DO MORE WITH LESS
    47. 47. COMMONAGILE MISTAKES 4. SKIMPING ON TRAINING AND EDUCATION
    48. 48. COMMONAGILE MISTAKES 5. LACKING AN EXECUTIVE SPONSOR
    49. 49. COMMONAGILE MISTAKES 6. THINKING AGILE IS FASTER OR EASY
    50. 50. 7. START WITH A TOOL COMMONAGILE MISTAKES
    51. 51. 8. FAILING TO SCALE COMMONAGILE MISTAKES
    52. 52. 9. ASSUMING AGILE = SCRUM COMMONAGILE MISTAKES
    53. 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. 54. EVAN LEYBOURN EVAN@THEAGILEDIRECTOR.COM AGILE METHODS PART 2: ROLES & RESPONSIBILITIES
    55. 55. Evan Leybourn Lean / Agile Business Leader and Author Melbourne,Australia @eleybourn http://theagiledirector.com CLICK TO DISCOVER MORE
    56. 56. USERS WILL USE THE SOFTWARE, IDENTIFY ISSUES & PROVIDE FEEDBACK
    57. 57. USERS CAN BE THERE ARE NO TYPICAL USERS
    58. 58. USERS DO NOT SET SCOPE OR TEST WORK
    59. 59. CUSTOMERSWILL DEFINE, START& END THE PROJECT
    60. 60. CUSTOMERSCAN BE INTERNAL MANAGERS OR EXTERNAL CLIENTS
    61. 61. CUSTOMERS DO NOT DIRECT WORK
    62. 62. THE PRODUCT OWNER WILL MANAGE THE PRODUCT BACKLOG, SET THE SCOPE & APPROVE RELEASES
    63. 63. THE PRODUCT OWNER CAN BE PROJECT MANAGER, PRODUCT MANAGER OR CUSTOMER
    64. 64. THE PRODUCTOWNER DOES NOT MANAGE THE TEAM
    65. 65. THE SCRUM MASTER WILL MANAGE THE AGILE PROCESS & REPORT ON PROGRESS
    66. 66. THE SCRUM MASTER CAN BE PROJECT MANAGER, TEAM LEADER OR TEAM MEMBER
    67. 67. THE SCRUM MASTER DOES NOT PRIORITISE FEATURES
    68. 68. DEVELOPERS WILL DEVELOP FEATURES, AND RESOLVE ISSUES
    69. 69. DEVELOPERS CAN BE DEVELOPERS, DESIGNERS, WRITERS, OR ADMINISTRATORS CROSS FUNCTIONAL
    70. 70. DEVELOPERS DO NOT PRIORITISE FEATURES
    71. 71. TESTERS WILL TEST, APPROVE OR REJECT FEATURES FOR RELEASE
    72. 72. TESTERS CAN BE EXISTING DEVELOPERS OR DEDICATED TESTERS
    73. 73. TESTERS DO NOT TEST THEIR OWN CODE
    74. 74. 7 +/- 2 TYPICALTEAM SIZE
    75. 75. HAS AN INTEREST IN THE WORK & IS KEPT UP TO DATE INVOLVED PARTIES (CHICKENS)
    76. 76. COMMITTED PARTIES (PIGS) "DO" THE WORK & ARE RESPONSIBLE FOR THE RELEASE
    77. 77. VALUE STREAM MAPPING DEFINES THE „AS-IS‟ STEPS & ROLES FOR EACH TASK
    78. 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. 79. EVAN LEYBOURN EVAN@THEAGILEDIRECTOR.COM AGILE METHODS PART 3: PROJECT INITIATION
    80. 80. Evan Leybourn Lean / Agile Business Leader and Author Melbourne,Australia @eleybourn http://theagiledirector.com CLICK TO DISCOVER MORE
    81. 81. ALSO KNOWNAS FEASIBILITY, SPRINT 0 (SCRUM) OR ITERATION 0 (XP)
    82. 82. REDUCE RISK & UNCERTAINTY BY DEFININGTHE HIGH LEVELSCOPE
    83. 83. ALIGN TO STRATEGIC GOALS, & TECHNICAL FRAMEWORKS SKILLS GAPANALYSIS & RECRUITMENT
    84. 84. BEGINNINGTHE PROCESS AGILE PROJECTS HAVE MINIMAL INITIATION
    85. 85. THE DEVELOPMENTTEAM SHOULD BE ENGAGED DURING INITIATION
    86. 86. CUSTOMER IS FULLY AWARE OF THEIR RESPONSIBILITIES CUSTOMERSSHAREACCOUNTABILITYFOR DELIVERY
    87. 87. REMOVEANY POTENTIALIMPEDIMENTS ADD TRAINING TASKS TO THE BACKLOG
    88. 88. “Friends don’t let friends use Microsoft Project”
    89. 89. CREATE THE INITIAL PRODUCT BACKLOG (IN LOW DETAIL) ALLOW CUSTOMERSTO SLOWLYDEFINETHEIR NEEDS
    90. 90. ESTIMATE THE PRODUCT BACKLOG FIRSTORDER ESTIMATE- USING STORYPOINTS
    91. 91. 1, 2, 3, 5, 8, 13, 20, 40, 100 FIBONACCISEQUENCE
    92. 92. EXPERT OPINION THE TEAM MEMBER WITH SPECIFIC DOMAIN KNOWLEDGE E.G.ADBAESTIMATING DATABASETASKS.
    93. 93. COMPARISON COMPARING A TASK TO ANOTHER, ESTIMATED, TASK. E.G.TASKAISABOUTTWICETHE EFFORTOF TASKB
    94. 94. COMPONENTS BREAK A LARGE TASK INTO SMALL SUB-TASKS E.G. BREAK USER MANAGEMENT INTO INTERFACE, LOGIN,ACCESS CONTROL, ETC.
    95. 95. PLANNING POKER EACH TEAM MEMBER PLAYS A CARD REPRESENTING THEIR ESTIMATE EVERYONE PARTICIPATESTO REACH CONSENSUS
    96. 96. Estimates must not be mentioned during planning discussion to avoid anchoring
    97. 97. STAFF OVERHEAD: NON PROJECTTIME ESTIMATED LEAVE, ILLNESS, BREAKS, MEETINGS ETC. GENERIC INDUSTRYMODIFIER:25%
    98. 98. DURATION CALCULATION STORY COST X (OVERHEAD + 1) X (ESTIMATE RISK + 1) ESTIMATE RISK IS OPTIONAL
    99. 99. FOR EXAMPLE 4 X (25% + 1) X (50%+ 1) = 4 X 1.25 X 1.5 = 5 TO 7.5 HOURS
    100. 100. ITERATIONS SHOULD BE BETWEEN 1 & 4 WEEKS SHORTER ITERATIONS PROVIDE MORE OPPORTUNITIES TO INSPECT &ADAPT
    101. 101. - “How much is this going to cost?” - “As much as you’re willing to spend.”
    102. 102. - “How long is this going to take?” - “As long as is necessary.”
    103. 103. - “What am I going to get?” - “Whatever you tell us you want.”
    104. 104. WORK IN PRIORITY ORDER, RELEASE QUICKLY & MONITOR BURN RATE FIXED COST
    105. 105. WORK IN PRIORITY ORDER & ENFORCE ITERATION LENGTH FIXEDTIME
    106. 106. FIXED SCOPE FOCUS ON BACKLOG DEFINITION AND ESTIMATION
    107. 107. FIXED COSTAND TIME CALCULATE TOTAL COST AS COST PER ITERATION
    108. 108. FIXED COSTAND SCOPE INCREASE THE ESTIMATE RISK DURING ITERATION 0
    109. 109. FIXEDTIMEAND SCOPE PRE-ASSIGN WORK TO ITERATIONS & PAD SCHEDULE WITH EXTRA ITERATIONS
    110. 110. FIXED COST,TIMEAND SCOPE CANCEL THE PROJECT
    111. 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. 112. EVAN LEYBOURN EVAN@THEAGILEDIRECTOR.COM AGILE METHODS PART 4: ITERATIONS
    113. 113. Evan Leybourn Lean / Agile Business Leader and Author Melbourne,Australia @eleybourn http://theagiledirector.com CLICK TO DISCOVER MORE
    114. 114. CONVERT THE BACKLOG INTO A REALISTIC GOAL ITERATION PLANNING
    115. 115. THIS IS A CREATIVE PROCESS: PREPARE BEFOREHAND SUPPLYPAPER,AWHITEBOARDAND INTERNETACCESS.
    116. 116. PRIORITISE THE PRODUCT BACKLOG BEFORETHE PLANNING WORKSHOP
    117. 117. DEFINE THE BUSINESS GOAL FOR THE ITERATION PART 1: BUSINESS PLANNING
    118. 118. ENCOURAGEASTABLE & CONSISTENTWORKFLOW ITERATION SCOPE IS LIMITED BY TEAM VELOCITY
    119. 119. PART 2:TECHNICALPLANNING DECOMPOSE USER STORIES INTO TASKS (< 1 DAY)
    120. 120. CREATE THE ITERATION BACKLOG (IN HIGH DETAIL) OWNED & MAINTAINED BYTHE DEVELOPERS
    121. 121. PLAN, DESIGN & ESTIMATE TASKS TECHNICALSPECIFICATIONS
    122. 122. GET HIGHEST PRIORITY FEATURE ALLOW DEVELOPERSTO CHOOSETHEIR TASKS
    123. 123. KANBAN (かんばん) WORKFLOW MONITORING& VISUALISATION
    124. 124. CAN BE AS SIMPLE OR COMPLEX AS REQUIRED THE FLOW OF VALUE THROUGHTHE SYSTEM
    125. 125. KANBAN: CLASS OF SERVICE EXPEDITE FIXED DELIVERY STANDARD CLASS INTANGIBLE CLASS
    126. 126. TEST– DRIVEN DEVELOPMENT
    127. 127. TEST COVERAGE FUNCTIONS, BOUNDARY CASES, USER INTERFACE & PERFORMANCE
    128. 128. TESTTYPES DEFECT, USABILITY, FUNCTIONALITY & DATA
    129. 129. PAIR PROGRAMMING: CODER + REVIEWER BUILD
    130. 130. CODE STANDARDS: A COMMON CODING STYLE BUILD
    131. 131. SYSTEM METAPHOR: CLEAR NAMING STANDARDS BUILD
    132. 132. REGULAR COMMITS VERSION CONTROL
    133. 133. AUTOMATED: UNIT TESTING, COVERAGE, DOCUMENTATION, STANDARDS & BUILD CONTINUOUS INTEGRATION
    134. 134. WHAT DID YOU DO YESTERDAY? DAILYSCRUM
    135. 135. WHAT WILL YOU DO TODAY? DAILYSCRUM
    136. 136. ARE THERE ANY ISSUES? DAILYSCRUM
    137. 137. SCRUM OF SCRUMS FOR LARGETEAMS
    138. 138. CUSTOMERS CAN ALWAYS SEE PROGRESS PROMOTINGTRANSPARENCYTHROUGHTHE SCRUMSAND BACKLOG
    139. 139. VIEW PROGRESSAGAINSTTHE RELEASE IMPROVE FUTURE ESTIMATES
    140. 140. PROGRESS MONITORING BURNUP CHARTS BURNDOWN CHARTS CUMULATIVE FLOW STATISTICAL RUN
    141. 141. EFFORTVISUALISATION PLOT DELIVERED FUNCTIONALITY AGAINST VELOCITY
    142. 142. BURNUP CHART
    143. 143. BURNDOWN CHART
    144. 144. VELOCITY HOW MUCH WORK CAN BE DELIVERED PER ITERATION
    145. 145. DON'TMANAGE BY NUMBERS IDENTIFY PROBLEM TRENDS EARLY
    146. 146. DISCOVERY
    147. 147. SCOPE CREEP
    148. 148. PLATEAU
    149. 149. TOO MANY FEATURES
    150. 150. TRACKING EPICS
    151. 151. PLOT DELIVERED FUNCTIONALITY AGAINST DURATION EFFORT VISUALISATION
    152. 152. CUMULATIVE FLOW DIAGRAM
    153. 153. AVERAGE TIME TO COMPLETE A TASK FROM START CYCLETIME
    154. 154. AVERAGE TIME TO COMPLETE A TASK FROM REQUEST LEAD TIME
    155. 155. DON'TMANAGE BY NUMBERS IDENTIFY PROBLEM TRENDS EARLY
    156. 156. BOTTLENECK
    157. 157. POOR FLOW
    158. 158. LARGE WIP LIMIT
    159. 159. LONG LEAD TIME
    160. 160. PLATEAU
    161. 161. PLOT CYCLE TIME AGAINST AVERAGE DURATION VISUALISATION
    162. 162. CYCLE TIME RUN CHARTS
    163. 163. DON'TMANAGE BY NUMBERS IDENTIFY PROBLEM TRENDS EARLY
    164. 164. PROCESS TREND
    165. 165. PROCESS SHIFT
    166. 166. EXTREME PROCESS VARIATION
    167. 167. DIFFERS BY ORGANISATION WHAT DOES “DONE” MEAN?
    168. 168. DEFINITION OF “DONE” DOCUMENTATION? UAT? BUILT / COMPILED?
    169. 169. WHAT DOES “NOT DONE” MEAN? REMEMBERTHE PRIMARYMEASURE OF PROGRESS
    170. 170. PER ITERATION OR ACROSS ITERATIONS DEPLOY
    171. 171. PRESENT & REVIEW COMPLETED WORK TO THE CUSTOMER ITERATION REVIEW
    172. 172. RETROSPECTIVE & KAIZEN (改善) CONTINUOUS IMPROVEMENT
    173. 173. WHAT WENT WELL? ITERATION RETROSPECTIVE
    174. 174. ADDACTIONABLETASKS TO THE PRODUCT BACKLOG WHAT COULD BE IMPROVED?
    175. 175. KAIZEN EMPHASISES TEAMWORK, DISCIPLINE & MORALE
    176. 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

    ×