Rapid Product DevelopmentSTOP GUESSING AND START DELIVERING!
Zach BeerPolaris Solutions
Why this guy?•Ten years working in Chicago-based start-ups•I’ve held nearly every role in a development team• Developer• Tech lead / manager• Architect• Product owner• Scrum master
Most of all, though: Because I’ve lived it and know it works.
Some quick disclaimers… We’re going to talk a lot about customers. Customers are people
invested in using your product. They could be internal or external. We’re going to assume you’re building on an existing product. If
you’re starting from scratch, a lot of the same ideas apply, but you’ll want to tweak them somewhat.
We’re going to talk about a process pattern that depends on a number of other ideas. I’m not going to go into significant depth on any of those as part of this presentation.
While I encourage you to do so, you don’t have to do all of these things. Each of them has value even outside of the larger pattern.
I’m happy to discuss any of these in greater depth after the presentation!
I believe we can serve our customers better.
How did this happen?
The product owner failed to understand the needs of the customer
Few opportunities to learn from the customer Forced to take a stab in the dark
Manufacturing requires waterfall product development.
What do you mean by “waterfall product development”?
All requirements determined up front
Little opportunity to respond to changing information
Only one opportunity at delivery
Why is waterfall product development problematic?
Scopes constantly change No customer feedback until the
project is complete Sometimes the problem
changes during development Any mistakes aren’t caught
until the end
Customers can’t help us directly
Customers are great at… … pointing out pain points. … giving lists of things they think they need. … adapting to change.
Customers struggle with… … thinking in limited scopes. … prioritizing what’s most important. … being open to change.
We don’t know what to build either
We crave positive feedback We don’t want to tell the customer “no” We think that we understand the customer
better than we do Manufacturing culture tells us we must build
the whole thing at once
I believe we can learn from our customers’ actions.
Continuous feature improvement!
1Determine the narrowest vertical slice that can add value to the customer.
2Deliver this slice as soon as possible, event if the feature isn’t “complete”.
3Learn as much as possible from each delivery.
4Repeat!
Choose the right slice to deliver
How can I add value to the customer quickly? Is this where the users spend most of their time? How can I unblock other critical deliveries? This is a significant technical challenge, is there a way to prove
its value?
For example, think about a user management system…
User management requirements
Before narrow vertical slices Add a page to our website which allows
administrators to view, add, and reset passwords for existing users
After narrow vertical slices Add a page to our website which allows
users to view existing users Restrict access to the view users page
to administrators Add ability to add users to the existing
view users page Add ability to reset passwords to the
view users page
Develop critical feedback loops
A/B testing can inform critical (or trivial!) choices
Actively engage with users about specific changes
Tracking tools help you see which features users are engaging with
Heat maps can show where users are focused
Observing recorded user interactions can point out pain points
Creating this way feels difficult…
We’re culturally programmed toward the manufacturing model
We’re praised for our “good ideas” We want our customers to be fully satisfied immediately
… but it’s actually easier!
You have to know less to get started You learn details as you go along Smaller mistakes are much easier to recover from You can focus on the most important things Customers focus on progress
I believe this process will make developers happier.
Development is easier with feature branching
What is feature branching? Create a branch for each feature Only merge completed featuresWhy is it helpful? Developers can work in parallel Collaboration is easier, since
developers can share branches Branches can be tested before
being integrated Releases only contain completed
features
Automated testing gives developers confidence in releases
Create well-written unit tests Choose critical behavior-driven tests Manual test only the newest release items
Automated delivery makes reduces the pain of releases
Run automated tests on each build
Automate deployment to test environments
Automate release approval Automate release deployment
Even positive change is difficult
Old practices die hard Existing team members may need training Developers might complain about writing “more code” Introducing testing into legacy systems can be
challenging
Eventually, teams never look back
The most common long term complaints I hear are: “This story feels too big, can we break it up?” “Who checked in a broken test? All our tests should
pass.” “Why does the release take so long now? Five minutes is
forever!” “How soon can I push this to production?”
I believe we can serve our customers better.
So if the car was a software feature…
#1 Determine the narrowest vertical slice that can add value to the customer
We want to build toward a convertible top We identify that switching to a two door model is a requirement
for introducing a convertible top Theoretically, this could add value to the customer It would also give us customer feedback
#2 Deliver this slice as soon as possible, event if the feature isn’t “complete”
Don’t develop the convertible mechanism, it’s expensive and it’s not needed yet
Find the simplest way to achieve the two door model Ensure the two door model works correctly before shipping Deliver the two door model to customers as soon as is practical
#3 Learn as much as possible from each delivery.
Only ship the two door model to a limited set of users Preferably select users who demonstrated interest Monitor these selected users carefully after delivery Compare these selected users to other existing users, are they
more satisfied? Gather real data about our test users compared to existing users
#4 Repeat!
Presumably, our comparison didn’t go so well! Stop the development of the convertible, customers aren’t willing to
compromise on four vs two doors How much time/energy/effort did we save by shortcutting the process?
Get started on the next most valuable slice!
Thanks for listening!