master your stack
• practice your art to get faster
• use plugins and gems for common
• anything to let you focus more on what’s
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.”
• what worked for the start of the project
may not ﬁt once you enter into
• the larger the organization, the more the
• accept that you will likely have to re-
3. focusing on value
“work on the right things”
deﬁning your product
• knowing your vision
• clarify and agree as a team
• what is your value?
• why are you creating this software?
• how do you deﬁne success?
• how do you measure it?
• will people use it?
• dev team takes direction from client
• no questioning of business motives in
• engineers don’t ‘own’ the business side
• strip features to the essence that achieves
• spiking large features
• “do the simplest thing that could possibly
• pushing off decisions, commitment until the
last possible moment
• yagni - you ain’t going to need it
• no really, be militant about pushing things
• core value of lean, eliminating waste
• does your current task add business value?
• eliminate activity that doesn’t contribute to
• re-evaluate the value of what you’re doing
Develop only for the current
Overproduction Extra Features
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 ﬁrst; including acceptance
Defects Defects not caught by tests
Waiting Waiting, Including Customers Deliver in small increments
Developers work directly with
“know when you’re making progress”
• simple, less process
• limit work in progress, maximize
• more easily spot bottlenecks
• easy to change direction
• less inventory of requirements/stories
• less time in meetings
• green or undisciplined team
• other reasons?
• one week iterations
• ultra light weight complexity ‘estimates’
• continuously add stories to backlog as
• no ipm, just in time discussions
• deploy stories when complete
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?
value of testing
• not all project phases value testing equally
• larger the team, the greater the need
• context really matters
phases of a startup
1. Taxi (ﬁnd a need)
2. Takeoff (validate need has a problem)
3. Climb (scaling)
4. Cruise (manage)
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
• 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