SERGEY SUNDUKOVSKIY PH.D.

Building Debt Free MVP1

Introduction2

Background3

Agenda

MVP ConsiderationsDebt AvoidanceTechnical DebtOrganizational DebtProcess DebtInfrastructure Debt

4

MVP Core Functionality

Ideal MVP

5

Ideal MVP

Mini-Me is an Ideal MVPCore Functionality

Identical “DNA” Same Major Features Same Major Functionality Same Usability Not Up To Scale Not As Pretty

6

Viable For What?7

Eric Ries defines MVP as “…that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

MinimalProduct nobody

wants to use

ViableProduct built

by companiesthat have no

financial limitations

MVP

Difficult Determinations

Prototype vs. MVP How Do I Distinguish?

MVP vs. Product At What Point Do I Stop?

Intent Matters You Will Get What You Are Aiming For

Do Not Make A Mermaid You Will Always Get a Wrong Half

8

Defining MVP9

Defining an MVP

MVP vs. Prototype

10

MVP vs. Prototype

MVP Test Product Viability Test Assumptions Test the Market Test Product Usability Get User Feedback

Prototype Demonstrate the Concept Convince Others That You Are Serious Get Seed Money

11

MVP vs. Prototype

Who Builds It?

12

MVP vs. Prototype

MVP Built by a Minimal Viable Team Evolutionary in Its Development

Prototype Built by One Guy Usually Throwaway in Its Development

13

Roger’s Adoption Curve

Who is MVP for?

14

MVP Targeting

Prototype Targets InnovatorsMVP Targets Early AdoptersEarly Adopter Groups

Educators Influencers Opinion Makers Social Connectors

15

MVP Features

Less Is Truly More

16

MVP Features

Intelligent Design and Evolutionary Concepts Aim For Adjacent Possible

Irreducible Complexity Can’t Take Anything Away Can’t Be Simpler

Most Efficient For What It Does Most Efficient Wins

17

Irreducible Complexity

Simplest Mousetrap

18

Path To Intent

Straightforward Path To Intent

19

Product Don’ts

Do Not Complicate ThingsDo Not Make Users ThinkDo Not Make Users WorkDo Not Defy User’s ExpectationsDo Not Confuse Yourself With UsersDo Not Assume You Know Everything

20

Survey Bias

People Say One Thing and Do Another

21

Crowdsourcing

Rise of the Crowds

22

Mechanical Turk

Microtasking Crowdsourcing Platform

23

Usability Study Setup (cont.)25

Usability Study Results26

Was not sure what to do

Usability Study Results28

Feedback

It Is All About Uncensored Feedback

29

Feedback (cont.)30

Usability Testing Tools31

Technical Debt

Things Slow Down

32

Debt

Everything you want to do “Later” is DEBT Let’s Document Later Let’s Test Later Let’s Architect Later Let’s Refactor Later

Debt Misconceptions All Debt is Bad No Debt is Great Taking on Debt Always Gets You There Faster

33

Debt (Leverageable)34

Debt Story

I Have not Seen Organs Like This

35

Common Story

CEOs Tale We Were Very Productive We Kicked Ass We Became Complacent I Fired Them All I Hired a New Team They Are Not Productive Either Must Have Chosen Wrong I Fired Them All SAVE ME

36

Common Story

CTOs Tale We Were Very Productive Through Debt Accumulation We Kicked Ass But Burned Out We Slowed Down Due to Debt We Got Fired New Team Got Hired It Does Not Know Where Skeletons Are Buried We Got Fired As Well I have Not Seem Organs Like These

37

Support to Innovation Ratio

You Are in the Support Business

38

Support(15%)

Innovation(85%)

Support(50%)

Innovation(50%)

Support(85%)

Innovation(15%)

Year 1

Year 2

Year 3

Broken Window Theory

One Broken Window Leads to Ruin

39

Broken Window Theory

Do Sweat the Small Stuff

40

Debt Tipping Point41

Product Death

Year 2

Year 1

Tipping Point

Technical Debt Elements

Technical Debt Elements Lack of Architectural Blueprint Lack of Unit Testing Lack of Integration Testing Lack of Code Reviews Lack of Starting Platform Lack of Starting Framework Lack of Technical Design Lack of Development Recipes

42

Decision Stack

Reverse Funnel

43

Frameworks44

Language Selection

Programming Language Is Irrelevant. It Only Matters in Terms of Resource and Starter Product Availability

45

Organizational Debt

You Can’t Outsource What You Do Not Understand

46

MVT47

Minimal Viable Team Designer/UX/UI (part-time) Mobile/HTML5/Javascript SysAdmin/DBA/DevOPS Lead Developer 2 Engineers

MVT = 5.5 peopleCan We Afford It?Who is My Product Guy?

Offshore Development

Do it for Right Reasons

48

All The Wrong Reasons49

Wrong Expectations Solution to Ignorance (outsourcing what you do not understand) It Will Be Cheaper (min 30% overhead) We Can Achieve Instant Scalability (it takes time to hire) Poaching Is not a Problem (no difference) We Can Minimize Office Distractions (hallway magic)

Right Reasons50

Right Expectations Somewhat Easier to Find Talent 24 h Dev/QA Cycle Improved Ramp Up/Ramp Down Cycles Specific Expertise

90% Done Problem

What Do They Mean by That?

51

90% Done Problem52

90 Done Offshore Team Did All the Work 90% of the Money is Spent No Business Documentation No Technical Documentation No Repeatable Process No Unit Tests Lead Developer Instead of CTO Performance Problems Right out of the Gate

Buddy Program

Do it Right

53

Buddy Paring54

Not Your Grandfather’s Pair Programming Get paired (your counterpart) Truman Show (my life on tv) 4 + 4 (overlap time + alone time) Joined work assignment (we are a unit) Circle of influence (product manager, project manager, qa,

development buddy)

Congruent Culture

Pick a Congruent Culture

55

Offshore Team Picking56

Congruent Culture (challenge authority)Working Hours Overlap (4+)Right Size (30+ large enough to have a bench)Right Size (100- small enough to care)Right Focus (we do everything)Do Not Let It Grow (micro-teams)

Team Structure

Big Rocks First

57

Separate Development Teams58

Rapid Development vs. Core

VS.

Process Debt

How Do They Know?

59

Process Complication

Do Not Make It Complicated

60

Process Complication

Do Not Make It Complicated Complicated = Bad Complicated = Unsustainable Complicated = Not Followed Complicated = Edge Case Centric Complicated ! = Useful Complicated = Unintended Consequences

61

Planned vs. Agile62

VS

Planned vs. Agile

Planned Process Exhaustive Planning (plan until you are exhausted) Prescriptive Document Centric

Agile Process Iterative Planning Non-prescriptive Practice Centric

63

Agile Umbrella64

Agile Process Phases65

Process Debt Elements

Process Debt Elements Lack of Articulated Process Lack of Process Documentation Lack of Repeatability Lack of Clear Process Identification Presence of Numerous Process Exceptions Process Busters

66

False Agile

Just Because You Call It Agile It Does Not Mean It Is

67

You Are Not Agile If

Requirement FrontloadingQA BackloadingYou Move Dates Instead of Feature NegotiatingYou Extend Sprints/IterationsYou Are Not Producing Code by Third Week of the

ProjectYou Have No Business RepresentationYou Are Not Tracking RequirementsYou Do Not Keep Track of Velocity/Drumbeat

68

Infrastructures Debt

Avoiding Infrastructure Debt

69

IaaS + PaaS

Use As Much of the Stack as You Can

70

Infrastructure Debt Elements

Infrastructure Debt Elements No Utilizing IaaS/Pass Lack of Monitoring Lack of Redundancy Lack of Disaster Recovery Lack of Environment Separation

Dev Ops Debt Elements Lack of Deployment Framework Lack of Continuous Integration Lack of Effective Source Control

71

PaaS 72

IaaS 73