SAFe Agile

Program Increment (PI) is a period during which an agile team delivers additional value to working systems. PIs usually take between 8 to 12 weeks through four different sprints, namely Planning, Execution, Inspection, and Adjustment phases together with a single Innovation and Planning (IP) iteration. 

In simple terms, a PI serves the purpose of strategizing, executing, and validating system increment processes while receiving feedback for enhancing rhythmical patterns and harmonization. 

The timeline for developmental iterations is broken up within a PI into sections in SAFe. It combines the developed values into relevant milestones to effectively monitor the solutions being developed. 

There are several entities encompassed in a Wide range/ Large solution SAFe, they include: 

• Capabilities 

They are more advanced features subdivided into levels to aid their execution in one PI. 

• Education Milestones 

They depict specific progress areas within a period of time and utilize their benefits in teaching, estimating, and monitoring risks to achieve growth. 

• Defects 

A defect is an item on the product backlog that fails to meet the expected and anticipated requirement resulting in its rejection. Examples are flaws, system bugs, or errors in a solution. 

• Program Increment (PI) Intent  

It shows a summary of the business objectives aimed to be accomplished by the agile team. 

• Uncertain prospects 

These are risks that pose a threat to the success of the project's outcome.

• Recollections 

It is a reflection of events by team members in order to come up with solutions and ways of overcoming similar challenges in the future. 

Agile and DevOps are tools used in the promotion of software development techniques across the globe. Both concepts have distinct advantages and it is more beneficial to an organization combined. 

The major difference between Agile and DevOps is that Agile is a concept used to build and launch software while DevOps considers unique ways to maintain a continual supply of codes and values via the use of advanced automated operations for a project. 

Below are some other differences between DevOps and Agile methodology. 

The Agile Release Trains (ART) are composed of business models for the construction of a vast range of coordinated compound outcomes, termed, Solution Trains.  

The ARTs is a specialized Agile team made of many members from about 50 to 125 people who are experienced in executing tasks, testing, deploying, and releasing end-user products. 

Solution trains, on the contrary, are a business construct used to develop large and more elaborate results and that aids ARTs to align via combined values, vision, direction, and Program Increment (PIs) strategies. 

 A great and easy way to present information is by the use of pictorial illustrations which can be in the form of a diagram. The Scaled Agile Framework (SAFe) supports the diagrammatic representation of data such as the CFD which may be favored by some Agile frameworks, while others may prefer a Burndown chart, all in a bid to simplify the cumbersome task of data representation. 

Unlike the Burndown chart, which only gives information about what work is left in the current development phase, a Cumulative Flow Diagram (CFD) gives information about the requirements present at every given stage and presents grouped data that assists in recognizing project dependencies, making project analysis less tasking as all needed data is represented on one diagram. 

It places focus on the “Backlog” curve representing tasks to be executed and on the “Done” curve indicating the departure or release of iterations. 

 
While this may not be an easy task, understanding subtle changes in the CFD may be an indication of a period of stagnation, demonstrated by the flattening of the curves or a rapid incline of curves, which may point to marked deadline pressure.
Also, it is not uncommon to find the 'actualization' and 'done' curves getting extremely close; this could result from delayed production or testing of products by system developers despite the adequacy of the team. 

Lastly, the curves could fall, indicating a defect in the production process at the point of the decline. This may result from failure to complete features that were previously accepted. Another rare cause of a flattening curve could result from wrongly discarding an already approved feature. 

Expect to come across this popular question in SAFe Agile interview.  

There are 3 main steps involved in the creation of the Cumulative Flow Diagram (CFD).

Establishing structure 

The CFD is represented in form of a chart with the number of task efforts on the vertical axis and the allocated time frame on the horizontal axis which could also indicate the number of sprints remaining in the development process. 

 It is noteworthy that, with more availability of information, the chart becomes more complex and detailed. 

Items to be mapped in a CFD can be included within these stages. 

1. Within the Backlog phase 
2. In the Actualization phase 
3. In the Done phase 

In an Agile project, these stages can be used to summarize multiple sub-levels to aid ease of understanding.

Interpretation and analysis of the curves 

In an ideal setting, all curves slant upwards towards the upper edge of the backlog. This is slightly different from a burndown chart where the slant of closed requirements expands when a production process is thriving, this is because there is an increase in many closed tasks when one requirement is removed. 

In the actualization curve, tasks are followed by each other while the backlog remains the same or changes in isolation when a requirement is added or removed from it. This can then be used to prognosticate when a product can be delivered. 

For correct and proper interpretation and analysis, one must have a good grasp of the “Concept of Done”, to ensure the execution of the correct task. 

Identification of possible problems  

Possible problems as earlier discussed could be indicated by: 

1. Flattening curves 
2. The rapid ascent of curves 
3. Closing gaps between curves 
4. A rapid fall of the curves. 

Broadly, there are 4 levels in SAFe, and each level has various events occurring within. SAFe has critical/ essential parts made up of the program team and the program levels and discretionary or optional parts which include the Large solution and Portfolio SAFe levels.  

The whole essence of grouping events into levels in a SAFe framework is to ensure the execution of customer-based services which satisfies the final product users. 

 
Although some of these events may be tagged non-essential and considered to be optional, regardless, when combined with the essential events, they ensure value to the CDP (Continuous Delivery Pipeline) and in turn, boosts productivity and net worth of delivered products to customers and project stakeholders within the specified project timebox. 

These four levels in SAFe are further subdivided into various events as shown in the table below. 

It's no surprise that this one pops up often in SAFe Scrum master interview questions.  

The SAFe team is made up of several members who work tirelessly to ensure all sprints are executed within the specified allocated time.

The SAFe Team-Level Events are listed and detailed below. 

1. Sprint Planning 

In this event, the SAFe team brings user stories to unanimity and decides on the particular story to be carried out in the following sprints. Next, they develop and agree on techniques for the undertaking and delivery of the iteration. 

2. SAFe Daily Standups 

These are meetings performed every day at a specified time and venue to discuss and review progress made the previous day, and to plan how that present day's activities will be conducted. 

3. Sprint Review 

This is auditing done by the agile team for concluded stories during an iteration. With this, they can get feedback and input from major stakeholders to review the team's production activities. 

4. Sprint Retrospective  

At the SAFe team level, a recollection of past procedure methods for necessary modifications is made by the working team. 

The program level is essential, and at this landmark, certain events are performed, which include the following. 

1. Planning The Program Increment (PI) 

The PI planning event depicts how the release teams are mobilized to center their overall decisions and plans around the PI goals. Here, they decide early on which sprint will require premium prioritization to enable its timely release. In this event, product dependencies and risks are anticipated and detected, and solutions are provided. 

2. Synchronizing Agile Release Trains (ARTs) 

This is also called the ART sync and it is done for project stakeholders to evaluate and make modifications at the program level to mitigate barriers and enhance progress. 

3. System Demo 

This event is added to the team sprint feedback system and comprises the display of all concluded sprints to the product owner and stakeholders. The significance of this is to ensure all aspects of the scope are integrated into the displayed work.

4. Inspection and Adaptation 

This is a concluding event at the integral SAFe program level and entails a demonstration of the PI system demo which is similar but different from the system demo in that it indicates the current status of a solution. 

It also involves a qualitative and a quantitative assessment where the ART presents the available metrics to its members for measurement. 

 Lastly, it includes a workshop for problem-solving. Here, the team performs a brief retrospective analysis of the PI intending to detect major sources of deficiencies and organize measures to resolve them to avoid a future recurrence. 

At this level, the system capabilities are put into consideration as a reference, instead of just the simple features or user stories. 

Prior and Post PI Planning 

Before and after the event, it is necessary to consider the institution of specific ART PI plans to foster alignment and collaboration between multiple ARTs and boost relevance and efficiency. 

Solution Demo 

The effort of the solution trains during the production process is displayed for stakeholders to see in the Solution Demo. This is the level where stakeholders applaud the accomplishments of team members on the final PI. An avenue for suggestions on future deliveries can also be made while highlighting capabilities and demands. 

There are 4 events at the Portfolio SAFe level that are less controlled because numerous differences exist depending on the business structure. Below are some examples of events at the Portfolio level. 

1. Portfolio Lean - Budget Review 

This is where a periodical review is performed on the available multiple value streams. The technique employed to conduct this review is termed Participatory Budgeting and a decision on an acceptable allocation is made by relevant stakeholders. In most cases, this event is carried out bi-annually.

2. Practice Communities 

The SAFe structure has a program management office set up to assist Release Train Engineers to coordinate the exchange of experience and collaboration during the Portfolio event. 

3. Portfolio Sync Event 

The main aim is to determine the effectiveness of the sprint moving towards achieving its anticipated result and may include a revision of value streams. This event is facilitated by the project stakeholders or the program management office and regularly takes place every 2 weeks. 

4. Final Work Display 

This is a final presentation of the completed work across various solution trains at the level of the organization. 

Some may utilize this event to gather feedback and suggestions for the final release.

The Agile Release Train (ART) entails a business model for the construction of a wide range of coordinated compound outcomes, termed, Solution Trains.  

The ARTs is a specialized Agile team made of many members from about 50 to 125 people who are experienced in executing tasks, testing, deploying, and releasing end-user products. There are about 3 to 10 ARTs present in 1 - Solution Train.  

 Solution trains are a business construct used to generate large and more elaborate results. They aid ARTs to align via integrated values, vision, direction, and Program Increment (PIs) strategies. 

A Value Stream is a group of fundamental standards constructed to boost the worth of services provided from the early request point made by a client to the development stage, and finally to the stage of product release. It is an extended cycle of actions that aids understanding, coordination, and continual delivery of value.
This is similar to the ART in that they are an organized team established to produce a continuous and incremental delivery of value in a value stream. The ART is the team that executes, delivers, and provides support for an organization's established value stream. 

Both are the business support of a SAFe execution and are essential to the successful completion of an iteration. It is, therefore, necessary to identify and use them effectively and this includes a basic comprehension of the updated business model to facilitate the continuous flow of value across different activity boundaries.
The structure of the Value Stream entails several aspects. Initially, certain significant events stimulate the flow of value such as a new order placed by a customer, and ends with the deployment of goods. The next element is divided up into steps from 1 to ‘n’, which are used by the organization to accomplish its aims.
Next, is the Value, which is delivered to the customer when the Value Streams are complete. The involved systems and people make up the subsequent aspect. Lastly is the Lead Time which is all-encompassing of the period covered from the initial triggering stimulant to the present Lead Time. A way to reduce the Lead Time is to take out irrelevant activities included that result in delays and prolongation of iterations. 

In the Scaled Agile Framework, product development focus is placed both on planning for future increments as well as on reviews of past events, the innovations and build of relevant areas, and on aspects from past activities that should be imbibed and built upon. 

All these are reflected in the PI System Demo. It also shows the current progress of the Solution and conveys knowledge within an internal system that has different teams to enable members to have a general overview and learn from themselves.

Therefore, the PI System Demo is intended for the Agile Development Team. Because a deep understanding of all the functionalities across various levels of development by all team members has a positive effect in bringing the business clients on board to provide them with sufficient information and ensure they achieve maximum benefits from future product development. 

A common in Scaled Agile Framework interview questions, don't miss this one.  

How do Agile and SAFe Frameworks vary? Describe the four core values of SAFe?

Agile is a broad term covering several frameworks, one of which is SAFe. SAFe was established by Dean Leffingwell and was created explicitly for large-scale enterprise projects. It mounts up other models like Scrum to an enterprise level.

It is based on three fundamental principles:

1. Agile Development
2. Lean Product Development
3. Systems Thinking.

 The four core values of SAFe are: 

1. Alignment - Maintaining pace with the instantaneous modifications 
2. Built-in quality - Every component must be up to the quality criteria 
3. Transparency - Trust and reliability 
4. Program Execution - Deliver continuously and efficiently 

SAFe 5.0 was launched in January 2020 and contains seven core competencies around customer centricity. They are: 

1. Enterprise solution delivery: The Enterprise Solution Delivery competency defines how to lay Lean-Agile principles and techniques to the specification, development, deployment, procedure or operation, and evolution of the world’s most extensive and refined software applications, networks, and cyber-physical systems. 
2. Agile product delivery: Agile Product Delivery is a customer-centric technique for defining, producing, and casting a constant flow of valuable products and services to customers and users. 
3. Team and technical agility: The Team and Technical Agility competency depict the vital skills and Lean-Agile principles and techniques that high-performing Agile teams utilize to produce high-quality solutions for their customers. 
4. Lean-Agile leadership: The Lean-Agile Leadership competency illustrates how Lean-Agile Leaders drive and support organizational change and functional excellence by entrusting individuals and teams to attain their highest potential. 
5. Lean portfolio management: The Lean Portfolio Management competency aligns strategy and execution by using Lean and systems thinking techniques to strategy and investment funding, Agile portfolio operations, and governance. 
6. Continuous learning curve: Continuous learning is the technique of learning new skills and knowledge continuously. This can come in many forms, from formal course-taking to informal social learning. It involves self-initiative and taking on challenges. 
7. Organizational agility: The Organizational Agility competency defines how Lean-thinking individuals and Agile teams optimize their business processes, evolve strategy with precise and clear new commitments, and quickly adapt the organization to capitalize on new opportunities. 

A value stream is a long-lived sequel of stages utilized to provide value, from customer demand to delivery of a definite outcome for the customer.

The image beneath depicts the anatomy of a value stream. 

An event starts the flow of value; it could be a consumer request, a new element, or a feature requirement. It concludes when some value has been delivered, like a shipment, customer purchase, or solution deployment. The activities in between are the enterprise's steps to accomplish the task. So, a value stream includes the people who do the work, the methods they develop or operate, and the flow of knowledge and materials. 

One of the most frequently posed SAFe Agile interview questions, be ready for it.  

The Continuous Delivery Pipeline denotes the workflows, activities, and automation required to design a new element of functionality from imagination to the release of value to the end user.

The pipeline consists of four parts: 

1. Continuous Exploration (CE) 
2. Continuous Integration (CI) 
3. Continuous Deployment (CD) 
4. Release on Demand 

SAFe brings multiple benefits and also comes with its own drawbacks, like:

1. SAFe needs to take more of a top-down rather than a team-based procedure.
2. Heavily stresses the use of its particular procedures and rules without leaving considerable room for customization on the part of the organization.
3. Extra layers of oversight, administration, and coordination of SAFe make it resemble the waterfall approach many teams are trying to leave behind.