Ignite presentation at The Lean Startup Conference (LeanStartup.co) in December 2012 in San Francisco by Arin Sime of AgilityFeat.com. In this 5 minute presentation, Arin took people through his complaints of companies (even startups) not deploying often enough, and offered 5 tips for how to prevent from doing this yourself.
7. #1 – Avoid Release Plans
Test Code
Release
Every 2
weeks
8. Instead…
Feature Feature
Ready
Highest Priority
to build
Feature Ready to
deploy
Feature
Feature
Feature
Feature
Feature
Feature
9. #2 – Avoid Big Bang Deployments
“Big release”
Feature B
Feature A
Design Bug fix
Change
Pricing
Feature C Change
meh.
Which was the cause?
10. Instead…
Define Test the Measure
Biz Test
Code it!
code
Deploy!
results
Learn!
11. #3 – Logins are low priority
Too-Typical Developer:
“Great! First I’m going to setup our user
types, an administration site, and this
cool security framework…”
I’m Arin Sime and I’m a software developer with a few things on my mind. I’d like to share with you some antipatterns that I see too much in startups.20 slides, 15 seconds each
How many of you deployed something today? How many of your teams deployed something last week, or will deploy something tomorrow? If you are like most people I meet the answer is you are not deploying often enough.
But we are still taking too long to deploy. Many companies still use the same processes and mindsets as they did with annual releases, it’s just now they do mini waterfalls every month.
So this is the key question that I have for you: What is holding you back from launching your business or that new feature right now? I’m going to share with you 5 tips to avoid taking too long to release.
The first tip is If you have a plan for what you are going to release in the first quarter of next year, then you are wasting time. That is too far into the future for a startup to have any detailed release plans.
Now I love agile methods like Scrum, and I use them all the time. But scrum teaches us to work in 2 week cycles, and often times people then start thinking of multi-sprint release cycles. That is for big companies using Scrum, not you as a startup.
Instead,focus on a strongly prioritized backlog.Don’t plan for items more than 2 weeks ahead and just build and deploy each feature, one at a time. Just deploy it!
Tip 2: If you group together new features, bug fixes, and design changes into big releases, and you don’t get the user reaction you wanted, how do you knowwhich change resulted in positive or negative behavior? Who knows!
Instead, make sure to release code one feature at a time.Think about how you can test that feature and build that test into the code, then Just deploy it … and measure it!
How often have your development teams started with boring stuff like logins and frameworks? When I see the demo of a project’s first sprint, and it’s just a login page, it makes me cry a little bit inside.
Now you might be saying, but I’ll get hacked! You might, but I’m not saying you should post a list credit card numbers on your site, at least not without a login around them! But there is plenty you can test before you put in fancy security.
Instead start with a more important feature or risky assumption, and add in the security and pretty admin site later. Forget about logins and just deploy it!
Tip 4 is to ignore load testing for now. We all imagine this is what will happen the day we launch, but that’s highly unlikely. Sorry to break the bad news!
Instead, wait to load test until you are sure the feature is worth the costs of tools and most importantly your time. Drop the load test FOR NOW and just deploy it!
Finally, I really don’t like the term beta. I’m trying to cut it out of my vocabulary all together, and Google is not helping me. Betas imply a big bang release, delayed validation, and big costs.