18. changed my view much like when I discovered XP in 2004 think just as much about the business as the technical engineers should own the business side
19. 2. rails stack preaching to the choir
20. why rails/sinatra great for prototyping can be minimal or full stack change is easy start simple but can grow
21. community assets helpful easy to pick up new resources constantly improving
22. automation automated testing continuous integration data migrations deployment notications
23. master your stack practice your art to get faster use plugins and gems for common functionality anything to let you focus more on whats important
24. context is king pick the right amount of process start simple and add on as you go know when not to use lean A solar death ray assembler would likely need moretesting and process than a twitter-based web app.
25. context changes what worked for the start of the project may not t once you enter into maintenance mode the larger the organization, the more the process accept that you will likely have to re- evaluate
26. 3. focusing on value work on the right things
27. dening your product knowing your vision clarify and agree as a team what is your value? why are you creating this software?
28. business value how do you dene success? how do you measure it? will people use it? who?
29. agiles customer dev team takes direction from client no questioning of business motives in feature requests engineers dont own the business side
30. ice cream glove
31. drinking your kool-aid?
32. webbchange story
33. of excess
34. of too many features
35. valuing web content
36. demo time
37. everything but ... Getting in all the features before launching
38. Built too much?!?
39. my mistake
40. will people use it?
41. got eyeballs on it
42. too complex
43. ran out of money
44. lessons learned start simple and launch early validate against real use get out of the building and talk to people
45. minimum viable product rails rumble or startup weekend starting place for validated learning with the least effort should be embarrassing early adopters see the potential
46. mvp exercise what is ingrs mvp? what about webbchange?
47. learning process make progress by reaching users dont just execute a plan use feedback pivot as you learn
48. Eric Ries feedback loop
49. 4. minimize effortless is more
50. simplicity strip features to the essence that achieves value spiking large features do the simplest thing that could possibly work
51. delay commitment pushing off decisions, commitment until the last possible moment yagni - you aint going to need it no really, be militant about pushing things off
52. reducing waste core value of lean, eliminating waste does your current task add business value? eliminate activity that doesnt contribute to progress re-evaluate the value of what youre doing
53. seven wastes of lean
54. Develop only for the current OverproductionExtra Features storyStory cards are detailed onlyInventoryBacklog, Requirements for the current iterationExtra Processing Extra Steps Code directly from stories Have everyone in the same Motion Finding Information room; customer includedTest rst; including acceptance DefectsDefects not caught by tests testsWaitingWaiting, Including CustomersDeliver in small incrementsDevelopers work directly with TransportationHandoffscustomers
55. 5. measuring know when youre making progress
56. pirate metrics
57. not vanity metrics
58. must be actionable should help you make decisions
59. AARRR! by Dave McClure http://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version acquisition activation retention referral revenue
60. ingr metrics unique visits (acquisition) signups (activation) repeat use (retention) ing backs (referral) pro upgrade (revenue)
61. skip services for now Google Analyticshttp://www.google.com/analytics MixPanel http://mixpanel.com/ KISSMetricshttp://kissmetrics.com/ others
62. diy metrics you control the data can track any event in your system good enough for actionable metrics start simple, 5 at most
63. metrics exercisetutorial/metrics.md
64. what to measure? will the new story add value? how will you measure progress? dene when new stories are created best when its one of your core metrics
65. split testingpresenting two or more variations and measuring user behavior to determine value
66. benets best mechanism to truly measure progress can answer internal debates
67. pitfalls can lead to a mess if not well-guided may not get conclusive reports dont go overboard dont let it replace your vision
68. split test exercise tutorial/abingo.mdtutorial/vanity.md
69. take away limited to a single metric/conversion best when you can analyze all aarrr metrics
70. 6. delivering fastspeed wins
71. small batches amount of nished work that can be shipped reduce to smallest, meaningful chunks reduces integration costs helps avoid overproduction think hours not days
72. kanban a pull-based system for continuous ow of work expression of just in time emphasis on ow http://www.limitedwipsociety.org/
73. science behind it queueing theory theory of constraints proven in world of manufacturing working in software projects
74. agiles iteration xed time box, such as two weeks IPM to cover a set of stories make estimates velocity to determine what ts
75. reducing waste no need to estimate no need to force stories to t just in time meetings no big batch of stories
76. kanban exercise
77. kanban benets simple, less process limit work in progress, maximize throughput more easily spot bottlenecks easy to change direction less inventory of requirements/stories less time in meetings
78. why not? cultural green or undisciplined team other reasons?
79. kanban-tracker hybrid one week iterations ultra light weight complexity estimates continuously add stories to backlog as needed no ipm, just in time discussions deploy stories when complete
80. kanban continuous deployment
81. continuous deployment automatic ow of completed features
82. agile way batch up all stories for iteration separate integration step explicit sign off process qa -- staging -- production
83. not leanthe larger the gap between trunk andproduction, the heavier the process
84. classic stack source control with commit hook continuous integration deploy/rollback script real time alerts root cause analysis
85. Commit MonitorTestDeploy
86. go lighter deploy to a dev instance no monitoring
87. faking it nothings automated once you commit a feature, deploy
88. monitoring pingdom nagios with business metrics stop the line on alert
89. ve whys determine source of issue take small steps to prevent
90. benets eliminates waste on shipping code features go live sooner reduce shelf time for nished work nd integration issues quickly in isolation
91. cd exercise tutorial/contdeploy.md
92. take away deliver code faster focus on features, not integration reduces fear of pushing to production quality does not have to decline
93. why we test exercise?
94. test all the fn time? dont blindly follow some guideline does 100% coverage have business value? are all tests valuable? cost of writing/maintaining all tests? cost of failure/bugs?