Specifically, you can take the time to develop and bring to the table an outside-in, market-centric perspective that is so compelling and so well informed that it can counterbalance the inside-out company-centric orientation of last year’s operating plan.
—Geoffrey Moore, Escape Velocity
Continuous Exploration (CE) is the process of continually exploring the market and user needs, and defining a Vision, Roadmap, and set of Features that address those needs. It’s the first element in the four-part Continuous Delivery Pipeline, preceding Continuous Integration (CI) Continuous Deployment (CD), and Release on Demand.
New features are initially captured and defined during the continuous exploration process. When each feature is ready, it is entered into the Program Backlog, and the continuous integration process pulls the highest priority features into implementation. Thereafter, the continuous deployment cycle pulls the features into the staging or deployment environment, where they are validated and made ready for release.
Inputs to continuous exploration come from Customers, Agile Teams, Product Owners, Business Owners as well as stakeholders, and portfolio concerns. Under the direction of Product Management, various research and analysis activities are used to further define and evaluate the feature. The result of this process is a set of outputs, including the vision, a set of features in the backlog sufficiently defined for implementation, and a preliminary roadmap forecast of how those features might be delivered over time.
SAFe avoids the traditional waterfall approach, eliminating the extensive up-front definition of the work to be done. Instead, it applies a continuous exploration process, providing a consistent flow of new work that is sufficiently ready for the teams to implement. This way, new functionality is available in small batches that can travel easily through continuous integration, continuous deployment, and on to release.
Continuous Exploration Process
The continuous exploration process may be considered to consist of three separate activities—collaborate, research, and synthesize—as can be seen in Figure 2.
To create a compelling and differentiated vision, Product Management enables and facilitates a continuous and collaborative process that solicits input from a diverse group of stakeholders. Primary sources include:
- System Architects/Engineers – System Architects/Engineers have in-depth technical knowledge of the solution and are responsible for understanding it at the system level, as well as its ‘use cases’ and Nonfunctional Requirements (NFRs). So, although it’s natural to view these roles as technically and internally inclined, the most capable—in our experience—also have significant and ongoing customer engagement.
- Customers – By voting with their wallets or their feet, customers are the ultimate judge of value. They’re the most obvious and primary source of input. But a note of caution: Customers are heavily bound to their current solution context, so they are often motivated only to improve things incrementally. In other words: The sum total of customer input does not a strategy make. But failing to meet real and evolving customer needs is an alternate path to extinction. A sense of balance is required. As the SAFe Lean-Agile mindset says, “Producers innovate. Customers validate.”
- Business Owners and stakeholders – Business Owners have the business and market knowledge needed to set the mission and vision. They also have specific responsibilities throughout the development process. A solution that doesn’t meet their expectations is probably no solution at all.
- POs and teams – Product Owners and have some of the foremost experts in the domain. In most cases, they developed the existing solution and are closest to both technical and user concerns. Their input is integral and invaluable.
In addition to this direct input, Product Management uses a variety of research activities and techniques to help establish the vision. These may include:
- Customer visits – There’s no substitute for first-person observation of the daily activities of the people doing the work. Whether structured or informal, Product Managers and Product Owners are responsible for understanding how people actually use systems in their actual work environments. They can’t do that at their desk, so there is no substitute for observing users in their specific Solution Context.
- Gemba walks – Many times, customers are the internal people who implement the operational values streams that our development systems support. In this case, the Gemba walk (‘Gemba’ is the place where the work is performed ) can be used by developers to observe how these stakeholders execute the steps and specific activities in their operational value streams.
- Elicitation – There are a variety of structured elicitation techniques that Product Management and Product Owner professionals use to generate input and prioritize user needs. These include research methods such as interviews and surveys, brainstorming and idea reduction, questionnaires, and competitive analysis. Other techniques include requirements workshops, user experience mock-ups, user personas, review of customer requests, and use-case modeling. [2, 3]
- Trade studies – Teams engage in trade studies to determine the most practical characteristics of a solution. They review numerous solutions to a technical problem, as well as vendor-provided products and services that address the subject area or an adjacent need. Solutions alternatives are then evaluated against the benefit hypothesis to determine which ones are the most effective for a particular context.
- Market research – To broaden their thinking, teams also conduct original market research, analyze secondary research and market/industry trends, identify emerging customer segments, interview industry analysts, and review competitive solutions.
Based on this collaboration and research, Product Management synthesizes their findings into the vision, roadmap, and program backlog. The Program Kanban helps manage this work. The default Kanban states of funnel, analysis, and backlog are good starting points to establish the workflow. Features that make it to the program backlog are ready for Weighted Shortest Job First (WSJF) prioritization to determine which ones should be pulled into Program Increment (PI) planning.
The Lean UX article describes a simple, four-step process for implementing features:
- Define a benefit hypothesis
- Design collaboratively
- Implement a Minimum Marketable Feature (MMF)
- Evaluate the MMF against the hypothesis
And while this model was developed and described in the context of user-facing functionality, it isn’t reserved exclusively for that; all features benefit from this approach. For example, an Enabler feature such as “In-service software update,” might not be user-facing at all, as shown in Figure 3.
With a solid feature definition in hand, the next process, continuous integration, pulls features from the backlog and implements them. In accordance with Lean UX process , each MMF is collaboratively designed, developed, and delivered incrementally. Incremental delivery enables fast feedback that delivers the knowledge teams need to refactor, adjust, redesign—or even pivot to abandon a feature, based solely on real objective data and user feedback. This creates a closed-loop Lean UX process that iterates toward a successful outcome, driven by objective evidence of whether a feature fulfills the hypothesis, or not.
Learn More Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series). Pearson Education.  http://www.innovationgames.com  Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc.  Gothelf, Jeff and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media.
Last update: 25 October, 2017