Deliberate Discovery - STAREAST

Modern software delivery involves the decomposition of a problem into packets of business and technical analysis, design, architecture, programming, testing, integration, deployment, documentation, and training. No matter how well-intentioned our iterative or sequential approach is to these activities, our success rate of software delivery is still far below what it should be. Advances in these disciplines haven’t reduced the unpleasant surprises that occur uncomfortably late in projects.

Dan North thinks it's because we are focusing on the wrong things, which means that any software delivery is merely a happy accident. He explains why ignorance is the greatest enemy to success, and presents some strategies and techniques for deliberately reducing ignorance, increasing learning, and moving toward a more deterministic and lower risk software delivery. We don’t like hearing bad news and will happily delude ourselves into thinking that things are better than they are. So this session probably isn’t for you—except that it is.

Transcript

1. Deliberate Discovery Dan North @tastapod
2. Imagine you got to redo your project... … 
 … - you knew then what you know now - you had 20/20 fore 
 
 Something is holding us back
3. Theory of Constraints There is currently a constraint Any inventory behind the constraint is waste Any time not addressing the constraint is waste But you don’t know where the constraint is!
4. Ignorance is the constraint Ignorance is multivariate You are ignorant (to some degree) about… - your domain - the nature of the problem - your incumbent technologies - other possible technologies - organisational constraints - relationships with stakeholders …and you don’t
5. Ignorance reduces in steps oh. Oh! Crap 
 
 So can we influence this
6. Can you prepare for the oh crap This time This time This time 
 
 
 This time will be just like all
7. Deliberate discovery 1. Assume you are always operating in second order 2. Assume some specific axis 3. Surface risk 
 
 
 Second-order ignorance is a given
8. We are wired to resist this We suffer with attribution bias We suffer with confirmation bias 
 
 
 
 
 …
9. Remember how the project started? You got everyone in a room You decomposed the problem into stories - and more stories - and more stories You estimated the stories - and estimated - and estimated Was that really the best use of your time?
10. So how can we apply this? Software has a half-life 
 Shorter half-life means less 2OI - less opportunity to not know what I don’t know 
 So why not rewrite rather than redevelop? - with multiple overlapping
11. Deliberate discovery in programming Spike-and-stabilise - Learn through evolving the “spike” - Stabilise later – test-driven testing Design for the second case - You might Travel in pairs - O
12. Deliberate discovery in testing Exploratory testing Randomised testing Not 
 
 
 Good testers already know this
13. Deliberate discovery in (dev)ops Get into production early - get anything Design for monitorability - push diagnostics rather than pulling an autopsy - make it easy to listen Design for discoverability - what went wrong? - what’s going wrong right now
14. Summary You don’t know what you don’t know That ignorance is killing your delivery Sometimes you can’t know what you don’t know 
 
 
 For everything else, there’s Deliberate Discovery
15. Thank you dan@dannorth.net http://dannorth.net @tastapod