Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf. No customer ever asked Amazon to create the Prime membership program, but it sure turns out they wanted it, and I could give you many such examples.
Whether internal or external, customers are increasingly demanding. They have choices. They expect solutions to work well and to solve their current needs. They also expect their solution providers to continuously improve the quality of their products and services.
Customers provide support for SAFe principles and their active engagement and continuous participation in solution development is essential for a successful business outcome.
Either in person or by proxy, customers fulfill the following responsibilities:
- Participate as a Business Owner in PI Planning
- Attend the Solution Demo and possibly System Demos; help evaluate the solution increment
- Participate in Inspect and Adapt workshops; assist in removing some systemic impediments
- Interact with analysts and subject matter experts during specification workshops
- Collaboratively manage scope, time, and other constraints with Product and Solution Management
- Help define the Roadmap, Milestones, and Releases
- Communicate the economic logic behind the solution and help validate assumptions in the Economic Framework
- Review the technical and financial status of the solution
- Participate in beta testing, user acceptance testing (UAT), and other forms of solution validation
The Customer Is Part of the Value Stream
The Lean-Agile Mindset extends beyond the development organization to encompass the entire value stream, which includes the customer.
Engaging customers in the development process depends on the type of solution and the customer’s impact. For example:
- An internal customer requesting their IT department build an application for them
- An external customer who’s the buyer of a custom-built offering (e.g. a government purchasing a defense system) or is part of a larger class of buyers (e.g. an independent software vendor that sells a suite of products).
For those who build solutions for an internal end user (e.g. internal IT department), the customer is part of the operational value stream, as Figure 1 illustrates.
An example would be a marketing director that is responsible for the partner enrollment value stream. The partner is the ultimate end user of the workflow and is the customer. However, to the development team, the marketing director and those who operate the value stream are the customers.
For those who build solutions for an external end user, the customer is the direct buyer of the solution, as Figure 2 illustrates. In this case, the development value stream and the operational value stream are one and the same. The solution can be a final product that’s sold or deployed directly. In other cases, the solution may need to be embedded into a broader Solution Context, such as a system of systems.
Customer Engagement Drives Agile Success
Lean-Agile development depends on a high degree of customer engagement, which is much higher than our traditional development models assumed.
However, the methods of engagement are different and are determined by whether the solution is a:
- General solution – a solution designed to be used by a significant number of customers
- Custom-built solution – a solution built and designed for an individual customer
Figure 3 illustrates the relative level of indirect or direct customer engagement in each case.
General solutions must address the needs of a larger audience. No single customer is an adequate proxy for the whole market. In this case, Product and Solution Management become the indirect customer proxy; they have the authority over solution content. It’s their responsibility to facilitate external interaction and make sure that the voice of the customer will be heard, and that the organization continuously validates new ideas. Scope, schedule, and budget for development are generally at the discretion of the internal Business Owners.
Since it’s unlikely that any particular customer will be participating in regular planning and system demo sessions, customer interaction is typically based on requirements workshops, focus groups, usability testing, and limited beta releases. The solution evolves through feedback from user behavior analysis, metrics, and business intelligence to validate the various hypotheses. During PI planning, a group of internal and external stakeholders acts as the Business Owners—the ultimate internal customer proxy within a specific value stream.
For custom-built solutions, the external customer is typically defining the solution with the support of Product and Solution Management. However, even though the customer is leading the effort, it is critical to establish a collaborative approach to scope and prioritization. This fosters incremental learning and exhibits a willingness to adjust the course of action as needed.
Active participation in PI planning, the solution demo, and selected specification workshops is required. This will often reveal inconsistencies in requirements and design assumptions, with potential contractual problems. This process should drive the customer and the ARTs toward a more collaborative and incremental approach.
Demonstrating the results of the program increment to the customer, in the form of a fully integrated solution increment, establishes a high degree of trust (ex., ‘These teams can really deliver.’) It also provides the opportunity to empirically validate the current course of action. Based on the measured predictability and velocity of trains, forecasting is significantly improved.
The transition toward an Agile contract model will also help increase trust and reduce the win-lose aspects of traditional contracts. One such model is the ‘SAFe managed investment model,’ where the customer commits the funding for a PI or two, then adjusts based on objective evidence and incremental deliveries. This requires a fair bit of trust going in, but then trust is built incrementally, based on a continuous flow of value received.
Learn More Ward, Allen and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.
Last update: 8 October 2018