3 hour tutorial at RailsConf 2010 focusing on lean practices in Ruby on Rails.

1. Get Lean
Slimming Down with Rails
Marty Haught
@mghaught
http://martyhaught.com
http://github.com/mghaught/getlean

2. tutorial’s goal
• introduce lean concepts
• discuss the how and why
• demonstrate Rails-specific techniques
• give you a starting place to go further

3. session guidelines
• questions are welcome at any point
• let’s be interactive
• encourage conversations
• we’ll have breaks

4. context for today
• limited resources (time & money)
• uncertain of solution
• unknown market

5. outline
1. lean overview
2. rails basics
3. focusing on value
4. minimize effort
5. measuring
6. delivering fast

6. tutorial material
http://github.com/mghaught/getlean

7. flingr!
tutorial/install.md
http://flingr.martyhaught.com
http://ciflingr.martyhaught.com

8. Boulder Ruby
Longmont, Colorado

9. why lean?
consulting entrepreneurship

10. other reasons
• bloated, inefficient agile projects
• building software no one wants or uses

11. rockin with ramen
(pictured with Dokken)

12. 1. lean overview
“from manufacturing to software”

13. discovering lean
Mary Poppendieck
http://www.poppendieck.com/

14. history of lean
• emerged from manufacturing in the 50s
• Toyota production system
• translated for software projects in 90s
• influenced agile thinking

15. lean startups
“translating your startup vision into a successful
business as quickly and efficiently as possible”
Eric Ries
http://www.startuplessonslearned.com/

16. customer development
Steve Blank
http://steveblank.com/

17. new ‘translation’
http://www.custdev.com/

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
• notifications

23. master your stack
• practice your art to get faster
• use plugins and gems for common
functionality
• anything to let you focus more on what’s
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 more
testing and process than a twitter-based web app.”

25. context changes
• what worked for the start of the project
may not fit 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. defining 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 define success?
• how do you measure it?
• will people use it?
• who?

29. agile’s customer
• dev team takes direction from client
• no questioning of business motives in
feature requests
• engineers don’t ‘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 flingr’s mvp?
• what about webbchange?

47. learning process
• make progress by reaching users
• don’t just execute a plan
• use feedback
• pivot as you learn

48. Eric Ries’ feedback loop

49. 4. minimize effort
“less 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 ain’t 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 doesn’t contribute to
progress
• re-evaluate the value of what you’re doing

53. seven wastes of lean

54. Develop only for the current
Overproduction Extra Features
story
Story cards are detailed only
Inventory Backlog, Requirements
for the current iteration
Extra Processing Extra Steps Code directly from stories
Have everyone in the same
Motion Finding Information
room; customer included
Test first; including acceptance
Defects Defects not caught by tests
tests
Waiting Waiting, Including Customers Deliver in small increments
Developers work directly with
Transportation Handoffs
customers

55. 5. measuring
“know when you’re 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. flingr metrics
• unique visits (acquisition)
• signups (activation)
• repeat use (retention)
• fling backs (referral)
• pro upgrade (revenue)

61. skip services for now
• Google Analytics http://www.google.com/analytics
• MixPanel http://mixpanel.com/
• KISSMetrics http://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 exercise
tutorial/metrics.md

64. what to measure?
• will the new story add value?
• how will you measure progress?
• define when new stories are created
• best when it’s one of your core metrics

65. split testing
“presenting two or more variations and
measuring user behavior to determine value”

66. benefits
• 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
• don’t go overboard
• don’t let it replace your vision

68. split test exercise
tutorial/abingo.md
tutorial/vanity.md

69. take away
• limited to a single metric/conversion
• best when you can analyze all aarrr metrics

70. 6. delivering fast
“speed wins”

71. small batches
“amount of finished 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 flow of work
• expression of just in time
• emphasis on flow
http://www.limitedwipsociety.org/

73. science behind it
• queueing theory
• theory of constraints
• proven in world of manufacturing
• working in software projects

74. agile’s iteration
• fixed time box, such as two weeks
• IPM to cover a set of stories
• make estimates
• velocity to determine what fits

75. reducing waste
• no need to estimate
• no need to force stories to fit
• just in time meetings
• no big batch of stories

76. kanban exercise

77. kanban benefits
• 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 flow of completed features”

82. agile way
• batch up all stories for iteration
• separate integration step
• explicit sign off process
• qa -- staging -- production

83. not lean
“the larger the gap between ‘trunk’ and
production, 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
Monitor Test
Deploy

86. go lighter
• deploy to a ‘dev’ instance
• no monitoring

87. faking it
• nothing’s automated
• once you commit a feature, deploy

88. monitoring
• pingdom
• nagios with business metrics
• stop the line on alert

89. five whys
• determine source of issue
• take small steps to prevent

90. benefits
• eliminates waste on shipping code
• features go live sooner
• reduce shelf time for finished work
• find 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 f’n time?
• don’t blindly follow some guideline
• does 100% coverage have business value?
• are all tests valuable?
• cost of writing/maintaining all tests?
• cost of failure/bugs?

95. value of testing
• not all project phases value testing equally
• larger the team, the greater the need
• context really matters

96. phases of a startup
Kent Beck
http://www.threeriversinstitute.org/blog/?p=251
1. Taxi (find a need)
2. Takeoff (validate need has a problem)
3. Climb (scaling)
4. Cruise (manage)

97. lean up your tests
• consider business value of features tested
• view tests as a garden, must prune
• strong integration layer
• test interesting/tricky business logic
• look for high value, small footprint tests
• skip rarely used areas like admin UI

98. takeaway
• really understand value for your project
• focus on tasks that add value
• ship early and continuous
• automate all that you can
• minimize effort to get feedback asap

99. go forth and rock!

100. thank you
Marty Haught
@mghaught
mghaught@gmail.com
http://martyhaught.com

101. image credits
Long's Peak - http://www.flickr.com/photos/17972620@N00/2956076614/
Pile of Money - http://www.flickr.com/photos/ironrodart/3841677517/
Bowl of Ramen - http://www.flickr.com/photos/billselak/2388252659/
George Lynch - http://www.rollingstone.com/artists/dokken/photos/collection/photo/1
Lean Overview - http://pffc-online.com/mag/paper_latitudes_lean/
Rails Stack - http://www.building-your-model-railroad.com/model-railroad-operation.html
Gold Heart - http://www.flickr.com/photos/cryodigital/3060730616/
Ice Cream Glove by Ali G - Sacha Baron Cohen
Kool-Aid - http://www.flickr.com/photos/dyannafstop/2025899850/
Various Black and Whites - http://blackandwtf.tumblr.com/
Hammock - http://www.flickr.com/photos/wisdoc/3212710310/
Seven Deadly Sins - Painter Hieronymus Bosch
Measuring - http://www.flickr.com/photos/captkodak/272746539
Motley Crue - http://www.laughinsam.com/1980Images/MotleyCrue.jpg
Running Dog - http://www.flickr.com/photos/wisdoc/123640339/
Chocolate Peanut Butter Cups - http://chocolateheaven.org
Randy Rhoads - www.rudysarzo.com/images/bio/Randy-Rhoads.jpg