Are you ready to build an MVP? Where do you start? How do you know what features to build? How do you know how many people you need to build it? How do you know that they are building a right thing in a right way? This presentation and conversation will explore strategies for assembling effective teams for building and deploying an MVP while incurring minimal Product and Technical Debt. We will also discuss implementing an effective process to make sure that your MVP will be built on time and on target.
6. Ideal MVP
Mini-Me is an Ideal MVP
Core Functionality
Identical “DNA”
Same Major Features
Same Major Functionality
Same Usability
Not Up To Scale
Not As Pretty
6
7. 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.”
Minimal
Product nobody
wants to use
Viable
Product built
by companies
that have no
financial limitations
MVP
8. 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
11. 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
13. 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
17. 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
20. Product Don’ts
Do Not Complicate Things
Do Not Make Users Think
Do Not Make Users Work
Do Not Defy User’s Expectations
Do Not Confuse Yourself With Users
Do Not Assume You Know Everything
20
33. 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
36. 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
37. 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
38. 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
42. 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
49. All The Wrong Reasons
49
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)
52. 90% Done Problem
52
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
54. Buddy Paring
54
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)
56. Offshore Team Picking
56
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)
61. Process Complication
Do Not Make It Complicated
Complicated = Bad
Complicated = Unsustainable
Complicated = Not Followed
Complicated = Edge Case Centric
Complicated ! = Useful
Complicated = Unintended Consequences
61
63. Planned vs. Agile
Planned Process
Exhaustive Planning (plan until you are exhausted)
Prescriptive
Document Centric
Agile Process
Iterative Planning
Non-prescriptive
Practice Centric
63
66. 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
68. You Are Not Agile If
Requirement Frontloading
QA Backloading
You Move Dates Instead of Feature Negotiating
You Extend Sprints/Iterations
You Are Not Producing Code by Third Week of the
Project
You Have No Business Representation
You Are Not Tracking Requirements
You Do Not Keep Track of Velocity/Drumbeat
68
71. 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