Scaled Agile Framework

Why Scaled Agile??

Above problem can be addressed by SaFe (Scaled Agile Framework Enterprise)

To make alignment between enterprise and execution at team level

It addresses the dimension for the enterprise, portfolio work items need to be executed at team level.

SAFe Overview

SAFe overview is a visualization of seven core competencies of Business Agility and the dimension of each.

There are 4 configuration

1. Essentail Safe

2. Large Solution

3. Portfolio Solution

4. Full Safe

Any organization starting this journey - need to attend first Core Safe Configuration - SAFe Essentail .

SAFe Essential

SAFe Large Solution

SAFe Portfolio Solution

SAFe Full Solution

Scaled agile metrices

==

The three measurement domains are defined as follows:

Outcome Matrices

· Do our solutions meet the needs of our customers and the business?

· are focused on the results, such as customer satisfaction, product use, revenue generation, Employee Engagement, iteration goals, pi objectives, impact of the work. These metrices provide a measure of the project’s success and help to determine if the project is meeting its goals.

Flow Metrices

· How efficient is the organization at delivering value to the customer?

· are focused on the movement of output and productivity.

· This can include metrics such as velocity, burn down chart, the average number of defects per week, rework generated due to defects, and cycle time. The specific metrics used will depend on the context and need of the project.

Flow Distribution

Flow distribution measures the amount of each type of work in the system over time. This could include the balance of new business Features (or Stories, Capabilities, or Epics) relative to Enabler work, as well as the work to resolve defects and mitigate risks.

How is this measured? One simple comparison is to count the number of each type of work item at any point in time. A more accurate measure might consider the size of each work item. Agile Teams may measure flow distribution per iteration, but PI boundaries are commonly used to calculate this at the ART level and above, as shown in Figure 6.

Why is this important? To balance both current and future velocity, it is important to be able to track the amount of work of each type that is moving through the system. Too much focus on new business features will leave little capacity for architecture/infrastructure work that addresses various forms of technical debt and enables future value. Alternatively, too much investment in technical debt could leave insufficient capacity for delivering new and current value to the customers. Target capacity allocations for each work type can then be determined to help balance these concerns. Returning to the portfolio example, tracking the distribution of funding across investment horizons provides a means to ensure a balanced portfolio that ensures both near- and long-term health.

Flow Velocity

Flow velocity measures the number of backlog items (stories, features, capabilities, epics) completed in a given timeframe; this is also known as the system’s throughput. (Figure 7).

How is this measured?

As with flow distribution, the simplest measure of velocity is to count the number of work items completed over a time period such as an iteration or PI. Those items can be stories, features, capabilities, or even epics. However, since work items are not all the same size, a more common measure is the total number of completed story points for work items of a type over the timeframe.

Why is this important?

All other things being equal, higher velocity implies a higher output and is a good indicator that process improvements are being applied to identify and remove delays from the system. However, the system’s velocity will not increase forever, and over time stability of the system is important. Significant drops in velocity highlight problems that warrant investigation.

Flow Time

Flow time measures the total time elapsed for all the steps in a workflow and is, therefore, a measure of the efficiency of the entire system.

Flow Time is typically measured from ideation to production. Still, it can also be useful to measure Flow Time for specific parts of a workflow, such as code commit to deployment, to identify opportunities for improvement.

How is this measured?

Flow time is typically measured by the average length of time it takes to complete a particular type of work item (stories, features, capabilities, epics). A histogram is a useful visualization of flow time (Figure 8) since it helps identify outliers that may need attention and supports the goal of reducing the overall average flow time.

Why is this important?

Flow time ensures that organizations and teams focus on what is essential – delivering value to the business and customer in the shortest possible time. The shorter the flow time, the less time our customers spend waiting for new features and the lower the cost of delay incurred by the organization.

Flow Load

Flow load indicates how many items are currently in the system. Keeping a healthy, limited number of active items (limiting work in process) is critical to enabling a fast flow of items through the system (SAFe Principle #6).

How is it measured?

A Cumulative Flow Diagram (CFD) is one common tool used to effectively visualize flow load over time (Figure 9). The CFD shows the quantity of work in a given state, the rate at which items are accepted into the work queue (arrival curve), and the rate at which they are completed (departure curve). At a given point in time, the flow load is the vertical distance between the curves.

Flow Predictability

Flow predictability measures how well teams, ARTs, and Solution Trains can plan and meet their PI objectives.

How is it measured? Flow Predictability is measured via the ART Predictability Measure, Figure 11.

Why is this important?

Low or erratic predictability makes delivery commitments unrealistic and often highlights underlying problems in technology, planning, or organization performance that need addressing.

Reliable trains should operate in the 80 – 100 percent range; this allows the business and its stakeholders to plan effectively.

Competency Metrices

· How proficient is the organization in the practices that enable business agility?

· are focused on the abilities of the project team.

· This can include assessments of team satisfaction, collaboration, trust levels, and other factors contributing to the project team’s sustainability.

Measuring Competency Achieving business agility requires a significant degree of expertise across the Seven SAFe Core Competencies. While each competency can deliver value independently, they are also interdependent in that true business agility can be present only when the enterprise achieves a meaningful state of mastery of all. Measuring the level of organizational competency is accomplished via two separate assessment mechanisms designed for significantly different audiences and different purposes. The SAFe Business Agility Assessment is designed for the business and portfolio stakeholders to assess their overall progress on the ultimate goal of true business agility, as shown in Figure 12.

SAFe Agile Metrcies Example

---

Tools/Framework Used

===

Rally

Jira

Jira Align

Confluence

ALM

Sparx Enterprise Architect

Prolaborate