Agile and Agile methods: what is the most important to understand to succeed<br />Vaidas Adomauskas<br />
Disclaimer<br />This is just my opinion and interpretation of information<br />Use at your own risk ;)<br />Information an...
Agenda (0)<br />Vaidas<br />
Agenda (1)<br />Agile<br />Agile<br />Agile<br />Agile<br />
Agenda (2)<br />Scrum<br />TDD<br />XP<br />Continuous Integration<br />Kanban<br />Refactoring<br />Pair programming<br /...
Agenda (3)<br />
About me<br />
About me (1)<br />VU MIF – Software Engineering(bachelor)<br />IT University of Gothenburg – Master in Software Engineerin...
Apie mane (2)<br />Certified Scrum Master (Ken Schwaber, Paris)<br />Certified Product Owner (Robin Dymond ,Kiev)<br />Agi...
Magic word?<br />Traditional Process and Statistics<br />Agile<br />
Traditional SW projects are like a cannon ball<br />Assumptions:<br />The customer knows what he wants<br />The developers...
We tend to build the wrong thing<br />This graph courtesy of Mary Poppendieck<br />The Biggest Opportunity to Increase Sof...
Maybe we are successfull?<br />“The primary reason [for the improvement] is that projects have gotten a lot smaller.”<br /...
How about performance of Agile?<br />Source: Dr. Dobb’s Journal 2008 Agile Adoption Survey<br />
Who is using it?<br />
What about Lithuania?<br />?<br />
Magic word?<br />Early Software Engineering<br />Agile<br />
Avoid bugs (1972)<br />“Those who want really reliable software will discover that they must find means of avoiding the ma...
The Life Cycle Concept (1976)<br />The biggest opportunity for cost reduction was finding errors as soon as possible:<br /...
Problem 1<br />Separation of design from implementation<br />Swartout and Balzer: “All current software methodologies have...
Problem 2<br />Large batchesof work (usually all project)<br />“Large batches of work tend to queue up during each process...
Other opponents<br />McCracken and Jackson, “Life Cycle Concept Considered Harmful”, 1982<br />Tom Gilb, “Evolutionary Dev...
Agile<br />Agile<br />Magic word?<br />Umbrella term<br />
Agile Manifesto<br />www.agilemanifesto.org <br />We are uncovering better ways of developing software by doing it and hel...
Agile Manifesto (1)<br />...we value:<br />Individuals and interactions<br /> over processes and tools <br />http://agilem...
Agile Manifesto (2)<br />...we value:<br />Working software over comprehensive documentation<br />http://agilemanifesto.or...
Agile Manifesto (3)<br />...we value:<br />Customer collaboration over contract negotiation<br />http://agilemanifesto.org...
Agile Manifesto (4)<br />...we value:<br />Responding to changeoverfollowing a plan<br />http://agilemanifesto.org/<br />
Agile projects are like a guided missile<br />Assumptions:<br />The customer discovers what he wants<br />The developers d...
Agile<br />Magic word?<br />Summary<br />Agile<br />
TDD<br />XP<br />Scrum<br />Kanban<br />Continuous Integration<br />Refactoring<br />Pair programming<br />Lean<br />What ...
What is all this stuff?<br />Practices<br />Methods<br />Agile<br />XP<br />Continuous Integration<br />TDD<br />Scrum<br ...
Do not mix with time line<br />Lean<br />Scrum<br />XP<br />Test Driven Development (TDD)<br />Pair programming<br />Conti...
What is wrong here?<br />Using the toolwrong<br />Using the wrong tool<br />Neither of these problems are caused by the to...
More prescriptive<br />More adaptive<br />Different tools<br />Scrum<br />(9)<br />Kanban<br />(3)<br />Do Whatever<br />(...
Business Designer
Business-Model Reviewer
Business-Process Analyst
Capsule Designer
Change Control Manager
Code Reviewer
Configuration Manager
Course Developer
Database Designer
Deployment Manager
Upcoming SlideShare
Loading in...5
×

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

1,895

Published on

My presentation at Agile Tour 2010 Vilnius

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,895
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
79
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Goal to put to shelves, not to explain!!!
  • I agila projekt försöka man slippa undan commitmentsEn sprint i taget bara
  • Definition of Done
  • Never blame the tool!
  • Adform – we did it and we are Lithuanians!
  • Cousin story
  • It is not just simple Scrum rules or iterations
  • Define the goal, and measure against it!
  • Transcript of "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 />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×