Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lean Kanban Practitioner

1,980 views

Published on

As part of an ongoing release of all my training material following the launch of my new book, I am releasing "Lean Kanban Practitioner" under a Creative Commons Attribution Share-Alike license. That is, you are free to share, copy, and adapt any part of this training course for your own purposes. All materials, including examples are available for download from this page.

Lean is a streamlined development, manufacturing and production technique as well as a philosophy that aims to reduce costs by eliminating all ‘wasteful’ processes. Put another way, Lean focuses on ‘getting the right things to the right place at the right time in the right quantity to achieve perfect workflow.’

This two day workshop provides a practical grounding in Lean techniques and how these can be used within your organisation. This workshop aims to provide the tools for managers and teams to improve their workflow, reduce waste and regain control of their processes. The workshop uses fun and interactive scenarios which provide practical experience in using these techniques.

Published in: Business
  • There is a useful site for you that will help you to write a perfect and valuable essay and so on. Check out, please ⇒ www.WritePaper.info ⇐
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Lean Kanban Practitioner

  1. 1. EvanLeybourn LEAN KANBAN PRACTITIONER Aleanapproachtoefficientworkflowmanagement Starting with Value Stream Mapping and Kanban by Evan Leybourn is licensed under a Creative Commons Attribution-ShareAlike 3.0 Australia License <http://creativecommons.org/licenses/by-sa/3.0/au/>
  2. 2. Evan Leybourn lean / agile business leader and author Singapore @eleybourn evan@theagiledirector.com http://theagiledirector.com CLICK TO DISCOVER MORE
  3. 3. lean,agile&kanbanforsoftware part 1: history & core concepts
  4. 4. shu-ha-ri thestagesoflearning
  5. 5. 守: shu(beginner) followpreciselywithoutmodification
  6. 6. 破:ha (proficient) shiftingbetweentechniques
  7. 7. 離: ri (mastery) unconsciouscreationofnewtechniques
  8. 8. what does being “agile” actuallymean? theagilemanifesto
  9. 9. waterfall agile
  10. 10. Waterfall (Incrementing) Agile (Iterating) Images with thanks from Jeff Patton:
  11. 11. individualsand interactions overprocessesandtools
  12. 12. working software overcomprehensivedocumentation
  13. 13. customer collaboration overcontractnegotiation
  14. 14. responding to change overfollowingaplan
  15. 15. 1. our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  16. 16. 2. welcome changing requirements, even late in development. agile processes harness change for the customer's competitive advantage.
  17. 17. 3. deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  18. 18. 4. business people and developers must work together daily throughout the project.
  19. 19. 5. build projects around motivated individuals. give them the environment and support they need, and trust them to get the job done.
  20. 20. 6. the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  21. 21. 7. working software is the primary measure of progress.
  22. 22. 8. agile processes promote sustainable development. the sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  23. 23. 9. continuous attention to technical excellence and good design enhances agility.
  24. 24. 10.simplicity--the art of maximizing the amount of work not done--is essential.
  25. 25. 11.the best architectures, requirements, and designs emerge from self- organizing teams.
  26. 26. 12.at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
  27. 27. leanprinciples 1. eliminate waste
  28. 28. leanprinciples 2. amplify learning
  29. 29. leanprinciples 3. decide as late as possible
  30. 30. leanprinciples 4. deliver as fast as possible
  31. 31. leanprinciples 5. empower the team
  32. 32. leanprinciples 6. build integrity in
  33. 33. leanprinciples 7. see the whole
  34. 34. business change via sustained effort across the organisation Change Change Change Images shamelessly stolen from Ahmed Sidky (ICAgile)
  35. 35. workflowandprojectmanagement aup, crystal clear, dsdm, kanban, rup, scrum
  36. 36. kanban 1. visualise (card wall) 2. limit wip 3. manage flow 4. make policies explicit 5. feedback loops 6. improve collaboratively
  37. 37. limitwip reduce lead time, identifyblocks & clear bottlenecks
  38. 38. scrum * iterative product development * 1-4 week sprints * formal roles (product owner & scrum master) * timeboxed meetings
  39. 39. development methods bdd, fdd, rad, lean software, xp
  40. 40. extreme programming activities writing the software testing the software listening to the customer designing & refactoring development pair programming common code standards clear system metaphor
  41. 41. qualitymethods test driven development
  42. 42. 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)
  43. 43. mura: unevenness muri: overburden muda: waste understandingwaste
  44. 44. 1. transportation the7wastes
  45. 45. 2. inventory the7wastes
  46. 46. 3. motion the7wastes
  47. 47. 4. waiting the7wastes
  48. 48. 5. over production the7wastes
  49. 49. 6. over processing the7wastes
  50. 50. 7. defects the7wastes
  51. 51. agile means no documentation commonagilemistakes
  52. 52. not measuring, monitoring or correcting commonagilemistakes
  53. 53. commonagilemistakes assuming you can do more withless
  54. 54. commonagilemistakes skimping on training and education
  55. 55. commonagilemistakes lacking an executivesponsor
  56. 56. commonagilemistakes thinking agile is fasteror easy
  57. 57. start with a tool commonagilemistakes
  58. 58. failing to scale commonagilemistakes
  59. 59. assuming agile = scrum commonagilemistakes
  60. 60. evanleybourn evan@theagiledirector.com questions???
  61. 61. lean,agile&kanbanforsoftware part 2: roles & responsibilities
  62. 62. userswill use the software,identify issues& provide feedback
  63. 63. userscanbe there are no typical users
  64. 64. usersdonot set scope or test work
  65. 65. customerswill define, start& end the project
  66. 66. customerscanbe internal managers or external clients
  67. 67. customersdonot direct work
  68. 68. thecustomerrepresentativewill manage the product backlog, set the scope & approve releases
  69. 69. thecustomerrepresentativecanbe project manager, product manager or customer
  70. 70. thecustomerrepresentativedoesnot manage the team
  71. 71. theteamfacilitatorwill manage the agile process & report on progress
  72. 72. theteamfacilitatorcanbe project manager, team leader or team member
  73. 73. theteamfacilitatordoesnot prioritisefeatures
  74. 74. developerswill develop features, and resolveissues
  75. 75. developerscanbe developers,designers,writers,or administrators crossfunctional
  76. 76. developersdonot prioritisefeatures
  77. 77. testerswill test, approve or reject features for release
  78. 78. testerscanbe existing developers or dedicated testers
  79. 79. testersdonot test their own code
  80. 80. 7 +/- 2 typicalteamsize
  81. 81. has an interestin the work & is kept up to date involvedparties(chickens)
  82. 82. committedparties(pigs) "do" the work & are responsible for the release
  83. 83. evanleybourn evan@theagiledirector.com questions???
  84. 84. lean,agile&kanbanforsoftware part 3: project initiation
  85. 85. valuestreammapping defines the ‘as-is’ steps & roles for each task
  86. 86. valueadded time spent on outcomes for the customer
  87. 87. non-valueadded time spent between steps
  88. 88. 1. gather preliminary information 2. product quantity routing analysis 3. group customers and materials 4. sort product families by sequence 5. choose one value stream to start
  89. 89. 6. create an operations flow chart 7. walk the shop floor 8. collect the data 9. construct the vsm 10. summarize the data to get the big picture
  90. 90. reduce risk & uncertainty bydefiningthehighlevelscope
  91. 91. align to strategic goals, & technical frameworks skillsgapanalysis&recruitment
  92. 92. beginningtheprocess agile projects have minimal initiation
  93. 93. thedevelopmentteamshouldbe engaged during initiation
  94. 94. customer is fully aware of their responsibilities customersshareaccountabilityfordelivery
  95. 95. “friends don’t let friends use microsoft project”
  96. 96. - “how much is this going to cost?” - “as much as you’re willing to spend.”
  97. 97. - “how long is this going to take?” - “as long as is necessary.”
  98. 98. - “what am i going to get?” - “whatever you tell us you want.”
  99. 99. work in priority order, release quickly & monitor cycle time fixedcost
  100. 100. work in priority order fixedtime
  101. 101. fixedscope focus on backlog definition and estimation
  102. 102. fixedcostandtime calculate total cost against cycle time
  103. 103. fixedcostandscope increase the estimaterisk during initiation
  104. 104. fixedtimeandscope allocation additional time into the schedule
  105. 105. fixedcost,timeandscope cancel the project
  106. 106. evanleybourn evan@theagiledirector.com questions???
  107. 107. lean,agile&kanbanforsoftware part 4: stories, tasks & the backlog
  108. 108. define user stories asa...ineed...soican...
  109. 109. investcharacteristics independent & self-contained
  110. 110. investcharacteristics negotiable & flexible
  111. 111. investcharacteristics valuable to the customer
  112. 112. investcharacteristics estimatable and clearly defined
  113. 113. investcharacteristics small – between ½ - 2 days
  114. 114. investcharacteristics testable with defined qc metrics
  115. 115. create an ordered product backlog (in low detail) allowcustomerstoslowlydefinetheirneeds
  116. 116. estimatethe product backlog firstorderestimate-usingstorypoints
  117. 117. 1, 2, 3, 5, 8, 13, 20, 40, 100 fibonaccisequence
  118. 118. expertopinion the team member with specific domain knowledge e.g.dbaestimatingdatabasetasks
  119. 119. comparison comparing a task to another, estimated, task e.g.taskaisabouttwicetheeffortoftaskb
  120. 120. components break a large task into small sub-tasks e.g.breakusermanagementintointerface,login,accesscontrol,etc.
  121. 121. planningpoker everyone plays a card representing their estimate everyoneparticipatestoreachconsensus
  122. 122. Estimates must not be mentioned during planning discussion to avoid anchoring
  123. 123. staffoverhead:nonprojecttime estimated leave,illness,breaks, meetings etc. genericindustrymodifier:25%
  124. 124. durationcalculation story cost x (overhead + 1) x (estimate risk + 1) estimateriskisoptional
  125. 125. forexample 4 x (25% + 1) x (50%+ 1) = 4 x 1.25 x 1.5 = 5 to 7.5 hours
  126. 126. regularly review the backlog toensurerelevance
  127. 127. evanleybourn evan@theagiledirector.com questions???
  128. 128. lean,agile&kanbanforsoftware part 5: continuous delivery
  129. 129. plan, design & estimatetasks technicalspecifications
  130. 130. get highestpriority feature allowdeveloperstochoosetheirtasks
  131. 131. test–driven development
  132. 132. testcoverage functions,boundary cases,user interface & performance
  133. 133. testtypes defect, usability,functionality & data
  134. 134. pair programming: coder + reviewer build
  135. 135. code standards: a common coding style build
  136. 136. system metaphor: clear naming standards build
  137. 137. regular commits versioncontrol
  138. 138. continuous build, testing & release continuousintegration
  139. 139. 5s:seiri/sort organise & clean the work area
  140. 140. 5s:seiton/setinorder arrange for easy identification and accessibility
  141. 141. 5s:seiso/shine regular maintenanceof the work area
  142. 142. 5s:seiketsu/standardise a consistent approach to development
  143. 143. 5s:shitsuke/sustain a commitment to maintain the previous 4s
  144. 144. what did you do yesterday? dailystand-up
  145. 145. what will you do today? dailystand-up
  146. 146. are there any issues? dailystand-up
  147. 147. summary stand-up forlargeteams
  148. 148. differsbyorganisation what does “done” mean?
  149. 149. definitionof“done” documentation? uat? built / compiled?
  150. 150. what does “not done” mean? theprimarymeasureofprogress
  151. 151. per story or at fixed intervals deploy
  152. 152. present & review completed work to the customer regularreview
  153. 153. evanleybourn evan@theagiledirector.com questions???
  154. 154. lean,agile&kanbanforsoftware part 6: kanban
  155. 155. kanban (かんばん) workflow monitoring & visualisation
  156. 156. can be as simple or complex as required theflowofvaluethroughthesystem
  157. 157. tasks with upstreamdependencies blocked
  158. 158. workinprogress limit concurrent work and promote workflow
  159. 159. “pull” all ready tasksto wip limit pull!!!
  160. 160. kanban:classofservice * expedite * fixed delivery * standard class * intangible class
  161. 161. identify&resolvebottlenecks through low wip limitsand strictprocess flow
  162. 162. productionlevelling constant rate of flow through all states
  163. 163. customers can alwayssee progress promotingtransparency
  164. 164. progressmonitoring cumulative flow statistical run
  165. 165. cycletime average time to complete a task from start
  166. 166. leadtime average time to complete a task from request
  167. 167. plot delivered functionalityagainst duration effortvisualisation
  168. 168. cumulative flow diagram
  169. 169. don'tmanagebynumbers identify problem trends early
  170. 170. bottleneck
  171. 171. poor flow
  172. 172. large wip
  173. 173. long lead time
  174. 174. plateau
  175. 175. plot cycle time against average durationvisualisation
  176. 176. cycle time run charts
  177. 177. don'tmanagebynumbers identify problem trends early
  178. 178. process trend
  179. 179. process shift
  180. 180. extreme process variation
  181. 181. evanleybourn evan@theagiledirector.com questions???
  182. 182. lean,agile&kanbanforsoftware part 8: kaizen (改善)
  183. 183. inspect & adapt continuousimprovement
  184. 184. what went well? retrospective/qualitycircle
  185. 185. addactionabletaskstothebacklog what could be improved?
  186. 186. kaizenemphasises teamwork, discipline & morale
  187. 187. 1. do not send defective products to the subsequent process 2. the subsequent process comes to withdraw only what is needed 3. produce only the exact quantity withdrawn by the subsequent process 4. equalise, or level, the production 5. kanban is a means to fine tuning 6. stabilize and rationalize the process
  188. 188. http://agilebusinessmanagement.o rg - Case Studies - Articles - Community Join our Agile Journey
  189. 189. To learn more, check out Directing the Agile Organisation by Evan Leybourn available at Amazon and all good book stores CLICK TO DISCOVER MORE

×