A Managers Guide... Agile and Beyond 2015

A Managers Guide to Gaining an Appreciation for the Engineering Practices

Development engineering practices are many times misunderstood or completely ignored by the business. The business wants valuable features, faster and with few defects. I believe when the business and development understand each others practices... each party can delivery more business value... cheaper, faster, simpler. This presentation will be a fun journey allowing developers and business-types alike to come to a common understanding of why understanding each other is important.

Transcript

2. an appreciation a manager’s guide engineering to gaining practices for the
3. an appreciation a manager’s guide engineering to gaining practices for the dj daugherty dj@pillartechnology.com @ddaugher
5. we are hiring !
6. we are hiring !
7. developer. i am I create business solutions for business problems…
13. think.
14. question the norm.
15. i struggle with these ideas every day. disclosure
16. an appreciation a manager’s guide engineering to gaining practices for the
17. developers?
18. business?
19. engineering practices why?
20. engineering practices misunderstood why?
21. engineering practices completely ignored why? misunderstood
22. technology waits for no one.
23. opportunity
24. opportunity curse
25. technology as an engine product improvements cost reductions market expansion
26. disruption source of
27. robotic uprising
29. focus on business… valuable features …faster with fewer defects
32. who has worked on a project?
33. difficult to change.
34. cycles. long testing
35. defects. lots of
36. ship. difficult to
37. requirements. doesn’t meet
38. 0 how many are still standing?
40. learn faster from our mistakes
41. 0 enter the engineering practices
42. what is a practice?
46. what is a engineering practice?
49. enter the chartus praxis.
50. i made this up ! chartus praxis.
54. ease of change
55. ease of change cost of change
56. essential ? ~45 3 =
57. test driven development paired programming continuous integration
58. paired programming
59. what is paired programming?
63. more than two developers sitting together
64. more than just coding
65. instant QA reduction of defects communication team-building design learning confidence
66. instant QA reduction of defects communication team-building design learning confidence
67. instant QA reduction of defects communication team-building design learning confidence
68. instant QA reduction of defects communication team-building design learning confidence
69. instant QA reduction of defects communication team-building design learning confidence
70. instant QA reduction of defects communication team-building design learning confidence
71. instant QA reduction of defects communication team-building design learning confidence
72. what are the concerns? economics disengagement ‘watch the master’
73. expert - expert expert - novice novice - novice
74. pair on
76. test driven development
77. test driven development
78. test driven design
79. test driven ‘doing’
80. what is test driven development?
85. comparing desired to actual… this is TDD.
86. intent direction focus
87. answering the question… am i done?
88. not about testing about specification
89. specify the problem, very narrowly, very explicitly forces…
90. safety net.
91. test drive
93. continuous integration
94. what is continuous integration?
97. pair
98. reducing risk current state vs. dev state
99. unit tests complexity code smells
100. validating assumptions
101. reduce overhead automate everything
102. increase confidence
103. so…
104. three practices and a primary goal
105. test driven development paired programming continuous integration
106. test driven ‘doing’ paired programming continuous integration
107. test driven ‘doing’ paired ‘collaboration’ continuous integration
108. test driven ‘doing’ paired ‘collaboration’ continuous ‘feeback’
109. primary goal… valuable features …faster with fewer defects
110. noteasy.
112. just start!
113. just start! it will suck at first.
114. just start! it will suck at first. that’s ok.
115. just start! it will suck at first. have a ritual. that’s ok.
116. just start! it will suck at first. have a ritual. it is ok to fail. that’s ok.
117. just start! it will suck at first. have a ritual. it is ok to fail. beer helps! that’s ok.
118. just start! it will suck at first. have a ritual. it is ok to fail. beer helps! eventually it will suck less. that’s ok.
119. dj daugherty dj@pillartechnology.com @ddaugher thanks. an appreciation a manager’s guide engineering to gaining practices for the
120. dj daugherty dj@pillartechnology.com @ddaugher q&a. an appreciation a manager’s guide engineering to gaining practices for the https://speakerdeck.com/ddaugher