Inspect and Adapt in Scaled Agile Framework

The Scaled Agile Framework is a grouping of patterns for organization and workflow developed to help enterprises scale Lean and Agile development practices. This is one of the most popular frameworks whose objective is to help organizations face the challenges in their effort to scale Agile beyond one team. Agile teams work through a regular feedback system, and feedback comes in many ways. One way is receiving product feedback at the end of every iteration when the iteration review is done. Another way of receiving feedback is during the iteration retrospective, where there is an opportunity to review and improve people and processes. Through this continuous feedback, teams keep improving and improving, which helps them build better products. 

But in SAFe, many teams work together on one product. So, the Agile Release Train (ART) also needs to get into a feedback system. There are many principles, practices, and events within the Scaled Agile Framework; if not all, most are used when large-scale product production. For example, events like iteration reviews and retrospectives in SAFe occur after the end of the iterations. Inspect and Adapt Scaled Agile Framework is also an event that happens at the end of a Program Increment (PI). Here, we will provide all the details about the SAFe Agile Inspect and Adapt (I&A), including what happens. 

What is Scaled Agile Inspect and Adapt?

Described by Scaled Agile as "a significant event that is held at the end of each Program Iteration," Inspect and Adapt is a crucial feature of SAFe, where PI is a timeboxed event that is usually of 8 to 12 weeks duration. As the name suggests, it is an event to inspect the product's progress and condition and adapt to the new features. The purpose of a PI is to enable the Agile Release Train to deliver incremental value at the end of this event which is in the form of a working and tested product or service. This value may be some features of the product or service. And the I&A event is held at the end of each PI so that developers can show at what stage the product development has reached and what process was used to reach this condition. The ART then evaluates the product. This is followed by a structured problem-solving workshop where teams ponder and identify the improvement backlog items. The I&A event is crucial because it gives the ART a chance to thoroughly inspect both the product and the process, which helps ensure that the following PI would be better. Thorough inspection and efforts to improve both the product and the process will pave the way for a better PI the next time. 

The event is attended by all the Stakeholders in the Agile Release Train, provides a set of improvement backlog items added to the next PI planning event, and helps the ART improve all the subsequent PIs. Solution trains hold a similar I&A event for large solutions. 

Principle of Inspect and Adapt

The basis of the SAFe Lean-Agile strategy is the concept mentioned in the Agile manifesto that states, "continuous improvement is essential ." The teams take time at the pre-decided intervals to contemplate how they can become more effective and efficient. Based on the derived thoughts, they change or modify their behaviors accordingly. This focus on continuous improvement and the experience gathered through the development cycle, along with the repeated review, enhances the teams' ability to find different viewpoints and multiple ways to do one task. So, the I&A event is an ideal chance for the teams to reflect on what has gone wrong so far, the mistakes that have been committed, and the ways to prevent them from happening again. This is further bolstered by the feedback received from different sources that helps them improve the product and the process. The result is an overall improvement in the speed, quality, and reliability of the following PI. So, it is essential to be set apart to think about how teams can improve. 

The Scaled Agile Framework Inspect and Adapt process:

Being an essential element of SAFe, the I&A process drives continuous development with the help of team evaluation and Stakeholder inputs. A team can make continuous progress if a mindset of inspection and adaptation is adopted. All people involved in developing the solution should ideally participate in the I&A event. These include:

• The Agile teams

• Release Train Engineers (RTEs)

• System and solution architects/ Engineers

• Product management

• Business owners and others in the ART

The I&A event works in three parts. They are:

• The PI system demonstration - Analyzing and customizing the product

• Qualitative and quantitative measurement - Analyzing the process with the help of metrics

• Retrospectives and workshop on problem-solving strategies - Customizing the process

We will now discuss each part in detail.

The PI system demo:

This is the first part of Inspect and Adapt process. It is the demonstration of the system developed during the PI. Here, product development facilitates demonstration covering the fully integrated system. This system demo is a biweekly event but differs from the system demos held at the end of every PI. This demo aims to demonstrate all the features developed by the ART during the just concluded PI. The ultimate goal is to display the existing condition of the system and the progress it has made. The audience here is much broader than the normal PIs and includes business owners, Stakeholders, sponsors, portfolio representatives, and customer representatives. All these collaborate with every Agile team to assess how much business value has been delivered. So, this demo takes a more formal shape and needs extra preparation and staging. Despite this, the PI system demo is time-bound, like other demos, usually limited to, at the most, one hour. An exception can be made for Stakeholders to remain actively engaged and provide feedback. 

The Agile team should present their part of the features quickly so that the whole exercise finishes within an hour. The demonstration by every team can earn some appreciation after its presentation, but the main point of interest should be that the result connects everything. The whole exercise aims to keep the audience engaged in giving proper feedback. So, every team should ensure its presentation is precise and to the point and doesn't get stuck in too many facts. For this purpose, teams should employ creative techniques to keep the audience hooked.  In the end, all the members collaborate to assess how much business value has been delivered up to this point. An essential aspect of the PI system demo is that before or during the demo, Business Owners and the Agile team give a score to the business value achieved during the PI for every individual objective of that particular PI.

Quantitative and qualitative measurement:

This is the next part of Inspect and Adapt scaled Agile. The teams have already agreed to collect data that can be used as metrics. In this part, all the teams sit together to review the metrics and then discuss the emerging data and trends. The responsibility of collecting and analyzing these metrics lies with the Release Train Engineer and the Solution Train Engineer, who must ensure that these align with the business objectives. They are also responsible for identifying the potential issues from these data and trends and presenting their findings to the ART. The products performance and processes that have been part of this ART is measured against these metrics from both quantitative and qualitative viewpoints. Suppose the teams need help deciding which metrics they should collect and analyze. In that case, the Scaled Agile Framework Metrics page provides an exhaustive list of the different portfolio, solution, program, enterprise, and team metrics they can use.

But be mindful of one thing, whatever you may choose to measure, numbers won't reveal everything. Instead, Metrics can be used to uncover the whole story, which can be done by scrutinizing the metrics. This is another session that lasts for one hour, where Program/ART level metrics are displayed to the audience. The program Predictability Measure is one of the critical measurements carried out in this phase. The program predictability measure is developed by expanding the value planned and the actual value achieved by each team. Each team's predictability is measured based on the value delivered by that team, and then the overall program predictability is consolidated. The trains operating within the 80-100% range are considered reliable. Some qualitative measurements can also be taken by the ARTs, like product delivery assessments, Agile assessments, and assessments specific to roles.

Retrospectives and problem-solving:

The first thing the teams do in the Retrospective part of Inspect and Adapt is to find out the problems and process issues they think need to be addressed. They then narrow this to some significant issues at either the team or the program level. These issues are then addressed in the problem-solving workshop. The retrospective runs for about 30 minutes. Issues at the program level usually are addressed by participants of those cross-functional teams that are directly and immediately affected by these issues and, thus are more inspired to resolve them. This creates a broader collection of perspectives and possible solutions that are creative and better. So once the problems are identified, the group is aided by the facilitator, who helps them decide on the issues they want to address. Then, either each team works on one issue or new people from different teams interested in working on the same problem form some new groups. In this phase, the Agile teams are joined by the primary Stakeholders in the ART, like business owners, management, and customers.

Once the retrospective is completed, it is followed by a problem-solving workshop held by ART, in which systemic problems are addressed through root-cause analysis. This root cause analysis brings forward specific tools for resolving issues that help the teams identify the problem's real cause. The Release Train Engineer is tasked with arranging and facilitating this work, typically held over two hours.

Begin with an explicit description of the issue and a commitment to resolving it.

Then do a root-cause analysis putting the issue on the top, and the factors instrumental in its emergence, including people, processes, resources, or systems, are listed along its branches.

Pareto analysis is then used to determine the primary cause that is most impactful at this point. 

Now that the problem has been presented transparently, next, teams can brainstorm to find a possible solution to the problem.

Once the solution is found, the schedule's components are readjusted so they can be incorporated into the following PI.

The tools used during the problem-solving workshop include Pareto analysis, Fish-bone or Ishikawa diagram, and/or 5Whys technique. With this exercise, the cycle of relentless improvement comes alive.

Adopting Lean-Agile thinking and practices takes time and many of the best methods. And the SAFe Inspect and Adapt is a crucial part of it. It assures the business owners that the products and the processes are moving in the right direction. The Agile Release Trains become stronger and at the same time, it makes sure that the SAFe framework guidelines are being followed correctly. The teams are driven to provide their best