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.

Agile and Agile methods: what is the most important to understand to succeed

2,369 views

Published on

My presentation at Agile Tour 2010 Vilnius

Published in: Technology
  • Be the first to comment

Agile and Agile methods: what is the most important to understand to succeed

  1. 1. Agile and Agile methods: what is the most important to understand to succeed<br />Vaidas Adomauskas<br />
  2. 2. Disclaimer<br />This is just my opinion and interpretation of information<br />Use at your own risk ;)<br />Information and pictures from<br />Henrik Kniberg<br />Mary Poppendieck<br />Google<br />...<br />
  3. 3. Agenda (0)<br />Vaidas<br />
  4. 4. Agenda (1)<br />Agile<br />Agile<br />Agile<br />Agile<br />
  5. 5. Agenda (2)<br />Scrum<br />TDD<br />XP<br />Continuous Integration<br />Kanban<br />Refactoring<br />Pair programming<br />Lean<br />
  6. 6. Agenda (3)<br />
  7. 7. About me<br />
  8. 8. About me (1)<br />VU MIF – Software Engineering(bachelor)<br />IT University of Gothenburg – Master in Software Engineering and Management<br />Lavasoft(www.lavasoft.com )<br />Adform (www.adform.com)<br />
  9. 9. Apie mane (2)<br />Certified Scrum Master (Ken Schwaber, Paris)<br />Certified Product Owner (Robin Dymond ,Kiev)<br />Agile Conferences<br />http://scrum.agile.lt<br />Lecturer at VU MIF “Agile Project Management with Scrum”<br />
  10. 10. Magic word?<br />Traditional Process and Statistics<br />Agile<br />
  11. 11. Traditional SW projects are like a cannon ball<br />Assumptions:<br />The customer knows what he wants<br />The developers know how to build it<br />Nothing will change along the way<br />
  12. 12. We tend to build the wrong thing<br />This graph courtesy of Mary Poppendieck<br />The Biggest Opportunity to Increase Software Development Productivity is to Write Less Code!*<br />*Mary Poppiendieck, “It’s Not About Working Software”, Agileee 2010 conference<br />12<br />
  13. 13. Maybe we are successfull?<br />“The primary reason [for the improvement] is that projects have gotten a lot smaller.”<br />“Doing projects with iterative processes as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”<br />Jim Johnson<br />Chairman of<br />Standish Group <br />“There is no silver bullet but agile methods come very close”<br />Sources:<br />http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish<br />http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS<br />”My Life is Failure”, Jim Johnson’s book<br />13<br />
  14. 14. How about performance of Agile?<br />Source: Dr. Dobb’s Journal 2008 Agile Adoption Survey<br />
  15. 15. Who is using it?<br />
  16. 16. What about Lithuania?<br />?<br />
  17. 17. Magic word?<br />Early Software Engineering<br />Agile<br />
  18. 18. Avoid bugs (1972)<br />“Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with…<br /> … programmers… should not introduce the bugs to start with.”<br />Edsger W. Dijkstra, “The Humble Programmer”, 1972 (http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)<br />
  19. 19. The Life Cycle Concept (1976)<br />The biggest opportunity for cost reduction was finding errors as soon as possible:<br />Barry W. Boehm, “Software Engineering”, 1976 (http://www.computer.org/portal/web/csdl/doi/10.1109/TC.1976.1674590)<br />
  20. 20. Problem 1<br />Separation of design from implementation<br />Swartout and Balzer: “All current software methodologies have adopted a common model that separates specification from implementation. Unfortunately, this model is overly naïve, and does not match reality.”*<br />*Swartout and Balzer, “On the Inevitable Intertwining of Specification and Implementation”, 1982<br />
  21. 21. Problem 2<br />Large batchesof work (usually all project)<br />“Large batches of work tend to queue up during each process step, and so defects are not detected at the point of insertion; they have to wait to be uncovered in a batch validation step”<br />*Mary and Tom Poppiendieck, “Leading Lean Software development”, 2000<br />
  22. 22. Other opponents<br />McCracken and Jackson, “Life Cycle Concept Considered Harmful”, 1982<br />Tom Gilb, “Evolutionary Development”, 1981<br />Start with short measurable business goals<br />Incremental deliverables (real software, real value)<br />Toyota Way<br />Just In Time (JIT)<br />Lean<br />Agile<br />….<br />
  23. 23. Agile<br />Agile<br />Magic word?<br />Umbrella term<br />
  24. 24. Agile Manifesto<br />www.agilemanifesto.org <br />We are uncovering better ways of developing software by doing it and helping others do it. <br />Feb 11-13, 2001<br />Snowbird ski resort, Utah<br />Kent Beck<br />Mike Beedle<br />Arie van Bennekum<br />Alistair Cockburn<br />Ward Cunningham<br />Martin Fowler<br />James Grenning<br />Jim Highsmith<br />Andrew Hunt<br />Ron Jeffries<br />Jon Kern<br />Brian Marick<br />Robert C. Martin<br />Steve Mellor<br />Ken Schwaber<br />Jeff Sutherland<br />Dave Thomas<br />
  25. 25. Agile Manifesto (1)<br />...we value:<br />Individuals and interactions<br /> over processes and tools <br />http://agilemanifesto.org/<br />
  26. 26. Agile Manifesto (2)<br />...we value:<br />Working software over comprehensive documentation<br />http://agilemanifesto.org/<br />
  27. 27. Agile Manifesto (3)<br />...we value:<br />Customer collaboration over contract negotiation<br />http://agilemanifesto.org/<br />
  28. 28. Agile Manifesto (4)<br />...we value:<br />Responding to changeoverfollowing a plan<br />http://agilemanifesto.org/<br />
  29. 29. Agile projects are like a guided missile<br />Assumptions:<br />The customer discovers what he wants<br />The developers discover how to build it<br />Things change along the way<br />
  30. 30. Agile<br />Magic word?<br />Summary<br />Agile<br />
  31. 31. TDD<br />XP<br />Scrum<br />Kanban<br />Continuous Integration<br />Refactoring<br />Pair programming<br />Lean<br />What is all this stuff?<br />
  32. 32. What is all this stuff?<br />Practices<br />Methods<br />Agile<br />XP<br />Continuous Integration<br />TDD<br />Scrum<br />Lean<br />Pair programming<br />Refactoring<br />Kanban<br />...<br />...<br />
  33. 33. Do not mix with time line<br />Lean<br />Scrum<br />XP<br />Test Driven Development (TDD)<br />Pair programming<br />Continues integration<br />Refactoring<br />Planning poker<br />…<br />Agile<br />Kanban<br />…<br />Time<br />
  34. 34. What is wrong here?<br />Using the toolwrong<br />Using the wrong tool<br />Neither of these problems are caused by the tool!!!<br />
  35. 35. More prescriptive<br />More adaptive<br />Different tools<br />Scrum<br />(9)<br />Kanban<br />(3)<br />Do Whatever<br />(0)<br />XP<br />(13)<br />RUP<br />(120+)<br /><ul><li>Architecture Reviewer
  36. 36. Business Designer
  37. 37. Business-Model Reviewer
  38. 38. Business-Process Analyst
  39. 39. Capsule Designer
  40. 40. Change Control Manager
  41. 41. Code Reviewer
  42. 42. Configuration Manager
  43. 43. Course Developer
  44. 44. Database Designer
  45. 45. Deployment Manager
  46. 46. Design Reviewer
  47. 47. Designer
  48. 48. Graphic Artist
  49. 49. Implementer
  50. 50. Integrator
  51. 51. Process Engineer
  52. 52. Project Manager
  53. 53. Project Reviewer
  54. 54. Requirements Reviewer
  55. 55. Requirements Specifier
  56. 56. Software Architect
  57. 57. Stakeholder
  58. 58. System Administrator
  59. 59. System Analyst
  60. 60. Technical Writer
  61. 61. Test Analyst
  62. 62. Test Designer
  63. 63. Test Manager
  64. 64. Tester
  65. 65. Tool Specialist
  66. 66. User-Interface Designer
  67. 67. Architectural analysis
  68. 68. Assess Viability of architectural proof-of-concept
  69. 69. Capsule design
  70. 70. Class design
  71. 71. Construct architectural proof-of-concept
  72. 72. Database design
  73. 73. Describe distribution
  74. 74. Describe the run-time architecture
  75. 75. Design test packages and classes
  76. 76. Develop design guidelines
  77. 77. Develop programming guidelines
  78. 78. Identify design elements
  79. 79. Identify design mechanisms
  80. 80. Incorporate design elements
  81. 81. Prioritize use cases
  82. 82. Review the architecture
  83. 83. Review the design
  84. 84. Structure the implementation model
  85. 85. Subsystem design
  86. 86. Use-case analysis
  87. 87. Use-case design
  88. 88. Analysis model
  89. 89. Architectural proof-of-concept
  90. 90. Bill of materials
  91. 91. Business architecture document
  92. 92. Business case
  93. 93. Business glossary
  94. 94. Business modeling guidelines
  95. 95. Business object model
  96. 96. Business rules
  97. 97. Business use case
  98. 98. Business use case realization
  99. 99. Business use-case model
  100. 100. Business vision
  101. 101. Change request
  102. 102. Configuration audit findings
  103. 103. Configuration management plan
  104. 104. Data model
  105. 105. Deployment model
  106. 106. Deployment plan
  107. 107. Design guidelines
  108. 108. Design model
  109. 109. Development case
  110. 110. Development-organization assessment
  111. 111. End-user support mateirla
  112. 112. Glossary
  113. 113. Implementation model
  114. 114. Installation artifacts
  115. 115. Integration build plan
  116. 116. Issues list
  117. 117. Iteration assessment
  118. 118. Iteration plan
  119. 119. Manual styleguide
  120. 120. Programming guidelines
  121. 121. Quality assurance plan
  122. 122. Reference architecture
  123. 123. Release notes
  124. 124. Requirements attributes
  125. 125. Requirementsmanagement plan
  126. 126. Review record
  127. 127. Risk list
  128. 128. Risk management plan
  129. 129. Software architecturedocument
  130. 130. Software developmentplan
  131. 131. Software requirements specification
  132. 132. Stakeholder requests
  133. 133. Status assessment
  134. 134. Supplementary business specification
  135. 135. Supplementary specification
  136. 136. Target organization assessment
  137. 137. Test automation architecture
  138. 138. Test cases
  139. 139. Test environment configuration
  140. 140. Test evaluation summary
  141. 141. Test guidelines
  142. 142. Test ideas list
  143. 143. Test interface specification
  144. 144. Test plan
  145. 145. Test suite
  146. 146. Tool guidelines
  147. 147. Training materials
  148. 148. Use case model
  149. 149. Use case package
  150. 150. Use-case modeling guidelines
  151. 151. Use-case realization
  152. 152. Use-case storyboard
  153. 153. User-interface guidelines
  154. 154. User-interface prototype
  155. 155. Vision
  156. 156. Work order
  157. 157. Workload analysis model
  158. 158. Whole team
  159. 159. Coding standard
  160. 160. TDD
  161. 161. Collective ownership
  162. 162. Customer tests
  163. 163. Pair programming
  164. 164. Refactoring
  165. 165. Planning game
  166. 166. Continuous integration
  167. 167. Simple design
  168. 168. Sustainable pace
  169. 169. Metaphor
  170. 170. Small releases
  171. 171. Scrum Master
  172. 172. Product Owner
  173. 173. Team
  174. 174. Sprint planning meeting
  175. 175. Daily Scrum
  176. 176. Sprint review
  177. 177. Product backlogt
  178. 178. Sprint backlog
  179. 179. BUrndown chart
  180. 180. Visualize the workflow
  181. 181. Limit WIP
  182. 182. Measure and optimize lead time</li></ul>Which one is better?<br />Compare for understanding, not judgement!<br />
  183. 183. Agile<br />Practices<br />Methods<br />What is all this stuff?<br />Summary<br />
  184. 184. How to succeed?<br />
  185. 185. We are NOT “different”<br />
  186. 186. Respect People<br />
  187. 187. Right Toolbox<br />
  188. 188. Right Metrics<br />
  189. 189. External help<br />
  190. 190. Courage<br />
  191. 191. Start NOW<br />
  192. 192. Thank you!<br />Let’s Scrum!<br />v.adomauskas@gmail.com<br />http://scrum.agile.lt<br />Mob. Tel.: 860038860<br />Facebook, Skype, LinkedIn… <br />

×