Design thinking and continuous delivery are amazing approaches to product innovation. They are not widely discussed in the agile context, but the synergy between them is crucial to build products that people love.
Design thinking is about problem-solving. Companies like Airbnb, Netflix, and Uber used design thinking to form deep understanding of their users and built features to address the user needs.
“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.” — Tim Brown, Executive Chair of Ideo
I like it a lot because it’s inclusive in the innovation process. It starts with understanding the users. The goal is to solve a problem with a solution that’s desirable from the human point of view and technically feasible while capturing market opportunities.
Design thinking follows the flow of understand, explore, and materialize. There are six phases:
As you can see, design thinking iterates through product discovery, testing, and building. You have the flexibility to run it as lean as in just one week with the design sprint, or you can iterate and repeat through the phases until you find your product market fit.
You can read more about the design thinking process:
Now, in engineering, what we want to achieve is to have the infrastructure and workflow to enable such rapid product iterations so that multiple teams can prototype, test, and implement in your product with speed and at scale. This is where continuous delivery can help us.
Continuous delivery puts working software first. It’s a practice to release software quickly, safely, and sustainably.
“Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, without doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production.” — Wikipedia
There are several benefits by integrating continuous delivery. From the DORA State of DevOps research program, which summarizes a 7 years of research on high performance technical delivery and organizational outcomes, we can see a clear benefit in performance and culture. Here’s the screenshot:
The idea is to have an automatic process that builds, tests, analyzes, integrates, and deploys continuously throughout your product cycle. In the case of any error occurring in the process, the process will stop your product changes being integrated in production so that it won’t impact your users. It leads to a greater level of psychological safety that enables us to test our prototypes and collect feedback and data without worrying about breaking the product.
According to the Accelerate State of DevOps 2021, there are several capability factors that serve as indications to software delivery and organizational performance. In this article, I want to highlight a few technical capabilities in the context of agile product development:
You can read more about the concepts, best practices, and KPIs of continuous delivery:
Now that we have discussed both design thinking and continuous delivery, we are ready to see how they can work together to achieve higher speed and code quality.
Continuous delivery comes into the picture in the prototype, test, and implement phase.
Continuous delivery play a part in the prototype, test, and implement phase of design thinking.
Let’s look at the phases separately.
The two most important focuses during the phases are learning and speed. You want to be able to put your prototype in front of your users as quickly as you can to test your ideas and hypotheses so you can design the next iterations based on your learning.
To prioritize learning and speed, we can design the continuous delivery process like this:
We are keeping most of the best practices with a few modifications:
Dirty Pull Requests
✅ Dos
❌ Don’ts
Regression Testing & Continuous Integration
✅ Dos
❌ Don’ts
Analytics and Feature Toggles
When your prototypes are designed for quantitative research, it requires code changes in the product so that you can analyze the data on a larger scale. This is where analytics and feature toggles are useful.
Feature toggles gives you the flexibility to target the user segments for your tests and analytics provides you aggregated data to track your KPIs.
The purpose of feature toggles in these phases is to collect data and learn from the intended user segments. Make sure you don’t use toggles to hide prototypes or features from your users. It defeats the purpose of learning.
When you are in the implement phase, it means that you have tested the prototypes and you are officially going with one of your ideas. Congratulations!
Unlike in the prototype and test phase, we want to prioritize the best practices of continuous delivery over speed:
Stacked Pull Requests
✅ Dos
❌ Don’ts
You can find more about the best practices for pull request authors and reviewers:
Continuous Testing and Continuous Integration
✅ Dos
❌ Don’ts
Design thinking provides us a human-centric framework to iterate on product innovation, whereas continuous delivery creates a effective and predictable baseline to protect the code quality.
Code quality often lose its priority to lead time in many companies. By following design thinking, we are able to ideate and test the prototypes quickly to learn about the market and users. By integrating continuous delivery, we have a technical capability to collaborate and test on a large scale without breaking our products.
This article is originally posted on Daw-Chih’s website.