Feedback

By overfocusing on linear processes rather than the end-to-end flow and feedback, organizations are repeating mistakes by adopting an overly narrow and overly linear view of DevOps.

-Mik Kersten, Project to Product

Definition: Feedback in SAFe includes effective feedback systems that enable the continuous exchange of information to improve products, services, and processes.

Why is feedback critical?

Improving products and the processes that develop them is at the heart of SAFe. Faster customer feedback, especially in the early stages of product innovation, is vital to evaluating new initiatives quickly. This feedback ensures investments do not result in designing and building solutions that Customers do not want or requiring a business model change that the organization cannot deliver. Additionally, the processes used to manage the day-to-day work are continuously evolving as organizations look for opportunities to improve the quality, flow, and satisfaction of those who do this work. None of this can be achieved without feedback. The goal is simple – incorporate and respond to feedback—both positive and negative—as early as possible.

SAFe creates a foundation for effective feedback, and feedback mechanisms exist throughout the entire Framework. Examples include SAFe events, such as the System Demo,­ providing product and process feedback. Agile Teams and ARTs apply, through their iterative approach, implement a Plan-Do-Check-Adjust (PDCA) cycle as part of how they work. Keeping work items small and manageable also ensures quicker value delivery, making it easier to collect and act on feedback. Design-thinking practices embed customer-centricity and user feedback into the product development cycle. The continuous delivery pipeline, with a focus on automation and test-first practices, allows organizations to engage more frequently and respond more effectively to customer feedback.

What are the elements of an effective feedback system?

Although, as described above, SAFe has built-in feedback mechanisms, their success depends greatly on their implementation. Moreover, there are many other opportunities for feedback in addition to those described by SAFe. For these reasons, understanding the critical elements of any effective feedback system provides Agile Teams, ARTs, and the Portfolio with the knowledge needed to collect and respond to feedback wherever needed.

Figure 1 shows the elements common to all effective feedback systems. These elements work together, and when one is missing, the quality or quantity of feedback is impacted. The importance of understanding the elements of feedback is that it provides the means for those seeking feedback to ensure each of these elements is defined and understood before the feedback process is initiated.

Each of these elements and their interactions are described in more detail below.

Subject(s) of Feedback

This is what we want feedback about. Common feedback subjects might be products, customers, processes, strategy, or even company values and culture. Though this seems simple, people often interpret feedback with assumptions about the subject. Specifically, the subject of the feedback might concern a set of newly developed features rather than the entire product or specific steps in a process. Being clear on the purpose and what the feedback is about, and therefore what it is not, helps eliminate assumptions throughout the rest of the feedback system.

Feedback Source

Feedback can be gathered from multiple different sources. The choice of a particular source of feedback should be made carefully as it impacts the quantity and type of feedback available. Examples of feedback sources might include:

• Customers and users
• Employees
• Market data
• Systems
• Data sources

In most cases, multiple feedback sources will be employed, perhaps balancing customers’ views with analytics available directly through the systems they interact with.

Feedback Design

Feedback data may be readily available for some of the feedback sources mentioned above; for others, the process for collecting the feedback will need to be designed.

Part of feedback design is about identifying what we want to know and why we want to know it, along with the type of feedback that will help us answer these questions. Considerations might include:

• Do we need qualitative or quantitative feedback or a mixture of both?
• How quickly do we need the feedback, and what is an appropriate time frame given the type of feedback we seek?
• Is the data we seek available, or do we need to invest in system development or implement tooling?
• If asking questions, what kind of questions should we ask, and who should we ask them?
•  If offering incentives, what will we offer, and how might that bias affect the feedback?

A key element of feedback design is determining how the feedback will be collected. Below are common approaches, and some recommendations are included.

• Gemba: Gemba involves directly observing and experiencing a product being used in the environment where work is being carried out. This allows teams to see actual processes and challenges firsthand and gain valuable insights for making informed decisions based on real-life observations rather than solely on reports or indirect information.
• Empathy interviews and surveys:  This approach helps develop a deep understanding of needs, challenges, and preferences. By directly or indirectly asking relevant questions, valuable insights are gathered. This approach can be scaled fairly easily, although the quantity of data is not a quality replacement.
• Measurement: Organizations need to define key metrics that measure performance and identify areas for improvement. These metrics can be related to quality, delivery speed, customer satisfaction, or other relevant factors.
• Monitoring: Implementing tools and processes to collect data and track system performance continuously. This allows real-time visibility into a system’s health and user interaction.
• Meetings and events: This approach creates opportunities for groups of individuals to share information and respond to feedback. Examples might include regular reporting, team meetings, and collaboration between departments.

Gather Feedback

After agreeing on the design, the next step involves putting the design into action and collecting feedback. Although this step seems simple in the process, you should be aware of some things. One consideration is to make sure to brief those involved in collecting the feedback properly and make them aware of the guardrails governing the approach. Additionally, they have been provided with the necessary tools and training to succeed.

If the feedback design includes implementing a new system or updating an existing one, this step will include communicating the requirements and developing new capabilities.
Another consideration is how the feedback gathered will be stored. This might range from organizing files and folders to designing spreadsheets to more structured approaches such as specific research applications and data warehousing.  Feedback should be available and discoverable.

Analyze Feedback

Analyze the collected data to identify trends, patterns, and root causes of problems. This involves using data analytics techniques and visualization tools to make sense of the information. Analysis does not have to be heavy or lengthy to return value. For example, a team might just desire a quick check with a customer, which would quickly result in saving weeks of wasted development.

---

Note: As Figure 1 highlights, it may be the case that once the analysis is complete, it becomes clear that more feedback is required or that the feedback gathered so far was not of the expected quality or quantity. In this situation, the process is repeated, starting with consideration of the feedback source and following the steps described above.

---

Decisions and Action

The final step in the process is to use the feedback to inform decisions and drive improvement actions. After all, this was the whole reason for collecting the feedback in the first place. The key consideration here is remembering the mantra ‘the facts are friendly.’ Avoid interpreting the feedback in ways that support existing biases or dampen negative feedback. Embrace the feedback and treat it as an opportunity to improve your products and processes.

Implementing changes based on insights gained from the feedback system involves another important step, which is to monitor the impact of that change. In many cases, feedback leads to desired outcomes. However, sometimes, the results may not be satisfactory. In those instances, the feedback process starts again. For many organizations, this feedback system isn’t just a one-time thing. It’s always running. Continuously collect feedback to drive relentless improvement. This approach ensures that organizations are constantly learning, adapting, and striving for better outcomes.

Fully understanding how feedback systems work prevents assumptions, improves customer experience, and allows faster innovation. It’s common for an organization to fall into the trap of assuming they have the right feedback coming in at the right time from the right people. But often, the most important feedback is missed because it is not being sought out, and a system for collecting and analyzing it has not been implemented. 

How is effective feedback enabled?

It’s important to emphasize the importance of shortening feedback loops to accelerate feedback and reduce the time it takes to respond. SAFe and Lean-Agile ways of working include approaches that help accelerate feedback.

Apply cadence through iterations and PIs

Each Agile Team on the ART works in iterations, with all the teams on the ART aligning the start and end date of each iteration. This approach brings cadence and synchronization with key events and integration points happening in a regular and predictable manner.

This approach also provides a critical foundation for feedback. SAFe supports events such as the System Demo, which takes place during each iteration. In this event, all the teams on the ARTs gather feedback from customers and stakeholders on the state of the solution under development. Quickly following this feedback, the teams make the necessary adjustments to their backlogs, following agreement on how they should respond to the feedback in their iteration planning events.

Similarly, at the end of the PI, the entire ART engages in an Inspect and Adapt event. In addition to reviewing the product under development, they use a problem-solving workshop to gather and analyze feedback on ART processes and actively determine the appropriate improvement actions for the very next PI.

The benefits of this iteration and PI cadence for gathering and responding to feedback extend far beyond these examples. To make the best use of them, they should be part of the feedback design to ensure the time frames around the feedback fit well with our ability to respond to it through iteration and PI planning events.

Reduce batch sizes

As with all processes, feedback takes longer when the batch size is larger. Multiple approaches exist to help keep feedback batch sizes smaller, many of which are integral to SAFe. Within the portfolio, early testing with mockups and prototypes helps validate the viability of new initiatives. This approach facilitates quick feedback, enabling informed decisions about whether to continue, adjust, or stop a project.

Across the ART, focusing on minimum marketable features ensures that we can gather feedback on new functionality without over-investing. Moreover, investing in the continuous delivery pipeline allows for the deployment of smaller and smaller pieces of functionality on a more regular basis. Separating the deployment of these features from the full release creates the opportunity to gather feedback from small, controlled groups of users. This ensures that any feedback can be acted upon before impacting the entire user base.

When designing a feedback system, opportunities to reduce batch size should be identified. It is important to remember that the central loop of the feedback system can be navigated multiple times, as shown in Figure 1. It is much better to do multiple feedback loops with smaller batches than a single loop with a larger batch. Large batches risk collecting the wrong feedback with no opportunity to adjust.

Accelerate flow

The connection between flow and feedback should become a virtuous cycle. This means that improved product and delivery flow leads to faster feedback. When development happens smoothly and efficiently, with minimal bottlenecks or delays, it allows for more rapid delivery of features and updates to customers. This faster delivery means customers can interact with the products sooner, providing valuable feedback on new functionality, usability, and overall experience. 

Consequently, any impediments to flow delay feedback. Bottlenecks are especially common. These can occur in the flow of work and can delay the time it takes for customers to interact and provide feedback while they wait for new features. Bottlenecks also impact process feedback. They prevent the next step in a process from receiving work promptly, thereby delaying the feedback to the previous step on the quality and accuracy of the work they received.  

The feedback system itself can be affected by bottlenecks. Common examples include:

• Decision-making delays in the feedback design process
• Limited opportunities to engage with the right customers
• Lack of self-service data
• Managing the gathering of feedback alongside other priorities
• Manual feedback analysis

By identifying and eliminating bottlenecks and focusing on accelerating flow, you also accelerate feedback and the ability to respond to it.

How to communicate and respond to feedback?

Organizations need cultures that celebrate feedback, whether positive or negative, as central to learning, success, and innovation. This contrasts with cultures that use feedback to assign blame or highlight mistakes. To develop the appropriate culture, leaders and those in positions of influence should exemplify the following behaviors when communicating and responding to feedback.

Be clear, precise, and actionable – Provide specific feedback with concrete examples to clarify points, instead of vague comments. This approach allows recipients to fully understand the feedback’s context. In addition, timely feedback ensures that the information is relevant and allows for prompt adjustments, enhancing learning opportunities. Moreover, feedback should be actionable, providing clear suggestions or recommendations for improvement. This not only aids the recipients in addressing the issue at hand but also fosters an environment where multiple solutions can be explored. Together, these elements form the cornerstone of an effective feedback culture, driving growth, development, and collaboration within an organization.

Ignore sunk costs – The sunk cost fallacy is the tendency to continue investing in a product or idea when it will clearly not succeed. When individuals have already invested time or money, it significantly affects their reception and action upon feedback. This means focusing on the future, ignoring sunk costs, and investing emotional attachment in the customer outcomes over a particular feature or product. This makes it easier to make objective decisions based on feedback. It also means celebrating when feedback shows that a particular approach or product will not succeed because then the organization can spend time and people on something else that will. 

Create psychological safety – Feedback should be constructive, respectful, and focused on improvement, avoiding blame or shame. It’s important to assume positive intent and embrace diverse communication styles, fostering trust and safety. Psychological safety is crucial for creating an environment where individuals can freely share ideas and concerns without fear of retribution, promoting innovation and growth. Depending on the source of the feedback, ensuring that we deliver all feedback kindly may not always be possible. However, it is possible to create a system where we view all feedback as an opportunity to learn and improve.

---

References

[1] Kersten, Mik. Project to Product. IT Revolution Press, 2018