Hypothesis-Driven Development Can Revolutionize Agile

Agile’s flexible, well-structured philosophy makes it easier for developers to tackle projects in bite-sized chunks. But Agile, it turns out, is only half of the development coin. As University of Virginia Darden business professor Alex Cowan explained in a recent Zenhub webinar, while Agile and Scrum tell you how to build something, they don’t help you figure out what you’re going to build.

While building without a plan is excellent for freeform Lego, it’s not great for software development. As Alex noted, when developers “design things and hope for the best,” it usually doesn’t work out. After all, an excellent development process doesn’t count for much if you’re making something nobody wants or needs. That’s where Hypothesis-Driven Development comes in.

Alex explained that Hypothesis-Driven Development is the yin to the yang of Agile practices because it helps determine what you’re going to build. With Hypothesis-Driven Development, you first identify a possible need, then find out if it’s something your end-users actually need. This process remains useful throughout product development in five key areas: continuous design, application development, the delivery pipeline, deployment, and post-deployment.

Continuous design helps ensure success

The Agile process is iterative. You build, evaluate, test, build more, and rinse and repeat that process until you have something functional and useful. But if you don’t take an iterative approach to that iterative approach at the very beginning of the design process, your team can run into the same types of pitfalls they’re using Agile to avoid.

As the diagram above shows, the core principle of Hypothesis-Driven Development is to link the right solution to a problem. Every project, after all, starts with an idea: I have a user with problem X that can be solved with solution Y. But while the problems and jobs of your end-users stay very stable over time, how they do those jobs and solve those problems changes drastically.

Maybe there’s already a solution out there, or some other factors have changed and made that problem not such a big deal anymore, and other issues are now a higher priority. So even if issues are static, design can’t be.

The key is not to assume you have the right solution to a problem. Question the assumption. And be willing to give up on an idea in favor of a better one.

“By discarding ideas earlier, you give yourself more chances to be successful with the same amount of time and energy.” – Alex Cowan

Focus your application development on what truly matters to the end-user

Hypothesis-Driven Development also streamlines application development, enabling developers to concentrate efforts on fewer better applications. By reducing the number of features in the development pipeline, Hypothesis-Driven Development frees up time and energy that can be used to refine and focus on only those features that matter.

Ultimately, you probably end up with the same number of useful features. But focusing on the right ones from the start means features are that much better when they enter the delivery pipeline. This can save your team some soul-crushingly tedious work.

Streamline your delivery pipeline with automation

Unfortunately, bugs, glitches, and tech debt are facts of life, so we can’t eliminate the automated test process entirely. But although most developers love automation, they hate automating. So, building an automated test is one of those boring-but-necessary jobs that we all procrastinate as much as we possibly can, like folding laundry.

Hypothesis-Driven Development reduces the anxiety units. It helps you hone in on where automated tests are helpful because the only thing worse than finishing a tedious job is finding out afterward that it was totally unnecessary. Hypothesis-Driven Development ensures you pick the right problems to automate testing for, which is critical to working efficiently in agile and preserving your team’s sanity.

Optimize deployment by weighing the value of new features

Hypothesis-Driven Development makes it easier to compare the cost of delivering a feature against its value at the deployment stage. This diagram shows how to map that comparison.

Obviously, this approach wants returns to exceed costs, and a critical portion of the cost evaluation is deployment. Different deployment tools offer distinct advantages. More powerful and customizable tools require experienced teams, whereas back-end-as-a-service tools ease deployment but offer less customization. Using the Hypothesis-Driven Development comparison process can help you determine which tool fits better and provides the best return for your team’s skills.

Figure out where to go next in post-deployment

Post-deployment, Hypothesis-Driven Development can help you determine whether your application meets end-user needs and to what degree, so when the next design phase rolls around, your team already knows what to tackle.

A Hypothesis-Driven Development approach starts by looking at how much people are using the application: how many different people, how often, how regularly, etc. From there, it focuses on asking questions about how useful it is. Do people stick with it, or are most uses short-term? Where does it work well? Where does it work not-so-well?

Questions and metrics must be clear and precise to be useful. “Do you like it?” probably won’t bring back any actionable answers. “How often do you use X feature, and what might make you more likely to use it more?” probably will.

This approach can take a team from a not-so-useful goal like “make the app better” to something actionable like “most technicians that aren’t using the app say it’s because the layout is too intimidating.” The first goal is an existential crisis; the second is an afternoon’s work.

Implement Hypothesis-Driven Development into Agile by using Hypothesis-Driven Development and Agile

Trying to implement Hypothesis-Driven Development all at once is a bit like trying to complete a project all in one go in Agile. It’s a contradiction in terms.

So, as Alex noted in the webinar, the best way to implement Hypothesis-Driven Development into Agile is by using these philosophies and Agile methods together. Look at your product pipeline. Sketch it out. Talk to your team about it. Pick one place to start and take it from there.

“What you’ll find is that, after you do that once or twice, it’ll breathe its own air,” Alex said. Refine and continually evaluate what’s working and what isn’t. Come up with new ideas and test them before implementing them more broadly.

Want to learn more? Watch the full webinar for plenty more insights.

Curious about other ways to help your team stay focused? Check out our eBook on Focus-Driven Development.