Over the past couple of years we've migrated from a traditional, waterfall development process to more of an iterative one. At the same time we've moved from structured to object oriented programming languages. These are big transitions and we are proud to say that we've released our first .NET product built on an object oriented framework. We have recently adopted the Lean Start-up Process first introduced by Eric Ries. This is a presentation I gave at our customer advisory board meeting that was adapted from Eric's presentation found here: http://www.slideshare.net/startuplessonslearned/eric-ries-lean-startup-presentation-for-web-20-expo-april-1-2009-a-disciplined-approach-to-imagining-designing-and-building-new-products Find us at http://exumatech.com or @ExumaTech

1. ExumaTech
Development
Process

2. Traditional Product Development
Problem: Solution:
Known Known

3. Common Misconceptions
• We know what customers
want (Problem)
• We know how to solve it
(Solution)
• Advancement is progress

4. Traditional Product Development
Problem: Solution:
Known Known

5. Commercial Software Reality
• Problem = Known
• Problem = Hypothesis
• Solution = Hypothesis
• Solution = Unknown

6. • Do customers recognize they
have the need?
• If there was a solution, would
they buy it?
• Would they buy it from us?
• Can we build it?

7. Minimize TOTAL time through the loop

8. Validated Learning

9. Code Faster:
Continuous
Deployment

10. Continuous Deployment
• Deploy new software to Q/A quickly:
Measure last check-in to Q/A
deployment
• Break large projects into small batches
• Tell a good change from a bad change
(quickly) and…
• Revert a bad change quickly

11. Envelope Stuffing
Your job is to stuff 5 envelopes and stamp them.
What’s faster?
1. Folding all five sheets, then stuffing, then licking,
then stamping?
2. Doing each envelope one at a time?

12. Measure Faster:
Customer
Validation

13. Customer Validation
• Indentify product champion or liaison
• Validate hypothesis through customer
use and interaction
• Measure response across a sample set

14. Learn Faster:
5 Whys Root
Cause
Analysis

15. 5 Whys Root Cause Analysis
• A technique for continuous improvement
of company processes
• Ask “why” five times when something
unexpected happens
• Behind every supposed technical
problem is a human problem

16. 5 Whys Example
1. A new release broke a key feature for customers.
Why? Because a particular server failed.
2. Why did the server fail? Because an obscure
subsystem was used in the wrong way.
3. Why was it used in the wrong way? The engineer who
used it didn't know how to use it properly.
4. Why didn't he know? Because he was never trained.
5. Why wasn't he trained? Because his manager doesn't
believe in training new engineers, because they are
"too busy."

17. Cam Collins
cam@exumatech.com
http://exumatech.com
@CamCollins (Twitter)