Agile Project Management for Embedded Dev. (or Burning Your Gantt Charts)

Traditional embedded project management usually hinges on eliminating change and designing out uncertainty up-front; such an approach is fantasy. Agile Project Management offers solutions to common, persistent problems: poor estimates, slipped timelines, products languishing in an almost-done state, and Gantt charts rarely reflecting reality. Here we discuss: usable definitions of “customer”, “feature” and “done”; prioritization; iterations; estimation; burndown charts; documentation; and risk & scope management.

Transcript

1. Agile Project Management (or Burning Your Gantt Charts) ESC-267 Michael Karlesky & Mark VanderVoord
2. The Zen Of “Done”
3. 3 Things
4. 1. Define Done
5. 2. Feature Done
6. 3. Project Done
7. Define “Done”
8. Done | dәn | adjective. 1. The code has been written according to the developers' interpretation of the spec (delivered 9 months ago). It can now be tested.
9. Done | dәn | adjective. 1. The code has been written but may require an unspecified amount of “cleanup” before shipping.
10. Done | dәn | adjective. 1. It works on a developer's machine.
11. Done | dәn | adjective. 1. Gantt chart progress has reached 100% 2. (more often) Gantt chart progress has reached 95% introducing a secondary state: “almost done”
12. Done | dәn | adjective. 1. The developers have stepped through the code with the debugger.
13. Done | dәn | adjective. 1. The debug build runs.
14. Done | dәn | adjective. 1. The state immediately preceding “done done”
16. Done | dәn | adjective. 1. A Zen-like continuation where the mind is at peace and the soul is at one with code, coworker, contractor, and customer alike
17. Done | dәn | adjective. 1. A Zen-like continuation where the mind is at peace and the soul is at one with code, coworker, contractor, and customer alike
18. Done | dәn | adjective. 1. A Zen-like state wherein all customer-specified features have been implemented to glowing accolades
19. Done | dәn | adjective. 1. A Zen-like state wherein all customer-specified features have been implemented to glowing accolades
20. Done | dәn | adjective. 1. A Zen-like state wherein all customer-specified features pass a vast (comprehensive) suite of unit, system, and acceptance tests
21. Done | dәn | adjective. 1. A Zen-like state wherein all customer-specified features pass a vast (comprehensive) suite of unit, system, and acceptance tests
22. Done | dәn | adjective. 1. A Zen-like state wherein (a) all customer-specified features pass unit, system, and acceptance tests (b) ...
23. Done | dәn | adjective. 1. A Zen-like state wherein (a) ... (b) It works on more than just my machine
24. Done | dәn | adjective. 1. A Zen-like state wherein (a) ... (b) It works on more than just my machine
25. Done | dәn | adjective. 1. A Zen-like state wherein (a) ... (b) builds are reproducible, identical, and machine independent
26. Done | dәn | adjective. 1. A Zen-like state wherein (a) all customer-specified features pass unit, system, and acceptance tests (b) builds are reproducible, identical, and machine independent
27. Define “Feature Done”
28. Feature?
29. Feature | ˈfē ch ər | noun. 1. Something that a customer can actually define in a concrete way, crossing that mystical gap between geek and non-geek.
30. Feature | ˈfē ch ər | noun. 1. Something that a customer can actually define in a concrete way, crossing that mystical gap between geek and non-geek.
31. Feature | ˈfē ch ər | noun. 1. Something that a customer (a) can explain (b) can know when it has been done correctly and is properly Awesome
32. Feature | ˈfē ch ər | noun. 1. Something that a customer (a) can explain (b) can know when it has been done correctly and is properly Awesome
33. Feature | ˈfē ch ər | noun. 1. Something that a customer (a) can explain (b) can verify
34. Feature | ˈfē ch ər | noun. 1. Something that a customer (a) can explain (b) can verify (c) feels is worth some kind of money or compensation to develop
35. Feature | ˈfē ch ər | noun. 1. Something that a customer (a) can explain (b) can verify (c) feels is worth some kind of money or compensation to develop
36. Feature | ˈfē ch ər | noun. 1. Something that a customer (a) can explain (b) can verify (c) will pay for
37. Customer?
38. Customer noun. synonyms: 1. End User
39. Customer noun. synonyms: 1. End User 2. Engineering Department
40. Customer noun. synonyms: 1. End User 2. Engineering Department 3. Marketing
41. Customer noun. synonyms: 1. End User 2. Engineering Department 3. Marketing 4. Sales
42. Customer noun. synonyms: 1. End User 2. Engineering Department 3. Marketing 4. Sales 5. Production
43. Customer noun. synonyms: 1. End User 2. Engineering Department 3. Marketing 4. Sales 5. Production 6. Technical Support
44. Since We Understand Feature
45. Now For A Round Of “Is That A Feature?”
46. ? SPI Interface Driver
47. ? Application should calculate and display the air-speed velocity of an unladen swallow
48. ? Application Should Initialize ADC as Pulse Convert Mode
49. ? Application Should Filter Results Before Display
50. ? Application Should Look Awesome
51. ? Application Should Blink A Warning Light Before It Crashes
52. We Know Features
53. So When Is The Feature Done?
54. Done | dәn | adjective. 1. A Zen-like state wherein (a) all customer-specified features pass unit, system, and acceptance tests (b) builds are reproducible, identical, and machine independent
55. unit, system, acceptance
56. unit, system, acceptance prove pieces of code work
57. unit, system, acceptance prove the release build works
58. unit, system, acceptance proves to customer the features work
59. development team
60. now also develops tests
61. strangely
62. does NOT
63. take more time
64. does NOT
65. make the project more complex
66. plus
67. encourages good design
68. encourages modular code
69. and
70. (obviously?)
71. promotes TESTABLE code
72. when all tests
74. we know those features
75. DONE
76. Done For Good?
77. Yes!
78. Continuous Integration
79. Every Time
80. Add A Feature
81. Every Time
82. Fix A Bug
83. Every Time
84. We Change Anything
85. ALL TESTS
86. Re-run
87. Re-validated
88. Re-verified
89. But We Can't Work On Features Until There Is Infrastructure Right?
90. Wrong
91. “Simplest Thing That Works”
92. Then
93. Refactor As Needed
94. You Can't Guess
95. Exactly
96. How All Modules Will Be Used
97. Quite Likely
98. “You Ain't Gonna Need It”
99. When You're Wrong
100. Spend More Time Changing
101. Than Writing
102. But You Skipped The Step Where We Wrote A System Design Specification!
103. Wrong
104. Develop Documentation
105. Like Software
106. Collaborative
107. Fast
108. Unobtrusive
109. Get the Customers Involved
110. Don't Let It Feel Rigid
111. Don't Let It Get Stale
112. Always Evolving
113. Accurate
114. wiki
115. That's Feature Done
116. Define “Project Done”
117. Project Done | präjˌekt dәn | noun.
118. Project Done | präjˌekt dәn | noun. 1. A Zen-like state wherein (a) all customer-specified features pass unit, system, and acceptance tests (b) builds are reproducible, identical, and machine independent
119. anti-climactic?
120. really want to know
121. WHEN
122. Project Done
123. Let's Start With
124. Estimation
125. All Features Given Points
126. Points are NOT Hours
127. Points are Complexity
128. If Feature 1
129. 2x
130. Feature 2
131. Then
132. 2x
133. Points
134. Humans Better At Estimating Complexity Than Time
135. Estimating Points
136. Factors Out
137. Overhead
138. Overhead Meetings
139. Overhead Documenting Meetings
140. Overhead Documenting Meetings Requirement Gathering
141. Overhead Documenting Meetings Requirement Gathering Coffee Breaks
142. Overhead Documenting Meetings Requirement Gathering Coffee Breaks Phone Calls
143. Overhead Documenting Meetings Hear Ryan's Joke Requirement Gathering Coffee Breaks Phone Calls
144. Overhead Documenting Meetings Hear Ryan's Joke Requirement Gathering Coffee Breaks e-mail Phone Calls
145. Overhead Documenting Meetings Hear Ryan's Joke Requirement Gathering Coffee Breaks e-mail YouTube Phone Calls
146. Overhead Documenting Meetings Hear Ryan's Joke Requirement Gathering Coffee Breaks e-mail YouTube Phone Calls less-than-productive time
147. Because The Truth Is Documenting Meetings Hear Ryan's Joke Requirement Gathering Coffee Breaks e-mail YouTube Phone Calls less-than-productive time
148. No One Is Productive 100% Of Their Time
149. Points
150. Estimate
151. Net Progress
152. So How Do We Assign Points?
153. Planning Poker
154. Step 1
155. As A Group
156. Choose a Medium-Size Feature
157. Call it 5
158. Everyone Has Deck of Cards
159. Numbered 1-10
160. (Or 1-2-3-5-8-13)
161. For Each Feature
162. Quickly Discuss It
163. Then, Everyone Chooses a Card
164. (But Does Not Show It)
165. Everyone Reveals
166. If Points are Close
167. (within a card)
168. Use the Highest Value
169. Otherwise
170. Re-Discuss
171. (there's a difference in view)
172. (what the feature is)
173. (the risks involved)
174. (or what's unknown)
175. After Discussion
176. Re-Select Cards
177. Repeat Until You Agree
178. Repeat Until All Features Estimated
179. That's It? What about Features we don't understand yet, or high risk Features?
180. Good Point
181. Higher Risk Features
182. Get Higher Points
183. Lack of Definition
184. Gets Higher Points
185. Some of Those Unkowns
186. Will be Easy
187. Some will be Scary
188. In Fact,
189. Normal Features
190. Will be Easier / Harder
191. Than Estimated
192. But That's OK
193. (we'll see why in a moment)
194. Now For A Round Of “How Many Points?”
195. Our Features: 1. Return Version Message via serial port when requested. 2. Measure Filtered Battery Voltage and Return 1/sec 3. Estimate Battery Life Remaining and Return 1/sec 4. Blink Red LED when Battery Is Too Low 5. Send Out LOW Message once when Battery Too Low
196. So Now What?
197. It's Time For Fancy Math
198. We Sum The Points
199. As We Work
200. Track Points From “Features Done”
201. At Regular Intervals
202. (Iterations)
204. Burn-Down Chart
206. VELOCITY
207. Variations in Points Completed
208. Per Iteration
209. Average Out
210. We Use Points Completed
211. In Last Iteration
212. (or Average of Last Few)
213. Calculate Velocity
214. (Points / Iteration)
215. Use Velocity
216. From Points Remaining
217. To Predict “Project Done”
219. I'm Sorry That End Date Is Not Acceptable.
220. We Have Options
221. We're Tracking Velocity
222. We Know Effect Of Adding People
223. We Know Effect Of Dropping or Modifying Features
224. We Can Estimate Effect Of Buy/Build Decisions
225. Huh?
226. Feature Sets Change
227. New Features Are Requested
228. Features Were Forgotten During Estimation
229. Priorities Change
230. Each Time
231. We Add / Remove
232. Points to Total Points
233. Points Remaining
234. Giving Us Updated Estimates
235. Automatic History
237. De-Featuring / Feature Redesign
238. Scope Creep
239. “Project Done”
240. What About Adding People?
241. 4 people 5 people
242. Be Careful
243. 6 people
244. 6 people
245. Because of This
246. Often Add Another Graph
247. Track Velocity
248. Now For A Round Of “What Happened?”
249. Where Did We Add Features?
250. What Was Our Initial Estimate?
251. What Was Velocity At Iteration 4?
252. Where Did We De-Feature?
253. What Was Our Final Total?
254. Where Was A Velocity Jump?
255. Where Were We Done?
256. So We Just Work Through Points Until We're Done?
257. Almost
258. The Order Is Important
259. How Do We Set Priority?
260. Every Iteration
261. Work With Customer
262. Prioritize
263. Most Important Features First
264. Highest Risk First
265. Greatest Unknowns First
266. (Helps Flush Out Definition)
267. Plus a Bonus
268. Stop When You Want
269. If Customer Happy
270. Current Feature Set
271. All Tests Pass
272. Then Ship It
273. Why Wait For Low-Priority Features?
274. Ship Now.
275. Make Money.
276. Find Out What Customer Wants
277. And Add Those Features
278. Iterations
279. We've Seen
280. Iterations
281. Help
282. To Regularly Adjust Priorities
283. To Accurately Track Progress
284. They Also
285. Serve As Mini-Milestones
286. Or Mini-Releases
287. How Long Is An Iteration?
288. Usually
289. 1 or 2 weeks
290. 1 Week
291. Faster Feedback
292. More Flexible
293. 2 Week
294. Coarse Grained Features
295. More Interdependencies With Other Disciplines
296. Pick What Sounds Right
297. You Can Always Change
298. 1 ὎ 2 Sum Pairs Of Past Iterations
299. 2 ὎ 1 Split Past Iterations Into Halves
300. What Happens When We Reach The End Of An Iteration... With Incomplete Features?
301. All Incomplete Features
302. Count As 0 Points
303. If
304. Still High Priority
305. Work On It Next Iteration
306. Points Will Average Out
307. How Do We Know How Much Work To Schedule For Next Iteration?
308. “Yesterday's Weather”
309. We Assume Our Velocity
310. Will Be Our Recent Velocity
311. Then
312. Work With Customer
313. Highest Priority Features
314. Fit In As Many As We Can
315. Some Teams
316. Use Visual Reinforcement
317. Sheets of Paper
318. Size Proportional To Points
319. Large Sheet Of Paper
320. Size Proportional to Velocity
321. Then Fit Features Into Iteration
322. Intuitive
323. Visual (For Visual People)
324. So Is That It?
325. Let's See
326. We Know
327. Meaning of Done
328. We Know
329. How To Estimate The Complexity Of Features
330. We Know
331. When Features Are Done
332. We Know
333. How Quickly We Get Features Done
334. We Know
335. When Project Should Be Done
336. We Know
337. What Our Options Are To Change When It's Done
338. We Know
339. The Success Of Those Changes
340. We Know
341. To Make Constant Corrections
342. so
343. Yeah.
344. We're
345. Done.
346. This Presentation is Licensed Under a Creative Commons 3.0 Attribution, Share-Alike License. You may use all or part of this presentation for whatever you want, as long as you (1) credit Michael Karlesky and Mark VanderVoord (2) release any derived works under a similar license http://www.creativecommons.org/
347. Images By (thanks!): Beach Zen - Tanais Costa Rica Zen Garden – Scott Robinson Fire And Water – Paul Sapiano Zen Garden – Timothy Tak Mad Scientist - Zoomar Momento Zen – Silke Gerstenkorn Zen – Pierangelo Rosati Carnival Cruise – Josh Bousel