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 the process that drives innovation and fosters 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.

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

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 kicks off the continuous integration process. After that, the continuous deployment cycle pulls the features into production, where they are validated and prepared for release.

Details

Agile Product Delivery is one of the seven core competencies of the Lean Enterprise. It gives the enterprise the ability to deliver increasingly valuable solutions to end users with optimal frequency. Continuous exploration is integral to that process and focuses on applying Design Thinking to understand and build alignment on new opportunities and what needs to be built, while recognizing that all such ideas are hypotheses that need to be validated.

CE replaces traditional waterfall approaches of up-front, rigid definitions of requirements with a process that generates a consistent flow of work that is ready for the ART to implement. This flow of work is captured as Features and Stories, defined in small batches that can travel easily through the remaining aspects of the continuous delivery pipeline to the customer. Feedback is built into the process, enabling teams to adjust to market needs.

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 are participating in an Innovation and Planning Iteration. The results of CE activities enable the organization to align to a shared Vision, a set of features in the backlog defined for implementation, and a Roadmap forecast of when those features might be delivered.

The Four Activities of Continuous Exploration

SAFe describes four activities of Continuous Exploration, as illustrated in Figure 2.

• Hypothesize describes the practices necessary to capture ideas and the measurements needed to validate them with customers
• Collaborate and research describes the practices required to work with customers and stakeholders to refine the understandings of potential needs
• Architect describes the practices necessary to envision a technological approach that enables quick implementation, delivery, and support of ongoing operations
• Synthesize describes the practices that organize the ideas into a holistic vision, a roadmap, a prioritized program backlog, and supports final alignment during PI Planning

Create a Solution Hypothesis

From their understanding of the marketplace—as well as from the Strategic Themes, Portfolio Vision, and the Solution Roadmap—Product and Solution Management have notions of what needs to be developed. These ideas, however, should not be considered facts that drive the teams. Instead, they should be considered as hypotheses. We don’t know if our ideas will work. Accordingly, the first set of practices are associated with the ability to leverage hypothesis based development:

• Lean startup thinking – Defining Minimum Marketable Feature (MMFs) and/or Minimum Viable Products (MVPs) helps evaluate hypotheses quickly before making too much investment. Both MMFs and MVPs represent the smallest thing that can be built to evaluate whether the hypothesis is valid.
• Innovation Accounting – Evaluating hypotheses 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 a 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 facilitates a continuous and collaborative process, soliciting input from a diverse group of stakeholders (see Figure 3). 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 that enables them to identify new ways to solve unmet needs.
• Customers – By voting with their wallets or their feet, customers judge value. Accordingly, they’re the most obvious and primary source of feedback on the solution and how well it meets their needs. 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: customer input alone does not a strategy make. But failing to meet current and evolving customer needs is a sure path to extinction, which means Product Management must ensure design thinking processes are leveraged to understand the problem(s) before designing solutions.
• 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 is probably no solution at all.
• POs and teams – Through their work creating the solution, Product Owners and Agile teams create expertise in the domain. 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.
• Gemba walks – An experiential form of primary market research, a Gemba walk (‘Gemba’ is the place where the work is performed [2]) is a process in which the product team observes how stakeholders execute the steps and specific activities in their operational value streams to better identify opportunities for relentless improvement.
• 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 use systems in actual work environments. They can’t do that at their desk, so there is no substitute for “getting outside the building” and observing users in their specific Solution Context.
• Secondary market research – To broaden their thinking, Product Management uses various secondary market research techniques to develop a comprehensive understanding of the customers and markets they’re serving. Staying abreast of market/industry trends is a critical outcome of secondary market research.
• Lean UX thinking – Lean UX [5] is a collaborative process of working with stakeholders to define Minimum Marketable Features (MMFs) and validate them quickly with customers. (The Lean UX article provides more information about this process.)

Conducting research enables the organization to further refine its processes 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 the target customer.
• Building empathy for the user – Empathy maps ensure that the team is considering the full needs of the user and how these needs may be evolving through successive releases.
• Designing the customer experience – Journey maps provide the design link between the operational value stream and the customer’s 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 the solution

With a clear understanding of the problem, CE moves into the solution space, starting with architecture. Architects serve the business and the customer by ensuring the architecture has sufficient Architectural Runway to deliver the required functionality and that the architecture is designed to enable the continuous delivery pipeline. The former is covered in System Architect/Engineering. The latter is supported through five practices:

• 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 designed and architected in a modular way enable continuous testing.
• Separating deployment and release – In order to continuously deploy, the ability to release may need to be separate from the work of deploying to production. This 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 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 fix-forward.
• Threat modeling – Information security considerations should start early, identifying threats to proposed architecture, infrastructure, and applications. And record important security requirements as Non-Functional Requirements to influence backlogs.

Synthesize the vision, roadmap, and program backlog

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 common, shared direction. Synthesis is focused on ensuring these assets are ready for PI planning. To accomplish this, six practices 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.
• Defining a backlog with clearly written features – Clearly defining features that fit in a PI is critical for ARTs to align on what is needed and for teams to be able to plan. The backlog also reflects important security requirements.
• 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 on 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 continually flowing back from developed, deployed, and released features. This 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 continuous delivery pipeline. When they involve large batches, rigid specifications, and commitments to fixed plans, execution is slow. Thus, for ARTs to achieve continuous delivery, these ‘upstream’ activities must 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 continuous delivery pipeline.

Many DevOps related concepts apply at this level. As illustrated in Figure 4, continuous exploration is enabled by SAFe’s CALMR approach to DevOps (center) as well as several practice domains (inner rings). Each of the four activities (in green) is a collaborative effort that draws upon DevOps expertise from multiple domains to maximize delivery speed and quality.

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 so as to maximize delivery speed and solution value.

All four continuous exploration activities are enabled by DevOps, though with different combinations of technical practices and tooling. For more detailed guidance on DevOps and how it enables the continuous delivery pipeline, see the DevOps article series.

---

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] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series). Pearson Education, 2011.

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

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

 

Last update: 27 September 2021