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 that fosters innovation and builds alignment on what should be built by continually exploring market and Customer needs, and defining a Vision, Roadmap, and set of Features for a Solution that addresses those needs.
During CE, new ideas are raised, refined, and prepared as a list of prioritized features in the Program Backlog. They are pulled into implementation during PI Planning, which begins the continuous integration process. Thereafter, the continuous deployment cycle pulls the features into production, 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 strategic portfolio concerns. Under the direction of Product and Solution Management, 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 roadmap forecast of when those features might be delivered.
DevOps and Release on Demand is one of the five core competencies of the Lean Enterprise. It provides the enterprise with the ability to deliver increasingly valuable solutions to end users with optimal frequency. Continuous exploration is integral to that process and focuses on gaining alignment on new opportunities and what needs to be built, while understanding that all such ideas are hypotheses that need to be validated.
In place of the traditional waterfall approach, CE mitigates the more extensive, and theoretically complete, up-front definition of requirements for 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. New functionality is defined and available in small batches that can travel easily through continuous integration, continuous deployment, and on to release.
Four Sub-dimensions of Continuous Exploration
SAFe describes four sub-dimensions of Continuous Exploration as illustrated in Figure 1:
- Hypothesize – covers the skills necessary to identify ideas, and the measurements needed to validate them with customers
- Collaborate and research – covers the skills needed to work with customers and stakeholders to refine the understandings of potential needs
- Architect – covers the skills necessary to envision a technological approach that enables quick implementation, delivery and support of ongoing operations
- Synthesize – encompasses the skills that organize the ideas into a holistic vision, a roadmap, a prioritized program backlog, and supports final alignment during PI Planning
Create a Solution Hypotheses
New ideas start as hypotheses—one never really knows whether they will work or not. Product and Solution Management have notions of what needs to be developed that originate from their understanding of the marketplace, as well as from the Strategic Themes, and Portfolio Vision and roadmap. These ideas might also be initiated by Portfolio Epics, or alternatively, they might spawn new Portfolio Epics.
Two specific skills contribute to the ability to hypothesize:
- Lean startup thinking – The definition of Minimal Viable Products (MVPs) helps evaluate hypotheses quickly before too much investment has been made. The MVP is the smallest thing that can be built to evaluate whether the hypothesis is valid.
- Innovation Accounting – Evaluating hypothesis requires different metrics than those used to measure end-state working solutions. Innovation Accounting focuses on how to measure the intermediate, and predictive business outcomes of the hypothesis both during initial incremental solution development and evaluation of the MVP. (Read more in the Innovation Accounting article.)
Collaborate and research customer needs
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 as Figure 2 shows. 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). Although it’s natural to view these roles as technically and internally inclined, architects should 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 motivations are often 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 a sure 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 teams have some of the foremost expertise 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.
Six specific skills help drive collaboration and research:
- Lean UX thinking – Lean UX  is a collaborative process of working with stakeholders to define Minimal Marketable Features (MMFs) and validate them quickly with customers. (The Lean UX article provides more information about this process.)
- 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. 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. [3, 4]
- Trade studies – Product Owners and Product Managers often 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. Solution 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, Product Owners and Product Managers also conduct original market research, analyze secondary research and market/industry trends, identify emerging customer segments, interview industry analysts, and review competitive solutions.
Architect the solution
Architects on all levels play an important role in understanding how the architecture drives and enables the continuous delivery pipeline, and in guiding Agile Teams in the design process that will support this. Five skills support this effort:
- Architecting for releasability – Different parts of the solution require different release strategies. The solution must be designed to enable various incremental release strategies and shift them over time based on business demand.
- Architecting for testability – Systems that can’t be easily tested can’t be readily changed. Systems which are designed and architected in a modular way enable continuous testing.
- Separating deploy and release – In order to continuously deploy, the ability to release may need to be separate from the work of deploying to production. This separation requires architectural enablers that will allow functionality to be in production but hidden from Customers.
- Architecting for operations – Operational needs must be considered. Build telemetry and logging capabilities into every application and into the solution as a whole. Allow services to be downgraded or even removed in times of high loads or in response to incidents. Build capabilities for fast recovery and for fix-forward.
- Threat modeling – Information security consideration should start early, identifying threats to proposed architecture, infrastructure, and applications.
Synthesize the vision, roadmap, and program backlog
The most critical alignment activity in SAFe is PI Planning. The inputs to PI Planning are a vision, a roadmap, and a prioritized backlog of features. The synthesis sub-dimension is all about getting these assets ready for PI planning. To accomplish this, six skills are needed:
- Creating the solution vision – The vision serves as the cornerstone for teams to understand the why for the features being developed.
- Maintaining the solution roadmap – The solution roadmap provides a view into the near future for the ART. It helps Product Management prioritize the work, enables System Architects to prioritize the runway, and provides visibility for Business Owners.
- Writing clear features– Defining clear features that fit in a PI is critical for ARTs to align on what is needed and for teams to be able to plan.
- Behavior-driven development (BDD) – BDD fosters collaboration between Product Management, Product Owners, and Agile Teams which clarifies requirements by adding acceptance criteria.
- Economic prioritization – Features must be prioritized for development to be effective. The budget guardrails of capacity allocation, investment horizons, and continuous Business Owners engagement are critical in prioritization.
- PI Planning – This is the culmination of the exploration work as the ART comes together to plan the next PI and gain alignment on what should be done in the next program increment.
When the ART is aligned with what needs to be built, the features move smoothly to the continuous integration segment of the continuous delivery pipeline. However, this does not mean that exploration is over. Feedback is constantly flowing back from developed, deployed, and released features. This feedback informs new decisions about what the ART should work on next and is integral to the CE process.
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: 12 September 2018