• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
8 Principles for Enabling Build/Measure/Learn: Lean Engineering in Action
 

8 Principles for Enabling Build/Measure/Learn: Lean Engineering in Action

on

  • 6,040 views

Keynote for eBay Classifieds TechCon 2013, Tues June 25, 2013.

Keynote for eBay Classifieds TechCon 2013, Tues June 25, 2013.

This is a variation on previous lean engineering talks but focuses on 8 principles for enabling build/measure/learn.

Statistics

Views

Total Views
6,040
Views on SlideShare
6,008
Embed Views
32

Actions

Likes
10
Downloads
53
Comments
2

4 Embeds 32

http://www.google.com 15
https://twitter.com 12
http://www.pulse.me 4
http://pulse.me&_=1372917356011 HTTP 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Nice talk. But words are cheap, and this is very light on delivery. So you changed a dozen static marketing pages and made Express Checkout work in a modal (and apparently only for selected merchants from all I can see)... Over 2 years? I love how new people always think they're so much better than their predecessors. In 2 years, we used to do a redesign of pretty much the whole site, including checkout. With a lot fewer buzzwordy SlideShare presentations. FWIW.
    Are you sure you want to
    Your message goes here
    Processing…
  • Love this talk Bill. Esp #1 and #5 are the hardest to focus on.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    8 Principles for Enabling Build/Measure/Learn: Lean Engineering in Action 8 Principles for Enabling Build/Measure/Learn: Lean Engineering in Action Presentation Transcript

    • 8 principles for enabling build/measure/learnlean engineering in actioneBay Classifieds TechConJune 2013@billwscottSr. DirectorUser Interface Engineering@paypal
    • continuous customer feedback (GOOB)customer metrics drive everythingthink it. build it. ship it. tweak itfail fast. learn fast.lots of experimentation... build/measure/learna different view ofengineering
    • paypal vs netflixcontrast this with a large enterprise like paypal (circa 2011)
    • guess what i found (in 2011)roll your own. disconnected deliveryexperience. culture of long shelf life.inward focus. risk averse.
    • In 2011, even a simplecontent copy changecould take as much as 6weeks to get live to site
    • new dna insertedjan 2012fleshed out ui layer that could support rapidexperimentationmarch 2012david Marcus becomes president of PayPalapril 2012formed lean ux team to reinvent checkoutexperience
    • hermes project lean ux/engineering in actionfrom whiteboard to code from code to usabilitylearningsstart again
    • change has started working its way out
    • change has started working its way out
    • lean startup movementfounded on build/measure/learn cycleget out of the building (GOOB)invalidate your risky assumptionsfail fast, learn fastget to the pivotgo for the minimal viable product (MVP)
    • lean uxdesigning products for build/measure/learnrequires 3 rules to be followed at all timesget to & maintain a shared understandingform deep collaboration across disciplineskeep continuous customer feedback flowing
    • purpose of lean engineeringbuildmeasurelearnLEANENGINEERINGEnablingBuild/Measure/LearnwithLeanStartupPrinciples
    • buildembracecontinuous deliverymake mistakes fastmeasure learnthe etsy way. Kellan Elliott-McCrea, CTO etsyuse metrics drivendevelopmentknow that you made amistakeblameless postmortemlearn from yourmistakes
    • LEANENGINEERING8principlesforenablingbuild/measure/learn
    • 1. focus on learning, not delivery
    • one of our biggest challenges is movingfrom a culture of delivery to aculture of learning
    • too many teams can create silos within theexeriencecommon silos that can affect experience:• number of scrum teams• specialization of skills• device channels• regional adaptationsCE2don’t let delivery driveexperience
    • 2. build a culture of rapid experimentation
    • long shelf life for softwarewhen software is not dynamically updatablewhen it takes herculean effort to deliverresultengineers run the asylumdelivery dates drive the experienceBDUF & waterfall prevail
    • 16 different test cells in the initial PS3 Launch (2010)focus is on build/measure/learnfour distinct PS3 experiences launched on same daytypical netflix release
    • ramping vs experimentingramping model results in oneexperience (with some tweaks alongthe way) after a long ramp up timeexperimentation model results inmany experiences being tested allalong the way
    • avoid disconnecteddelivery experiencecirca 1985deliver to disk then to usereverything was focused on getting itperfect for stamping on the diskno user in the loop. experiencehappened somewhere down thesupply chain
    • 3. design for volatility
    • the epiphany
    • you have to engineerfor volatilitychange is the normexperimentation is not a one time eventlaunching a product is giving birth to theproduct. the product’s life just begins.design for throwaway-abilitymajority of theexperience codewritten is thrownaway in a yearthe ui layer is theexperimentation layer
    • experiences must learnOur software is always tearing itself apart(or should be)Recognize that different layers change atdifferent velocitiesAll buildings are predictions.All predictions are wrong.Theres no escape from this grimsyllogism, but it can be softened.Stewart Brand
    • 4. embrace open source
    • building experiencescirca 1985merry band of three. dropped out ofcollege for semester. it was nirvana.however...
    • roll your own “everything”(close your eyes & imagine)no internet. no google. no blogs. no email. noblogs. no stackoverflow. no github. no twitter.much of the software era has been aboutbuilding from scratch.of course open source was gaining momentum.unix. gnu. linux. perl. mozilla.
    • use open source religiously
    • work in open source modelinternal github revolutionizingour internal developmentrapidly replacing centralizedplatform teamsinnovation democratizedevery developer encouragedto experiment and generate reposto share as well as to fork/pull request
    • give back to open sourcewe have projects that we will open sourcenode webcore (similar to yeoman)we are contributing back to open sourcecontributions to bootstrap (for accessibility)contributions to bootstrap (for internationalization)core committer on dustjs project
    • using github for continuous *use github for continuous integrationstarting to use github repo model for continuous deploymentmarketing pagesproduct pagescontent updates & triggers into i18n, l10n, adaptationcomponents
    • 5. map lean onto agile
    • btw, agile doesn’t have a brain...agile has been a big step in the right directionbut is an engineering disciplinedoesn’t address the full life cycleagile has become big business and sometimes collapses under the weightof “ceremonies” (process)but agile is a good “engine” for delivery if you know what to roughly buildagile needs a brain...
    • lean ux: enable a brain for agileuser interface engineering - agile scrum team (production)lean ux - lean team track (prototyping)engineering - agile scrum teamsprint 0usability usability usability usability usabilityrelease release release release{agile
    • 6. make your product a living spec
    • create a living specenabling the prototypelearning
    • stack circa 2011/early 2012simple change could take minutesto seefollows an “enterprise application”model. ui gets built into the “app”javajsp***restrictedcapabilities*prototypingwas hard“ui bits” couldonly live here* assumed client developers were low-skill* required server side java eng for simple client changes** java server pages. server-side java templating solutionserver sidecomponents**clientserver
    • we blended prototype & productionwe enabled the “ui bits” to beportable between the prototypingstack and the production stackjava (rhinoscript)node.js{dust}JS templateprototypestackproductionstack{dust}JS templateeither stack
    • java (rhinoscript)productionstack{dust}JS templateone stack: prototype & productionnode.js{dust}JS templateprototypestackthe final step is we made theprototype stack and productionstack the same technologythroughout the application stack
    • 7. refactor your way out of debt
    • technical debtrarely do you have a clean slategenerally you will have to refactor yourway to a nimble framework
    • we separated the ui bitscode = JS(backbone)templates =JS{dust}style = CSS(less)imagesre-engineered the userinterface stack so thatthe only artifacts are:• javascript• css• imagesditched the server-sidementality to creating UIs• no more server-sideonly templates• no more server-sidecomponents• no more server-sidemanaging the ui
    • code = JS(backbone)templates =JS{dust}style = CSS(less)imageswe used javascript templatingtemplates get convertedto javascript<p>Hello {name}</p>JavaScript compiles to...javascriptexecutedto generate ui
    • we used natural web artifacts - “web bits”server-side language independentserver/client agnosticCDN readycacheablerapid to createcode = JS(backbone)templates =JS{dust}style = CSS(less)images
    • ensured we could run on new & legacyJS templating can be runin client browser orserver on the productionstackwe can drag & drop theui bits from prototypingstack to the productionstackjava(rhinoscript)node.js{dust}JS templateprototypestackproductionstack{dust}JS templateclient ORservereither stack
    • experience debtdon’t just think about our technical debtconsider our “experience debt”cripples our ability to capture market andinhibits learning
    • 8. learn across all channels
    • mobile strategy ≠ just iOS appnative apps make it easier to create a richexperiencehowever, they are limited in reach and inlearning capabilityapp install rates will only be a subset of thecustomer baseyou need both a native and html5 strategy inorder to maximize learning
    • html5 is critical to learning strategynew users will see your html5 experiencethe onramp to onboarding is the lowly linknetwork delivery makes a/b testingstraightforwardnetflix gambled on html5 for mobile (iOS,android) and for game consoles, bluray players,hdtvs, etc.why? build/measure/learn. network delivery.
    • summaryrethink engineering. every dimension of your engineering needs to be aboutenabling build/measure/learntechnology. but not for tech sake. we are doing it for the experience tosupport lean startup principles.process. enabled lean ux and put a brain on agile.people. revitalizing our existing talent and started attracting new talent.
    • before
    • after
    • designing web interfacesO’Reillypicture creditshttp://www.flickr.com/photos/decade_null/2053134780/http://www.flickr.com/photos/therevsteve/3104267109/http://www.flickr.com/photos/juanpol/16287486/http://www.flickr.com/photos/giesenbauer/4092794246/http://www.flickr.com/photos/not_wise/182849352/http://www.flickr.com/photos/mbiskoping/6075387388/http://www.flickr.com/photos/37217398@N02/3442676067/http://www.flickr.com/photos/proimos/3473264448/http://www.flickr.com/photos/epsos/8463683689/http://www.flickr.com/photos/stuckincustoms/2380543038/http://www.flickr.com/photos/matthewpaulson/6176787688/http://www.flickr.com/photos/90585146@N08/8222922317/http://www.flickr.com/photos/cote/63914774/http://www.flickr.com/photos/olvrbrown/4542851399/http://www.flickr.com/photos/donpezzano/3257999898/follow me on twitter@billwscottDesigning Web InterfacesO’ReillyBill Scott & Theresa Neil