Originate - Think In Hours Not Sprints
Upcoming SlideShare
Loading in...5
×
 

Originate - Think In Hours Not Sprints

on

  • 618 views

Why software will never be the same... Discuss why agile and lean development methodologies alone are not enough to compete in today's software startup market. Explore real-time prototyping and ...

Why software will never be the same... Discuss why agile and lean development methodologies alone are not enough to compete in today's software startup market. Explore real-time prototyping and minimal viable experiments that can accelerate learning down to hours, not sprints.

Statistics

Views

Total Views
618
Views on SlideShare
598
Embed Views
20

Actions

Likes
1
Downloads
5
Comments
0

1 Embed 20

https://twitter.com 20

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Originate - Think In Hours Not Sprints Originate - Think In Hours Not Sprints Presentation Transcript

  • THINK IN HOURS NOT SPRINTS WHY SOFTWARE WILL NEVER BE THE SAME 1 Rob Meadows CEO, Originate Oct 21, 2013
  • We partner with start-ups and enterprises to rapidly build high-quality modern software. 2
  • Quality Software is Essential to Almost Every Business “Software is eating the world” / Marc Andreessen “In 3 to 5 years, your car will have more lines of code in it than LinkedIn does today” / Reid Hoffman 3
  • Building Software Classic Problem: Cheap, Fast, Good. Pick 2. Fast + Cheap (but it doesn’t work) or Fast + Good (but you can’t afford it) or Cheap + Good (but you don’t live to see it) 4
  • Building Startup Software Most competitive market landscape ever for software startups. More technology options (noise) than ever for software startups. Must be cheaper, faster, and better to win. 5
  • Cheaper, Faster, AND Better Cloud + Open Source + Tools + Methodologies = It has never been cheaper or faster to build high-quality software 6
  • Cloud Software as a Service (SaaS) Leverage quality 3rd party applications faster and cheaper Salesforce, Google Apps, etc. Platform as a Service (PaaS) Deploy and scale applications faster and cheaper Heroku, Azure, Pivotal, etc. Infrastructure as a Service (IaaS) Provision servers, storage, and bandwidth faster and cheaper Amazon Web Services (AWS), Joyent, Rackspace, etc. 7
  • Open Source Frameworks Ruby/Rails, Scala/Play, Python/Django, etc. User Interface jQuery, Twitter Bootstrap, etc. Data/Analytics MySQL, MongoDB, Hadoop, etc. Utilities Security, integrations, testing, you name it… 8
  • Tools Advanced tools help save time + risk: Communication Create more efficient (faster), global (cheaper) workforce Skype, Hipchat, Webex, Pivotal Tracker, JIRA, Assembla Analytics Faster reaction to business needs with less risk Google Analytics, Mixpanel, New Relic UX/Prototyping Omnigraffle, Popapp, Invisionapp, FluidUI Dev/DevOps Git(hub), Xcode, continuous integration, code quality, monitoring 9
  • Cloud + Open Source + Tools So the odds must be in our favor now, right? 10
  • Odds of New Startup Success What is the success rate of software startups today? 11
  • Odds of New Startup Success <10% 12 Steve Blank “Startup Owner’s Manual”
  • Once you Pivot in Market And what about if you can bounce back from a failure in market? 13
  • Once you Pivot in Market <15% 14 Steve Blank “Startup Owner’s Manual”
  • Why Do They Fail? ? 15
  • Why Do They Fail? They fail to create a product that people need and will use 16
  • Avoiding Failure Failure is usually catastrophic because there are no means to recover (money, time, expertise). Therefore, we need to either fail faster or know more before starting. We must identify and eliminate the risks around what users need and what they will use. 17
  • Better Methodologies Identify and eliminate risks earlier in the cycle Agile Lean Real-time Prototyping 18
  • Agile Think in weeks. Plan, build, test, repeat weekly; Involve real users in testing; Ability to pivot earlier Learning happens in sprints/weekly. Not good enough (a week of quality work is not cheap). 19
  • Lean Think in days. Front-load learning; test before building when possible (Lean Canvas model). Identify a problem, generate idea, de-risk it, build it, test it. Build Problem Solving Products (PSP). Some learning happens daily, but most is weekly. Still not good enough (need fast + cheap + good). 20
  • Accelerate Learning We can (and need to) increase our rate of learning by several orders of magnitude 21
  • Phases of Product Learning Phase 1 (90%): Does it make sense? Does it feel right? Ask: Real problem? Needs solution? What solution? Doable? Acceptable? Intuitive? Generalizable? Learn: problem space, user expectations, solutions, UI approaches, modalities, ergonomics Phase 2 (9%): Does it work with real data? Phase 3 (1%): Does it work in real life? 22
  • Real-time Prototyping Think in minutes. “Minimal Viable Experiments”- a few minutes each; Hundreds of experiments can be done before building any real software. Learning happens several times per hour. 23
  • Learning is Not Failing Experiments don’t fail. They create learning. 24
  • Minimal Viable Experiments To get real insights, the medium must be reality -not in our heads. 25
  • Paper Prototypes 26
  • Paper Flows 27
  • Paper Experiments 1. Draw the UI on stacks of index cards. 2. Let the user “click” somewhere. 3. Replace the card with another one that shows the new screen. 4. Observe if the user gets lost or has questions. 5. In the case of feedback, draw a new card in 10 seconds. 6. Results in ergonomic UI’s and workflows 28
  • Digital Prototypes 1. Convert paper prototypes into digital with tools like Popapp 2. Create digital mockups with tools like OmniGraffle 3. Test on real users 4. Incorporate feedback immediately 5. Use to build working software for specific features (in hours) 6. Test with real data 29
  • Manual Messaging Use existing channels to “simulate” software interaction: email, text, IM, etc. Use a human to act as server. Do NOT build software that a human can’t first do manually. Test and adjust messaging and flow until it is intuitive to real users 30
  • Manual Messaging 31
  • Readme Experiment 1. Write the documentation first. Strictly no coding! 2. Show the documentation to real users 3. Ask them: If/how they would use it What part of it they would not use What value it would have to them What else is missing 4. Change the documentation until it describes the perfect software 5. Use Agile/Lean to build PSP 32
  • And More MVE’s! There are hundreds of experiments you can come up with for any software product. Get creative and think outside the domain; start with experiments that don’t require coding. Remember, there is no such thing as a failed experiment! 33
  • A 48 Hour Example 2 day immersive workshop with key stakeholders: - Morning 1: Set real-world context (go do something) - Fill whiteboard with problems and ideas - Prove/disprove assumptions for each idea/solution through rapid experiments - Build first working prototype by lunch and test in realworld - Refine ideas and experiments; build second prototype overnight - Day 2: Test, refine, test, refine… in real world - Hour 48: complete working prototype 34
  • Recap - You must be faster, cheaper, AND better to win the software game. - This requires being agile and lean, but also creating real-time prototypes/experiments. - Learning is not failing; push learning up-front where it is cheaper/faster. - Start thinking in minutes: an hour is the new week. 35