In this article, I explain what Continuous Exploration is within the SAFe DevOps Health Radar and why it is essential for building the right thing in the right way. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out of this toolbox what fits your needs and what solves your problems.
What Is Continuous Exploration?#
Continuous Exploration is the first dimension in the SAFe DevOps pipeline. It is where all the bright ideas from customers and the business side come in. We transform these ideas into epics with a clear hypothesis statement, conduct market and customer research to understand the real problems, define a minimal architecture that proves the hypothesis, and finally create a vision, a roadmap, and a clear set of features that address customer needs.
The goal is simple: we need real alignment between all stakeholders about which hypotheses should be validated and what should actually be built.
Why Continuous Exploration Matters#
One of the biggest problems organizations face is wanting to build too much. Teams often do not identify which things have real value and which things should truly be built. This leads to overloading the entire system with work that does not deliver significant value.
Continuous Exploration solves this problem by defining a clear process for how ideas are transformed into epics, how customer needs are identified, how a minimal architecture is defined, and how those ideas are split into features ready for development. The result is that we are able to build the right thing right.
The Four Activities of Continuous Exploration#
Continuous Exploration consists of four activities: Hypothesize, Collaborate and Research, Architect, and Synthesize.
Hypothesize#
Everything starts with ideas from customers and the business. In the hypothesize activity, we take these ideas and create epics with a clear hypothesis statement behind them. This hypothesis defines what we believe will deliver value and what we want to prove.
Collaborate and Research#
With our epics and their hypotheses defined, we move into market research and customer research. We interview customers, identify their real needs, and try to understand the actual problem that should be solved. This step ensures we are not just building what someone asked for, but solving the real underlying problem.
Architect#
Once we understand the real customer needs, we define the minimal architecture needed to prove the hypothesis. This is not about building the complete final architecture. It is about identifying the simplest architectural approach that allows us to validate our hypothesis.
Synthesize#
At this point, we have identified the real customer needs, have a clear hypothesis, and have defined a minimal architecture to prove it. In the synthesize activity, we create a vision, a roadmap, and a clear set of features that go into our prioritized program backlog. This is the output of Continuous Exploration and the input for Continuous Integration.
How Fast Is This Process?#
One of the questions I get asked most frequently is: how long does Continuous Exploration take? The answer is simple: it depends.
Some items may go through Continuous Exploration within hours. Others may take days, and some will take weeks. What would be wrong is if Continuous Exploration takes months or even years. That would be a problem.
It is also important to understand that Continuous Exploration is not a three-month cycle just because there is PI Planning. We do not do three months of Continuous Exploration, then have everything in PI Planning, and then start another three-month cycle. It is a continuous process.
Concrete Examples#
A Simple Customer Request#
A customer gives feedback saying that changing a small filter in the application to reverse the order would have massive value for them. This request goes very quickly through hypothesize (the hypothesis is straightforward), through collaborate and research (we quickly verify the customer need), through architect (the minimal architecture is simple), and into synthesize where it lands on the backlog. This entire process might only take hours.
A Bug#
A bug comes in and we go into hypothesize. Here it is very important to analyze the bug. A small bug will move quickly, but a huge bug that changes the complete business logic requires careful analysis. In collaborate and research, we need to determine whether this bug relates to a missing customer need or an unaddressed problem. We might discover this is not really a bug but requires a new feature. In architect, we analyze the impact of fixing the bug and whether we need to change the architecture. Finally, in synthesize, we create either a bug fix or a new feature for the backlog.
A Huge Epic#
Imagine we hypothesize that creating a new product on our website would increase the number of users buying that product by 10%. This is a huge epic with a significant hypothesis, and we need to define the minimum viable product to prove it. In collaborate and research, we study market needs, ask customers, and perhaps create paper prototypes to validate the hypothesis. We analyze the simplest way to prove it. In architect, we determine the minimal architecture required. In synthesize, we may need to adapt the vision and roadmap, and we create new features for the backlog. This process could take weeks.
The Output of Continuous Exploration#
After Continuous Exploration, we have:
- A clear vision, or an adapted or unchanged vision
- A clear set of features in our prioritized program backlog
- Enabler features for the architectural runway that enable us to deliver more business value
- An adapted or new roadmap
It is also worth noting that information gathered during Continuous Integration, Continuous Deployment, or Release on Demand can flow back into Continuous Exploration. New ideas, bugs, or insights from production feed back into the cycle. This is the incremental, continuous nature of the entire DevOps pipeline.
Continuous Exploration is all about getting alignment between stakeholders so that we identify which hypothesis brings us the biggest value. This way, we can determine what we need to build and ensure we build the right thing right.