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

Continuous Exploration (CE) is an aspect of the Continuous Delivery Pipeline that drives innovation and fosters alignment on what should be built by continually exploring the market and customer needs, defining a vision, roadmap, and set of features for a solution.

Continuous Exploration (CE) is the first aspect of the four-part Continuous Delivery Pipeline (CDP), which also includes Continuous Integration (CI), Continuous Deployment, and Release on Demand (Figure 1).

Figure 1. Continuous exploration in the context of the CDP
Figure 1. Continuous exploration in the context of the CDP

During CE, new ideas are raised, refined, and prepared as a list of prioritized Features in the ART Backlog. Agile Teams implement the features prioritized by Product Management during PI Planning, which kicks off the CI process. After that, the CD cycle pulls them into production, where they are validated and prepared for release.

Details

Agile Product Delivery is one of the seven core competencies of SAFe. It allows the enterprise to deliver increasingly valuable solutions to end users with optimal frequency. CE is integral to that process and focuses on applying Customer Centricity and Design Thinking to understand and create alignment on new development opportunities while recognizing that all such ideas are hypotheses that need to be validated.

CE replaces traditional waterfall approaches of up-front, rigid requirement definitions with a process that generates a consistent flow of Features ready for implementation in the ART Backlog. Decomposing features into small batches of Stories enables work to move quickly through the remaining aspects of the CDP to the Customer. Getting fast feedback is built into the process, allowing the teams to adjust to market needs. See the ART Flow article for more information on making value flow without interruption (Principle #6 – Make value flow without interruptions).

Customers, Suppliers, partners, Business Owners, Agile Teams, Product Owners, and Lean Portfolio Management are among the internal and external stakeholders involved in this process. Their involvement may be indirect, such as through secondary research on market needs. Or it can be direct, as when Agile Teams participate in an Innovation and Planning Iteration. CE activities enable the organization to align to a shared Vision, a set of features in the backlog defined for implementation, and a forecasted Roadmap.

The Four Activities of Continuous Exploration

Figure 2 illustrates the four steps of continuous exploration, described in the following sections.

Figure 2. Four activities of Continuous Exploration
Figure 2. Four activities of continuous exploration

Hypothesize

Hypothesize describes the practices for generating ideas and the measurements needed to validate them with Customers. Its primary purpose is to define a Solution hypothesis that teams will validate through the CDP.

Product Management has notions of Customer needs based on their understanding of the marketplace, Strategic Themes, Portfolio Vision, and Roadmap. However, these ideas should not be considered facts. Instead, teams should consider them a hypothesis that needs to be tested and proven. Accordingly, the practices associated with hypothesis-driven development include:

  • Lean startup thinking – Defining Minimum Marketable Features (MMFs) and Minimum Viable Products (MVPs) [1] helps evaluate hypotheses quickly with minimal investment. MMFs and MVPs represent the smallest amount of usable functionality for early customers, who can provide feedback for future product development.
  • Innovation accounting – Evaluating hypotheses for a new product or feature requires a different approach than measuring existing solutions. It requires us to consider two questions: 1) Are we progressing toward our outcome hypothesis? 2) How do we know? Innovation accounting uses actionable metrics (leading indicators) for determining early results and is a good predictor of future business outcomes. Leading indicators answer these two questions and improve economic decisions during initial solution development and evaluation of the MMF or MVP.

Collaborate and Research

Creating a compelling and differentiated vision requires Product Management to facilitate a continuous and collaborative process, soliciting input from diverse stakeholders, as illustrated in Figure 3.

Figure 3. Product Management collaborates with multiple stakeholders to refine requirements
Figure 3. Product Management collaborates with multiple stakeholders to refine requirements
  • System Architects – System Architects have in-depth technical knowledge of solutions. They are responsible for understanding them at the system level and their 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 that enables them to identify new ways to solve unmet needs.
  • Customers –Customers judge value by voting with their wallets or feet. Accordingly, they’re the primary source of feedback on the solution and how well it meets their needs. But a note of caution: customer motivations are often heavily bound to their current solution context, so they are often motivated only to improve things incrementally. In other words, customer feedback alone does not constitute a product strategy. But failing to meet current and evolving customer needs is a sure path to failure.
  • Business Owners and stakeholders – Business Owners have the business and market knowledge needed to set the mission and vision. A solution that doesn’t meet their expectations likely has no value.
  • POs and teams – Product Owners and Agile Teams create domain expertise through their work creating the solution. In many cases, they are closest to both technical and user concerns. Their input is integral to the ongoing evolution of the solution.

Collaboration and research are grounded in specific practices:

  • Primary market research – Product Management develops additional insights through primary market research, including surveys, focus groups, questionnaires, and competitive analysis for customer understanding.
  • Customer visits and Gemba walks – A Gemba walk [2] or customer visit is a process where the product team observes how stakeholders execute the specific activities in their operational value streams to identify opportunities for relentless improvement. 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 need to understand how people use systems in their work environments. They can’t do that at their desk, so there is no substitute for “getting outside the building,” visiting customers, and observing users in their specific Solution Context.
  • Secondary market research – To broaden their thinking, Product Management uses various secondary market research techniques to understand the customers and markets they’re serving comprehensively. Staying abreast of market/industry trends is a critical outcome of secondary market research.
  • Lean UX thinking – Lean UX [3] is a collaborative process of working with stakeholders to define Minimum Marketable Features (MMFs) and validate them quickly with customers.

Collaborative research enables the organization to refine its processes further and create artifacts that clearly express its emerging understanding of the problem space. These include:

  • Developing personas to focus design – Informed by research, personas help the organization understand their target customers
  • Building empathy for the user – Empathy maps ensure that the team considers the user’s needs and how they may evolve through successive releases
  • Designing the customer experience – Customer journey maps provide the design link between the operational value stream and the Customer’s user experience

While these artifacts tend to be relatively stable over successive releases, the entire enterprise must find ways to avoid making strategic decisions on stale insights.

Architect

With a clear understanding of the problem, CE moves into the solution space, defining the minimum amount of architecture that will support the Solution and enable continuous delivery.

Architects serve the business and the Customer by ensuring the Architectural Runway is sufficient to deliver the required functionality and is designed to enable the Continuous Delivery Pipeline (CDP). System Architects support the CDP through five practices:

  1. Architecting for releasability – Different parts of the solution require distinct release strategies. Therefore, design solutions to enable various incremental release strategies and evolve them over time based on business demand.
  2. Architecting for testability – Systems designed and architected modularly enable continuous testing.
  3. Separating deployment and release – The capability to deploy continuously requires architectural enablers that allow functionality to be moved into production but hidden from Customers.
  4. Architecting for operations – Build telemetry and logging capabilities into every application and solution to meet operational support needs. Allow services to be downgraded or even removed during high loads or in response to incidents. Build capabilities for fast recovery and fix-forward.
  5. Threat modeling – Information security considerations should start early, identifying threats to proposed architecture, infrastructure, and applications. Capture essential security requirements as Nonfunctional Requirements to influence backlogs.

Synthesize

Synthesize distills the knowledge gained into a new future state for the solution. The vision, roadmap, and prioritized backlog of features align the ART’s teams to a shared direction. Focus synthesis on ensuring these assets are ready for PI planning. The following practices are needed to accomplish this:

  • Creating the solution vision – The vision provides the reasons or purpose for developing new features.
  • Maintaining the solution roadmap – The ART roadmap provides a view into the near future, helping Product Management prioritize the work, enabling System Architects to prioritize the architecture, and providing visibility for Business Owners.
  • Defining a backlog with clearly written items – Defining features that fit in a PI is critical for ARTs to align on what is needed and for teams to plan. The backlog also reflects essential security requirements.
  • Behavior-driven development (BDD) fosters collaboration between Product Management, Product Owners, and Agile Teams, which clarifies requirements by adding acceptance criteria.
  • Economic prioritization – Prioritized features enable effective development. The budget guardrails of capacity allocation, investment horizons, and continuous Business Owners engagement are critical in prioritization.
  • PI Planning – The exploration work done by the ART is an essential input to the following PI planning event and helps with alignment.

Where there’s alignment on what needs to be built, features smoothly flow to the CI segment of the CDP. However, this does not mean that exploration is over. Feedback is continually flowing back from deployed and released features. This feedback informs new decisions about what the ART should work on next and is integral to the CE process.

Enabling Continuous Exploration with DevOps

Activities in continuous exploration set the pace for the entire CDP. Execution is slow when they involve large batches, rigid specifications, and commitments to fixed plans. Thus, for ARTs to achieve continuous delivery, these ‘upstream’ activities should be driven by a bias for speed and validated learning. Applying DevOps thinking, practices, and tooling early in the value stream reinforces all SAFe principles, aligns the entire ART to a DevOps mindset, and primes the CDP.

Many DevOps-related concepts apply at this level. Figure 4 illustrates SAFe’s CALMR approach to DevOps (center) and practice domains (inner rings) support CE. Each of the four activities (in green) is a collaborative effort that draws upon DevOps expertise from multiple disciplines to maximize delivery speed and quality.

Figure 4. DevOps enables continuous exploration
Figure 4. DevOps enables continuous exploration

For example, architecting for continuous delivery is not a one-dimensional activity. It crosses several disciplines, as Figure 4 suggests. Agile architecture must account for desired quality and security levels, align to value stream performance objectives, produce tangible configurations under version control, and generate backlog items and NFRs that support Agile planning and emergent design. Moreover, the CALMR mindset should guide all architectural decisions and actions to maximize delivery speed and solution value.

All four CE activities are enabled by DevOps, though with different combinations of technical practices and tooling.

Learn More

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc, 2011.

[2] Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc, 2019.

[3] Gothelf, Jeff, and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media, 2016.

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series). Pearson Education, 2011.

Last update: 06 January 2023