{"id":9908,"date":"2021-03-23T18:55:14","date_gmt":"2021-03-23T13:25:14","guid":{"rendered":"https:\/\/www.konstantinfo.com\/blog\/?p=9908"},"modified":"2021-03-23T19:01:48","modified_gmt":"2021-03-23T13:31:48","slug":"hypothesis-driven-development","status":"publish","type":"post","link":"https:\/\/www.konstantinfo.com\/konstant-blog\/hypothesis-driven-development\/","title":{"rendered":"Citing Resonant Steps for Hypothesis-Driven Development"},"content":{"rendered":"

Working on experimenting with the union of people, processes and products to enable continuous delivery of value to our customers, the hypothesis-driven development accentuates the importance of delivery of value. How does it work? Let’s find out!<\/p>\n

Process-Driven Delivery<\/strong>: We used process-driven delivery during the waterfall model to deliver value towards the end of the development lifecycle. One release with multiple features is best deployable when there is time to plan.<\/p>\n

Being Agile<\/strong>: Introducing an Agile development approach allows us to deliver without worrying about the result. Plus, the developers do not have to wait till the project deployment stage to anticipate the results. They learn simultaneously.<\/p>\n

Deploying Features Based on Feedback<\/strong>: Now, if we have multiple releases with an improved set of features, we can re-deploy features based on feedback; after every release. Here we are focused on our stakeholders and are delivering continuously.<\/p>\n

Deployment Rings<\/strong>: Alternatively, we use deployment rings and feature flags to limit the impact or confirm feature changes in production. Here we calculate the blast radius via observation, testing, diagnosis, telemetry and user feedback. We conduct experiments to accomplish this.<\/p>\n

Here we progressively expose, test, enable\/hide features, tweak releases and continuously swivel on learnings and feedback. When we add feature flags to workflow, the features toggle ON (enables and expose) or OFF (hidden). We calibrate the features (value) of each release after deploying to production. (Note: Here, Impact = Blast)<\/p>\n

The ring-based deployment<\/strong> limits the impact on users as the app evolves with new features. Every subsequent ring allows deploying features progressively. Multiple releases run in parallel.<\/p>\n

Feature Flags<\/strong>: \u00a0Feature flags separate release deployment, features, emergency rollback, resets a flag, using rules to hide features, toggle preview features.\u00a0 It progressively deploys a release through rings and uses feature flags to calibrate deployable release;<\/p>\n

Coalescing Hypothesis-Driven Development to the Mix<\/h2>\n

The hypothesis is a series of experiments to achieve a potential result. It delivers a measurable conclusion, enables continuous feedback and enables us to understand an evolving landscape, and exposes value progressively. It validates viable ideas and expatiates falsifiable features. This process works in iteration, illustrating identifiable results at every stage.<\/p>\n

The hypothesis-based approach encompasses performing iterations instead of a single monolithic solution. As an example \u2013 we believe a “business” wants “product features” to accomplish a “value proposition”;<\/p>\n

A value proposition brings user satisfaction, user engagement, an increase in business profitability, measurable growth.<\/p>\n

Every experiment with True, false or condition basis hypothesis. Every hypothesis comes with a measurable conclusion, contributing to feature and overall product learning. Primary points to consider here:<\/p>\n