When Aaron Foster Breilyn (AFB) and I discussed continuous delivery, we explained that the goal of continuous delivery is to give the product team the confidence that with every commit they can push new software live into production.
To do so requires smaller, more frequent releases. And deploying at high frequency, with high confidence, depends on more testing and tighter integrations. In this post, I share more detail about how to employ a user-driven approach to tighten the feedback loop.
Testing product hypotheses
Software development professionals source ideas from all sorts of places – executives, users, customers, dev teams, etc. Regardless of the source, it is in the business’s best interest to view each idea as a hypothesis and test its value for users accordingly (This recommendation is straight out of The Lean Startup by Eric Ries.)
If something is valuable to users, it is more than likely valuable to the business. Getting feedback from customers to decide whether a feature will drive the decided-on business metric (usually revenue) requires product teams to get that feature in front of customers, and the faster, the better.
This user-driven approach to feedback is a well-thought-out practice in the industry. But not all teams understand how to implement it.
One of the biggest challenges enterprises face in effectively implementing Agile practices is making a mindset shift. This is especially true in larger, more established companies, but I’ve run into teams that still use the traditional waterfall method for product development in all sizes of organization.
We know Agile works. But what is sometimes a barrier to change is getting a team to truly grasp that Agile software development depends on taking a user-driven approach. It means eliminating the tendency to build heavy product architecture based on market research and instead starting with: What do my users want and need? And how can I get that out the door quickly?
Depending on the maturity of the organization, this might mean using paper prototypes or it might mean split testing against gross sales. Regardless, moving away from long lead times for development and focusing on tightening the feedback loop will allow teams to better predict the value that a release will provide to customers.
My colleague, Alice Toth, has created a series of posts on Stride’s Design Process, which explains the steps of user-centric design from a new product point of view. The fundamentals are the same whether for a new or existing product, though – developing software that provides user value, measured through user feedback, is the crux of successful Agile.
CI/CD supports faster feedback loops
The fundamentals of Agile are about shortening the feedback loops. Testing software scientifically – with both control and variable groups – in a statistically meaningful way depends on fast feedback loops. Through testing, teams can quickly decide whether functionality is worthy of release or additional investment.
However, that is only possible if the team is capable of pushing out software in small chunks, then either killing or promoting it based on feedback (CI/CD).
Just as Agile development improves software, the iterative approach also improves Agile processes themselves. Implementing CI/CD helps streamline and tighten the feedback loop, helping your business provide greater value to users faster.