Enabling Lean at Enterprise Scale: Lean Engineering in Action
1 like771 views
The document discusses the implementation of Lean UX and Lean Engineering at PayPal, emphasizing the transition from a risk-averse, delivery-focused culture to one centered on rapid experimentation and customer feedback. It outlines key principles for engineering including enabling learning, fostering continuous delivery, designing for volatility, and decentralizing engineering processes. The strategies and changes implemented illustrate how PayPal evolved to support a more agile, responsive development environment in order to enhance user experiences and reduce time to market.
Enabling Lean at Enterprise Scale: Lean Engineering in Action
- 1. enabling lean at enterprise scale lean ux & lean engineering in action Agile Camp 2013 San Jose, CA Sept 21, 2013 @billwscott Sr. Director User Interface Engineering @paypal
- 2. continuous customer feedback (GOOB) customer metrics drive everything think it. build it. ship it. tweak it fail fast. learn fast. lots of experimentation... build/measure/learn engineering for experimentation netflix view of engineering
- 3. paypal vs netflix contrast this with a large enterprise like paypal (circa 2011)
- 6. paypal way of engineering (in 2011) roll your own. disconnected delivery experience. culture of long shelf life. inward focus. risk averse.
- 8. In 2011, even a simple content copy change could take as much as 6 weeks to get live to site
- 9. new dna inserted jan 2012 fleshed out ui layer that could support rapid experimentation march 2012 david Marcus becomes president of PayPal april 2012 formed lean ux team to reinvent checkout experience
- 10. hermes project lean ux/engineering in action
- 11. hermes project lean ux/engineering in action from whiteboard to code
- 12. hermes project lean ux/engineering in action from whiteboard to code from code to usability
- 13. hermes project lean ux/engineering in action from whiteboard to code from code to usability learnings
- 14. hermes project lean ux/engineering in action from whiteboard to code from code to usability learningsstart again
- 15. before
- 16. after
- 17. change has started working its way out
- 18. change has started working its way out
- 19. change has started working its way out
- 20. rethink engineering in the light of lean shift the lens of engineering to embrace the build/measure/learn cycle engineer for experimentation LEANENGINEERING Engineeringfor Experimentation withLeanStartup Principles
- 22. 1. engineer for learning, not delivery
- 23. most organizations biggest challenge is moving from a culture of delivery to a culture of learning
- 24. include engineering in customer learning engineers should regularly be in usability studies & customer visits feedback from “measure” phase should be regularly discussed in engineering you want to create an engineering culture that focuses on real customer problems
- 25. include engineering in customer learning engineers should regularly be in usability studies & customer visits feedback from “measure” phase should be regularly discussed in engineering you want to create an engineering culture that focuses on real customer problems engineer
- 26. enable prototyping in the engineering stack because engineering teams are not trying to solve the learning problem, they see prototyping as outside the engineering discipline this is a real engineering challenge engineer for the “living spec”
- 27. stack circa 2011/early 2012 simple change could take minutes to see follows an “enterprise application” model. ui gets built into the “app” java jsp*** restricted capabilities* prototyping was hard “ui bits” could only live here * assumed client developers were low-skill * required server side java eng for simple client changes ** java server pages. server-side java templating solution server side components** client server
- 28. we blended prototype & production we enabled the “ui bits” to be portable between the prototyping stack and the production stackjava (rhino JS eng)node.js {dust} JS template prototype stack production stack {dust} JS template either stack
- 29. java (rhino js eng) production stack {dust} JS template new single stack: prototype & production node.js {dust} JS template prototype stack the final step is we made the prototype stack and production stack the same technology throughout the application stack
- 30. java (rhino js eng) production stack {dust} JS template new single stack: prototype & production node.js {dust} JS template prototype stack the final step is we made the prototype stack and production stack the same technology throughout the application stack
- 31. connect delivery to learning in 1985 I delivered software on a 3.5” diskette little or no feedback loop everything was focused on getting it the one right experience on the disk no user in the loop. experience happened somewhere down the supply chain
- 32. enable learning on mobile native apps make it easier to create a rich experience however, they are limited in reach and in learning capability app install rates will only be a subset of the customer base you need both a native and html5 strategy in order to maximize learning
- 33. html5 is critical to learning strategy new users will see your html5 experience the onramp to onboarding is the lowly link network delivery makes a/b testing straightforward netflix gambled on html5 for mobile (iOS, android) and for game consoles, bluray players, hdtvs, etc. why? build/measure/learn. network delivery.
- 34. 2. engineer for experimentation
- 35. 16 different test cells in the initial PS3 Launch (2010) focus is on experimentation the netflix way
- 36. 16 different test cells in the initial PS3 Launch (2010) focus is on experimentation four distinct PS3 experiences launched on same day the netflix way
- 37. build embrace continuous delivery make mistakes fast measure learn the etsy way. Kellan Elliott-McCrea, CTO etsy use metrics driven development know that you made a mistake blameless post mortems learn from your mistakes
- 38. ramping vs experimenting the big bet. ramping model results in one experience (with some tweaks along the way) after a long ramp up time lots of little bets. experimentation model results in many experiences being tested all along the way vs
- 39. long shelf life kills experimentation engineering has to make delivery a non- event result delivery dates drive the experience feature-itus becomes prevalent BDUF & waterfall prevail little to no learning
- 40. a tale of two trains departs infrequently “gotta get on the train or I will have to wait a long time”
- 41. a tale of two trains departs infrequently “gotta get on the train or I will have to wait a long time” departs all the time “if I miss this train another one comes in a few minutes”
- 42. using git for continuous deployment starting to use git repo model for continuous deployment marketing pages product pages content updates & triggers into i18n, l10n, adaptation components works well with cloud deployment (devops model) enables the train to be leaving all the time
- 43. 3. design for volatility
- 44. the epiphany
- 45. you have to engineer for volatility change is the norm experimentation is not a one time event launching a product is giving birth to the product. the product’s life just begins. design for throwaway-ability majority of the experience code written is thrown away in a year
- 46. you have to engineer for volatility change is the norm experimentation is not a one time event launching a product is giving birth to the product. the product’s life just begins. design for throwaway-ability majority of the experience code written is thrown away in a year the ui layer is the experimentation layer
- 47. experiences must adapt Our software is always tearing itself apart (or should be) Recognize that different layers change at different velocities All buildings are predictions. All predictions are wrong. There's no escape from this grim syllogism, but it can be softened. Stewart Brand
- 49. building experiences circa 1985 merry band of three. dropped out of college for semester. it was nirvana. however...
- 50. roll your own “everything” (close your eyes & imagine) no internet. no google. no blogs. no email. no blogs. no stackoverflow. no github. no twitter. much of the software era has been about building from scratch. of course open source was gaining momentum. unix. gnu. linux. perl. mozilla.
- 51. work in open source model internal github revolutionizing our internal development rapidly replacing centralized platform teams innovation democratized every developer encouraged to experiment and generate repos to share as well as to fork/pull request
- 52. give back to open source we have projects that we will open source node webcore (similar to yeoman) we are contributing back to open source contributions to bootstrap (for accessibility) contributions to bootstrap (for internationalization) core committer on dustjs project
- 53. use open source religiously nconf async q supertest
- 54. 5. put a brain on agile credit: Krystal Higgins http://bit.ly/18uP7N1
- 55. agile doesn’t have a brain... agile is a hungry machine. it will crank out garbage or brilliance. and it will do it iteratively. it is a travesty to waste this machine you have to get the experience “in the ballpark” to best use the machine it is imperative to make it easy to iterate designs ahead of the agile sprints leanux in the form of a “leanux scrum team” is one way to do this
- 56. lean ux: enable a brain for agile user interface engineering - agile scrum team (production) lean ux - lean team track (prototyping) engineering - agile scrum teamsprint 0 usability usability usability usability usability release release release release {agile
- 57. lean ux: enable a brain for agile user interface engineering - agile scrum team (production) lean ux - lean team track (prototyping) engineering - agile scrum teamsprint 0 usability usability usability usability usability release release release release {agile stories, user interface code come over from the leanux stream n+2 is more feasible because it actually bootstraps the agile stream
- 58. too many teams can create silos within the exerience what can fracture the experience • number of scrum teams • specialization of skills • device channels • regional adaptations CE2 watch out for fracturing the experience
- 59. as we have mapped lean onto agile it has exposed mismatches between the way we work you run the risk: • driving the experience based on eng teams • becoming a botteneck in almost all cases • either product is not aligned to the biz • or there are just too many people watch out for mismatch between teams
- 60. 6. refactor your way out of debt
- 61. technical debt rarely do you have a clean slate generally you will have to refactor your way to a nimble framework
- 62. ensured we could run “ui bits” on new & legacy we chose to make our “ui bits” as close to regular HTML/CSS as possible we enabled the same “ui bits” (templates) to run on any of our stacks java (rhino js eng) node.js prototype stack & production stack production stack client server any stack c++ (v8 js eng) production stack {dust} JS template
- 63. experience debt don’t just think about our technical debt consider the “experience debt” cripples our ability to capture market and inhibits learning key that engineering sees a chance to improve the experience whenever they are cleaning up technical debt
- 64. rethink engineering in the light of lean shift the lens of engineering to embrace the build/measure/learn cycle engineer for experimentation LEANENGINEERING Engineeringfor Experimentation withLeanStartup Principles
- 65. designing web interfaces O’Reilly picture creditshttp://www.flickr.com/photos/decade_null/2053134780/ http://www.flickr.com/photos/not_wise/182849352/ http://www.flickr.com/photos/37217398@N02/3442676067/ http://www.flickr.com/photos/hongiiv/4151964823/ Photo by Kim White: http://readwrite.com/2013/09/05/paypal-app-update-in-store- payments#awesm=~ohHUppP9dhMmMG http://www.flickr.com/photos/matthewpaulson/6176787688/ http://www.flickr.com/photos/olvrbrown/4542851399/ http://www.flickr.com/photos/juanpol/16287486/ http://www.flickr.com/photos/olvrbrown/4542851399/ http://www.flickr.com/photos/mbiskoping/6075387388/ http://www.flickr.com/photos/giesenbauer/4092794246/ http://www.flickr.com/photos/kowani/5565778790/ http://www.flickr.com/photos/ahockley/2657296577/ http://www.flickr.com/photos/90585146@N08/8222922317/ http://www.flickr.com/photos/therevsteve/3104267109/ Stewart Brand: How Buildings Learn (illustrations) http://www.flickr.com/photos/light_seeker/7444052000/ Krystal Higgins: http://www.kryshiggins.com/sketchnotes-of-bringing-design-to-life-with-lean-ux-lean-engineering/ http://www.flickr.com/photos/epsos/8463683689/ http://www.flickr.com/photos/proimos/3473264448/ http://www.flickr.com/photos/stuckincustoms/2380543038/ follow me on twitter @billwscott