Shorten Feedback Cycles
Part 3 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…
The third problem holding teams back is long feedback loops. Some of us have long feedback loops, while others have no feedback loops at all! And therefore we’re not learning. We’re not getting new information.
Eric Ries’ “The Lean Startup” challenges the way we think about developing products.
Picture two loops happening at the same time. Most of the time we’re focused on the execution loop: How do we execute? How do we deliver software faster? How do we do it with higher quality? How do we shorten feedback cycles? How do we increase productivity?
But there’s another loop we haven’t talked about enough – the product discovery loop. Are we building the right product? What product should we be building? What features should we be building? While both of these are happening at the same time, many times it seems the Product Owner is off on an island and is supposed to just guess what product to build and then the developers iterate on building it over here in the execution loop.
Eric Ries says to think about everything we build as a science experiment, not a requirement. We hear the word requirement and we assume it’s a fixed factual thing. It’s a requirement! But really, a requirement is nothing more than a hypothesis. If we build this thing, we expect that outcome. We got really good at coming up with an idea and building it, delivering the product, going to the next idea. That was our loop. But are we building the right product and features? We should be measuring and learning from it. I like to think of it backwards – What do we need to learn? How are we going to measure that we’re learning? What’s the needle we’re trying to move? What’s the smallest thing we can build or test?
There’s a story about a debate at Amazon where a group is discussing features and initiatives and what’s going to make the most money. Part of the conversation went like this:
"Let's just put a link to the website on the homepage." "But we haven't build the website yet!" "I don't care." "What's it going to do?" "Go to a 404 error."
They did just that and… nobody clicked the link. Do they need to build that feature? No! If people started clicking it, they could take the link down and go build the website. They built a minimal feature, measured its use, and learned that it was not worth investing the time and money to continue building on it.
Indeed has a lot of stories around product discovery in their blog. Last year they recorded a bunch of videos around how they’re doing experiment-driven development. Data-driven development is what they’re calling it. They’re running over 100 experiments at any given time, things are always changing. They’re trying to discover what’s the smallest thing we can build to experiment with and learn from, to validate or invalidate our hypothesis?
Eric Huddleston runs TrendKite. He is a smart dude who says our job is to figure how dumb we are as fast as possible. Because everything we’ve convinced ourselves is right, our “perfect” requirements? Most of those things are wrong and it’s a lot cheaper to figure that out before we’ve written all the code, integrated, tested, and released it. And that’s usually when we find out if we’re wrong… if we ever do.
Next topic in the Double the Value in Half the Time series: Focus!
If you’re still not seeing the value from your Agile investment, you might benefit from an Agile assessment. One of the benefits of an Agile assessment is understanding where teams are now, in terms of key capabilities, so that you can create a backlog (next steps) for your transformation. Go here to learn more about Agile assessments.