My presentation at Agile Tour 2010 Vilnius

1. Agile and Agile methods: what is the most important to understand to succeed Vaidas Adomauskas

2. Disclaimer This is just my opinion and interpretation of information Use at your own risk ;) Information and pictures from Henrik Kniberg Mary Poppendieck Google ...

3. Agenda (0) Vaidas

4. Agenda (1) Agile Agile Agile Agile

5. Agenda (2) Scrum TDD XP Continuous Integration Kanban Refactoring Pair programming Lean

6. Agenda (3)

7. About me

8. About me (1) VU MIF – Software Engineering(bachelor) IT University of Gothenburg – Master in Software Engineering and Management Lavasoft(www.lavasoft.com ) Adform (www.adform.com)

9. Apie mane (2) Certified Scrum Master (Ken Schwaber, Paris) Certified Product Owner (Robin Dymond ,Kiev) Agile Conferences http://scrum.agile.lt Lecturer at VU MIF “Agile Project Management with Scrum”

10. Magic word? Traditional Process and Statistics Agile

11. Traditional SW projects are like a cannon ball Assumptions: The customer knows what he wants The developers know how to build it Nothing will change along the way

12. We tend to build the wrong thing This graph courtesy of Mary Poppendieck The Biggest Opportunity to Increase Software Development Productivity is to Write Less Code!* *Mary Poppiendieck, “It’s Not About Working Software”, Agileee 2010 conference 12

13. Maybe we are successfull? “The primary reason [for the improvement] is that projects have gotten a lot smaller.” “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.” Jim Johnson Chairman of Standish Group “There is no silver bullet but agile methods come very close” Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS ”My Life is Failure”, Jim Johnson’s book 13

14. How about performance of Agile? Source: Dr. Dobb’s Journal 2008 Agile Adoption Survey

15. Who is using it?

16. What about Lithuania? ?

17. Magic word? Early Software Engineering Agile

18. Avoid bugs (1972) “Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with… … programmers… should not introduce the bugs to start with.” Edsger W. Dijkstra, “The Humble Programmer”, 1972 (http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)

19. The Life Cycle Concept (1976) The biggest opportunity for cost reduction was finding errors as soon as possible: Barry W. Boehm, “Software Engineering”, 1976 (http://www.computer.org/portal/web/csdl/doi/10.1109/TC.1976.1674590)

20. Problem 1 Separation of design from implementation 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.”* *Swartout and Balzer, “On the Inevitable Intertwining of Specification and Implementation”, 1982

21. Problem 2 Large batchesof work (usually all project) “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” *Mary and Tom Poppiendieck, “Leading Lean Software development”, 2000

22. Other opponents McCracken and Jackson, “Life Cycle Concept Considered Harmful”, 1982 Tom Gilb, “Evolutionary Development”, 1981 Start with short measurable business goals Incremental deliverables (real software, real value) Toyota Way Just In Time (JIT) Lean Agile ….

23. Agile Agile Magic word? Umbrella term

24. Agile Manifesto www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Feb 11-13, 2001 Snowbird ski resort, Utah Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

25. Agile Manifesto (1) ...we value: Individuals and interactions over processes and tools http://agilemanifesto.org/

26. Agile Manifesto (2) ...we value: Working software over comprehensive documentation http://agilemanifesto.org/

27. Agile Manifesto (3) ...we value: Customer collaboration over contract negotiation http://agilemanifesto.org/

28. Agile Manifesto (4) ...we value: Responding to changeoverfollowing a plan http://agilemanifesto.org/

29. Agile projects are like a guided missile Assumptions: The customer discovers what he wants The developers discover how to build it Things change along the way

30. Agile Magic word? Summary Agile

31. TDD XP Scrum Kanban Continuous Integration Refactoring Pair programming Lean What is all this stuff?

32. What is all this stuff? Practices Methods Agile XP Continuous Integration TDD Scrum Lean Pair programming Refactoring Kanban ... ...

33. Do not mix with time line Lean Scrum XP Test Driven Development (TDD) Pair programming Continues integration Refactoring Planning poker … Agile Kanban … Time

34. What is wrong here? Using the toolwrong Using the wrong tool Neither of these problems are caused by the tool!!!

36. Business Designer

37. Business-Model Reviewer

38. Business-Process Analyst

39. Capsule Designer

40. Change Control Manager

41. Code Reviewer

42. Configuration Manager

43. Course Developer

44. Database Designer

45. Deployment Manager

46. Design Reviewer

47. Designer

48. Graphic Artist

49. Implementer

50. Integrator

51. Process Engineer

52. Project Manager

53. Project Reviewer

54. Requirements Reviewer

55. Requirements Specifier

56. Software Architect

57. Stakeholder

58. System Administrator

59. System Analyst

60. Technical Writer

61. Test Analyst

62. Test Designer

63. Test Manager

64. Tester

65. Tool Specialist

66. User-Interface Designer

67. Architectural analysis

68. Assess Viability of architectural proof-of-concept

69. Capsule design

70. Class design

71. Construct architectural proof-of-concept

72. Database design

73. Describe distribution

74. Describe the run-time architecture

75. Design test packages and classes

76. Develop design guidelines

77. Develop programming guidelines

78. Identify design elements

79. Identify design mechanisms

80. Incorporate design elements

81. Prioritize use cases

82. Review the architecture

83. Review the design

84. Structure the implementation model

85. Subsystem design

86. Use-case analysis

87. Use-case design

88. Analysis model

89. Architectural proof-of-concept

90. Bill of materials

91. Business architecture document

92. Business case

93. Business glossary

94. Business modeling guidelines

95. Business object model

96. Business rules

97. Business use case

98. Business use case realization

99. Business use-case model

100. Business vision

101. Change request

102. Configuration audit findings

103. Configuration management plan

104. Data model

105. Deployment model

106. Deployment plan

107. Design guidelines

108. Design model

109. Development case

110. Development-organization assessment

111. End-user support mateirla

112. Glossary

113. Implementation model

114. Installation artifacts

115. Integration build plan

116. Issues list

117. Iteration assessment

118. Iteration plan

119. Manual styleguide

120. Programming guidelines

121. Quality assurance plan

122. Reference architecture

123. Release notes

124. Requirements attributes

125. Requirementsmanagement plan

126. Review record

127. Risk list

128. Risk management plan

129. Software architecturedocument

130. Software developmentplan

131. Software requirements specification

132. Stakeholder requests

133. Status assessment

134. Supplementary business specification

135. Supplementary specification

136. Target organization assessment

137. Test automation architecture

138. Test cases

139. Test environment configuration

140. Test evaluation summary

141. Test guidelines

142. Test ideas list

143. Test interface specification

144. Test plan

145. Test suite

146. Tool guidelines

147. Training materials

148. Use case model

149. Use case package

150. Use-case modeling guidelines

151. Use-case realization

152. Use-case storyboard

153. User-interface guidelines

154. User-interface prototype

155. Vision

156. Work order

157. Workload analysis model

158. Whole team

159. Coding standard

160. TDD

161. Collective ownership

162. Customer tests

163. Pair programming

164. Refactoring

165. Planning game

166. Continuous integration

167. Simple design

168. Sustainable pace

169. Metaphor

170. Small releases

171. Scrum Master

172. Product Owner

173. Team

174. Sprint planning meeting

175. Daily Scrum

176. Sprint review

177. Product backlogt

178. Sprint backlog

179. BUrndown chart

180. Visualize the workflow

181. Limit WIP

182. Measure and optimize lead timeWhich one is better? Compare for understanding, not judgement!

183. Agile Practices Methods What is all this stuff? Summary

184. How to succeed?

185. We are NOT “different”

186. Respect People

187. Right Toolbox

188. Right Metrics

189. External help

190. Courage

191. Start NOW

192. Thank you! Let’s Scrum! v.adomauskas@gmail.com http://scrum.agile.lt Mob. Tel.: 860038860 Facebook, Skype, LinkedIn…