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

Agile Product Delivery

Agile Product Delivery is a customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users.

It is one of the seven core competencies of the Lean Enterprise, each of which is essential to achieving Business Agility. Each core competency is supported by a specific assessment, which enables the enterprise to assess their proficiency. These core competency assessments, along with recommended improvement opportunities, are available from the Measure and Grow article.

Why Agile Product Delivery?

In order to achieve Business Agility, enterprises must rapidly increase their ability to deliver innovative products and services. To be sure that the enterprise is creating the right solutions for the right customers at the right time, they must balance their execution focus with a customer focus. These capabilities are mutually supportive and create opportunities for sustained market and service leadership. As illustrated in Figure 1, there are three dimensions to agile product delivery.

Figure 1. Three Dimensions of agile product delivery
  1. Customer Centricity and Design Thinking – Customer centricity puts the customer at the center of every decision and uses design thinking to ensure the solution is desirable, feasible, viable, and sustainable.
  2. Develop on Cadence; Release on Demand – Developing on cadence helps manage the variability inherent in product development.  Decoupling the release of value assures customers can get what they need when they need it.
  3. DevOps and the Continuous Delivery Pipeline – DevOps and the Continuous Delivery Pipeline creates the foundation that enables Enterprises to release value, in whole or in part, at any time to meet customer and market demand.

The sections that follow describe each of these dimensions of agile product delivery in greater detail.

Customer Centricity and Design Thinking

Customer centricity is a mindset and way of doing business that focuses on creating positive engagements as customers experience the products and services the enterprise offers. Customer-centric businesses create greater profits, increase employee engagement, and more thoroughly satisfy customer needs. Customer-centric governments and nonprofits create resilience, sustainability, and the alignment needed to fulfill their mission.

Lean-Agile Enterprises accomplish these goals by applying Design Thinking, an iterative solution development process that ensures solutions are desired by customers and users while also ensuring the solution is feasible, economically viable, and sustainable throughout its lifecycle.

Agile Product Management serves as the central coordinating function for bringing new solutions to market while also ensuring the ongoing success of existing products.

Customer Centricity

Whenever a customer-centric enterprise makes a decision, it deeply considers the effect it will have on its end users [1]. This motivates teams to:

  • Focus on the customer – Customer-centric enterprises use market and user segmentation to align and focus the enterprise on specific, targeted user segments.
  • Understand the customer’s needs – Customer-centric enterprises move beyond merely listening to customers who ask for features. Instead, they invest the time to identify customer needs and build solutions that address these needs.
  • Think and feel like the customer – Customer-centric enterprises are empathetic, and endeavor to see the world from their customer’s point of view.
  • Build whole product solutions – Customer-centric enterprises design a complete solution for the user’s needs, ensuring that the initial and long-term experience(s) of the customer is optimal and evolves as needed.
  • Create customer lifetime value – Customer-centric enterprises move beyond transactional mentality and instead focus on the total relationship with a customer over the natural life of the solution. The resulting long-term customer relationship enables the enterprise to create customer value, often in ways that were not anticipated when the solution was first released [2].

Design Thinking

Design thinking is integral to customer centricity. Design thinking has two main activities, that culminate in a sustainable solution, as shown in Figure 2:

  1. Understanding the problem, which provides insight into the requirements and benefits of a desirable solution
  2. Designing the right solution, which ensures the solution is technically feasible
  3. Ensuring the solution is viable and sustainable by understanding and managing solution economics
Figure 2. Design Thinking Activities

Employing Design Thinking throughout the solution lifecycle assures these three attributes persist for the life of the solution.

Develop on Cadence; Release on Demand

Customer-centric enterprises seek to create a continuous flow of value to its customers. The timing of these releases are determined by market and customer needs, and the enterprise’s own motivation to provide value. Some enterprises may release extremely frequently, while others may be constrained by compliance or other market requirements that motivate less frequent releases. Collectively, SAFe refers to these capabilities as Release on Demand.

Release timing, however, does not coincide with the workflow of the people creating solutions. Teams apply a process model that is optimized for highly variable knowledge work. In SAFe, this is known as Develop on Cadence, a coordinated set of practices that support Agile Teams by providing a reliable series of events and activities that occur on a regular, predictable schedule [3]. Decoupling the events and activities that support the organization creating value from how that value is delivered further promotes Business Agility (Figure 3).

Figure 3. Develop on Cadence; Release on Demand

Agile Team and Agile Release Train Cadences

SAFe’s cadence structure supports Agile Teams and Agile Release Trains (ARTs) in creating and delivering value.

  • Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox in which Agile Teams deliver incremental value. For Agile teams, these are typically working software and hardware, while business teams will provide other aspects of value. A typical timebox duration is two weeks. However, slightly shorter or longer timeboxes may be useful. Iterations are well structured and follow a consistent cycle of Iteration Planning, Iteration Execution (which includes a daily-stand-up and backlog refinement), Iteration Review, and an Iteration Retrospective.
  • Program Increments (PIs) are a larger timebox, a set of iterations during which a group of Agile Teams organized into an ART deliver incremental value, in the form of working, tested software and systems. PIs are typically established as a fixed 8 – 12 weeks period, comprised of 3 – 5 development Iterations, followed by one Innovation and Planning (IP) Iteration.

Program Increments are further organized to include additional cadence-based events and activities that promote Business Agility.

Working in Program Increments

Program Increments are the key to creating a cadence-based enterprise. They represent a timebox ‘big enough’ to plan and accomplish substantial work while being ‘small enough’ to promote fast feedback and mid-course correction. Accordingly, a Program Increment has several important activities and events:

  • Program Increment (PI) Planning is the most significant cadence-based event of the enterprise. PI Planning serves as the heartbeat of the ART, aligning all its teams to a shared mission and vision. While the inputs to PI Planning vary based on context, the two primary outputs include:
    • Committed PI objectives – These business and technical goals for each team, with agreement and value assigned by the Business Owners, guide the team’s work for the next program increment.
    • Program Board – This is a “visual radiator” of the new feature delivery dates, feature dependencies among teams and with other ARTs, and relevant Milestones (Figure 4).
Figure 4. Program Board
  • System Demos are conducted at the end of every iteration and provide an integrated view of new Features for the most recent iteration. Each demo gives ART stakeholders an objective measure of progress for the current increment. By providing opportunities for real-time adjustments, a system demo is a critical event that enables Business Agility.
  • Inspect and Adapt (I&A) events are held at the end of each Program Increment (PI). It provides the entire ART with an opportunity to identify process improvement via a structured, problem-solving workshop.
  • Innovation and Planning iterations offer an opportunity in every PI for teams to work on innovation activities that are difficult to fit into a continuous, incremental value delivery pattern.

While teams and ARTs work on this cadence, the enterprise can leverage the Continuous Delivery Pipeline to release value at any time that market and governance conditions warrant.

Release on Demand

Release on Demand captures the mechanisms and processes by which new functionality is deployed into production and released immediately or incrementally to customers based on demand. Enterprises vary regarding when they release functionality.

In conjunction with stakeholders, Agile Product Management determines when a release should happen, what elements of the system should be released, and which end-users and customers should receive the release. Some products serve markets in which releasing new functionality as soon as it’s available is the optimal choice. Notable examples are modern SaaS software and service providers who have created sophisticated DevOps capabilities that allow them to release value multiple times per day.

Others may serve markets with distinct market rhythms that govern optimal release windows. For example, there is a distinct market rhythm to selling cold-weather merchandise, ranging from clothing to vehicles, that is defined largely by the hemisphere in which you live. The larger supply chain responds to these rhythms, as further outlined in the roadmap article.

Additional factors that influence when an enterprise may wish to release functionality are:

  • Regulatory deadlines
  • Responding to product defects and security updates
  • Responding to competitive market pressures

Increasingly sophisticated architectures and technical practices that improve Business Agility also support Release on Demand. For example, product telemetry collects data to measure outcome hypothesis and obtain objective evidence of how customers respond to the value released. Separately releasable components, dark launches, feature toggles, and canary releases maximize business flexibility while ensuring operational stability.

DevOps and the Continuous Delivery Pipeline

While it is easy to agree that Release on Demand is the goal, creating the competency to reliably and skillfully release value whenever desired is hard work. It involves embracing the DevOps mindset and culture and creating an increasingly automated Continuous Delivery Pipeline.

Embracing DevOps Mindset, Culture and Practices

As digital disruption continues to change the world, and as software becomes a bigger part of every company’s ability to deliver and support their products and services, every enterprise faces the need to react to customer demand and needs faster with digital solutions. A common problem for fast delivery has always been the chasm between Development and Operations; the former optimizes for frequent releases and change, the latter optimizes for operational stability. If not addressed, this dichotomy in ‘worldview’ creates a barrier to success.

Popularized by books, including The Phoenix Project [4] and the later DevOps Handbook [5], the ‘DevOps’ movement works to align development, operations, the business, information security, and other areas to work together better by sharing the responsibility for improving business results. The reason is simple: high-performing organizations apply DevOps capabilities to dramatically outperform others at both technical aspects and business outcomes, as Figure 5 illustrates.

Figure 5. Example benefits of DevOps [6]
DevOps is the adoption of a mindset, a culture, and a set of technical practices that provides solution elements to the customer without handoffs or excessive external production or operations support. As illustrated in Figure 6, SAFe’s approach to DevOps is grounded in five concepts: Culture, Automation, Lean Flow, Measurement, and Recovery (CALMR).

Figure 6. SAFe’s CALMR approach to DevOps
  • Culture represents the philosophy of shared responsibility for fast value delivery across the entire Value Stream. It consists of everyone who helps create value, including Product Management, development, testing, security, compliance, operations, etc.
  • Automation represents the need to remove human intervention from as much of the pipeline as possible to decrease errors and reduce the overall cycle time of the release process.
  • Lean flow identifies the practices of limiting work in process (WIP), reducing batch size, and managing queue lengths. These hasten value flow to the customer and enable faster feedback.
  • Measurement fosters learning and continuous improvement by understanding and quantifying the flow of value through the pipeline.
  • Recovery builds systems that allow fast fixes of production issues through automatic rollback and ‘fix forward’ capabilities (i.e., fix in production).

One advantage of the CALMR model is that it is designed to work with an organization at any level of Business Agility, immediately supporting them as they begin the process of relentless improvement.

The Continuous Delivery Pipeline

The Continuous Delivery Pipeline represents the workflows, activities, and automation needed to shepherd a new piece of functionality from ideation to an on-demand release of value to the end-user. As illustrated in Figure 7, the pipeline consists of four aspects: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand. The pipeline is the most significant element of the agile product delivery competency (Figure 1).

Figure 7. The Continuous Delivery Pipeline

Each Agile Release Train (ART) builds and maintains, or shares with other ARTs, a pipeline with the assets and technologies needed to deliver solution value as independently as possible. The first three elements of the pipeline (CE, CI, and CD) work together to support the delivery of small batches of new functionality, which are then released in accordance with market demand.

Continuous Exploration fosters innovation and builds alignment on what should be built. Design Thinking is used to continually explore market and customer needs, and define a Vision, Roadmap, and a 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.

Continuous Integration builds quality into the development process by continuously integrating the ongoing work of many Agile Teams. All work is version controlled, and new functionality is built and integrated into a full system or solution. Then, it’s validated in a suitable staging environment that ranges from pure cloud-based software systems to physical devices and/or device simulators.

Continuous Deployment captures the processes associated with moving solutions through staging into production environments. As with Continuous Integration, this varies substantially based on the kinds of solutions created and their associated solution context. To ensure solutions are ready for a full release to customers, deployment includes monitoring to provide flexibility in controlling releases, rolling back a release, or deploying incremental updates and patches.

As described above, Release on Demand is the ability to make value available to customers all at once, or in an ad hoc fashion based on market and business needs. Release on Demand is central to Business Agility, as the decisions of what to release to whom and when are key value drivers.

Summary

Businesses need to balance their execution focus with a customer focus to help assure that they are creating the right solutions, for the right customers, at the right time. Agile product delivery is grounded in customer centricity, which puts the customer at the center of every decision. It uses design thinking to ensure the solution is desirable, feasible, viable, and sustainable.

Developing on cadence helps manage the variability inherent in product development. Release on demand decouples the release and development cadence to ensure customers can get what they need when they need it. DevOps and the CDP create the foundation that enables enterprises to release value, in whole or in part, at any time to meet customer and market demand.

The result of Agile product delivery is enhanced business agility with superior outcomes for the enterprise and the customers it serves.


Learn More

[1] Norman, Don. The Design of Everyday Things. Basic Books, 2013.

[2] Osterwalder, Alexander, Yves Pigneur, Gregory Bernarda, and Alan Smith. Value Proposition Design: How to Create Products and Services Customers Want. Wiley, 2014.

[3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[4] Kim, Gene. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013.

[5] Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.

[6] Accelerate – State of DevOps 2019. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf

 

Last updated: 27 September 2021