scaled agile framework problem solving workshop

• Skip to content

Problem-solving workshop: Step-by-Step

A problem-solving workshop is held by the Agile Release Train and its purpose is to address systematic problems. The workshop that concentrates on identifying the problems, not just addressing the symptoms, is facilitated by the Release Train Engineer and time-boxed to maximum of two hours. What are the six steps of the workshop?

In SAFe® (Scaled Agile Framework for Enterprises®), problem-solving workshop is done during the Inspect & Adapt (I & A) event. I & A  is held at the end of each Program Increment, and it forms the basis for relentless improvement, one of the four pillars of the SAFe House of Lean , and a dimension of the Continuous Learning Culture core competency.

During the three parts of I & A event (PI System Demo, Quantitative and Qualitative measurement, and Retrospective and problem-solving workshop), the ART demonstrates and evaluates the current state of the solution and teams reflect and identify improvement backlog items. In this article we are going to concentrate on the last part of the event, problem-solving workshop, during which teams systematically address the larger impediments that are limiting velocity.

Problem-solving workshop consists of 6 steps

Step 1: agree on the problem to solve.

Clearly stating the problem is key to problem identification and correction. It enables more focused investigation, time-saving, and avoids ‘ready, fire, aim’ approach. On the other hand, a problem that is not well defined, may result in failure to reach the proper countermeasure. To identify and agree on the problem to solve, the teams should spend a few minutes clearly stating the problem, highlighting the ‘what’, ‘where’, ‘when’, and ‘impact’ as succinctly as they can.

Step 2: Apply root-cause analysis and 5 whys

The Root-cause analysis and the ‘5 Whys’ technique is used to explore the cause-and-effect relationships underlying a particular problem. It helps to avoid assumptions and logic traps, trace the chain of causality in direct increments from the effect to a root cause.

The root cause analysis (fishbone or Ishikawa) diagram features 5 main ‘bones’ that represent typical sources of problems in development (tools, people, program, process, environment). Team members then brainstorm causes that they think contribute to the problem to be solved and group them into these categories. Once a cause is identified, its root cause is explored with the 5 Whys technique. By simply asking ‘why’ multiple times, the cause of the previous cause is uncovered, and added to the diagram. The process stops once a suitable root cause has been identified and the same process is then applied to the next cause (© Scaled Agile, Inc.).

Step 3: Identify the biggest root-cause using Pareto analysis

Team uses Pareto analysis (or 80/20 rule) to narrow down the number of actions that produce the most significant overall effect. It is based on the principle that 20% of root causes can cause 80% of problems and it has proved useful where many possible sources and actions are competing. Once the team writes down all the causes-of-causes, they identify the biggest root-cause using dot-voting – every team member has five dots on its disposal, and he can allocate them to one or more items he thinks are most problematic. Then they summarize votes in Pareto chart that shows collective consensus on the most significant root-cause.

Step 4: Restate the new problem for the biggest root-cause

Team picks the most voted item from Pareto chart. They restate it clearly as a problem and add economic impact of the problem to the description.

Step 5: Brainstorm solutions

During the brainstorming activity that lasts about 15 – 30 minutes, team brainstorms as many possible corrective actions as possible. The goal of activity is to generate as many ideas as possible, without criticism or debate. Team members should let their imagination soar and explore and combine all the ideas that arise and in the end dot-vote to identify top contenders.

Step 6: Identify improvement backlog items (NRFs)

In the end of the problem-solving workshop, up to three most voted solutions are identified. Solutions are then rephrased as improvement stories and features to be fed directly into the PI Planning event that follows the I & A event. During that event, the RTE helps ensure that the relevant work needed to deliver the identified improvements is planned. This closes the loop, thus ensuring that action will be taken, and that people and resources are dedicated as necessary to improve the current state. In this way, problem-solving becomes routine and systematic, and team members and ART stakeholders can be assured that the train is solidly on its journey of relentless improvement (© Scaled Agile, Inc. ).

You may also like

Mastering SAFe: What Every Business Professional Should Know

Anti-Patterns in SAFe Implementation

Five Things You May Not Know About the SAFe Inspect and Adapt (I&A) Event

The Scaled Agile Framework (SAFe … the “e” means nothing…) is the industry leading framework for scaling agile in a business or business unit. It’s used by some pretty big names like CVS, American Express, and FedEx.

Emma Ropski

The Scaled Agile Frame work (SAFe) incorporates methods, events, principles, and roles that agilists are already familiar with from Scrum, Lean, and XP. But SAFe is also novel, with its own unique concepts, roles, and events like the Inspect and Adapt (I&A) , a reflective all hands event that happens every quarter featuring a problem solving workshop. 

The thing about SAFe events is, even if you know a bit about them, they can still be super mysterious. It’s like a nursing student who’s only read their textbook or a rock and roll fan who’s never been to a Grateful Dead concert. You really have to be there to get it.

 Lucky for you, I have been there! Over ten times as both a participant and a facilitator! Here are a few misconceptions.

The I&A is more than just the problem solving workshop

People often use the term I&A to mean just the problem solving workshop. Though that is the main attraction of the 4-hour event, you’re missing some of the context setting that happens earlier in the agenda. 

First, there’s a demo of the current state of the product, highlighting work done in the past quarter. Next, the group reviews select success and predictability metrics focusing on areas to improve. Then, some do a retrospective during the event time-box to brainstorm and form problem statements. And finally, we get to the problem solving workshop!

• Become THE Expert!
• Subscribe to ScatterSpoke's Newsletter for more expert advice, and recieve a FREE copy of our popular Icebreakers List.
• Become an Expert!

You don’t need to use an Ishikawa diagram!

An Ishikawa diagram, also known as a fishbone diagram, is recommended for small groups to use to visualize potential contributing causes of the problem to be solved. The group then explores the causes of the causes using the five whys technique to get to a root cause. (Say causes of the causes five times fast). Though it may seem excessive to some, going deeper helps ensure that we're tackling the disease and not just a symptom of it. The group then diverges and converges on a solution set.

This fishbone visualization combined with the described technique is recommended because it is effective and theoretically sound. But fishbone quarter after quarter can leave teammates uninspired and asking, “… is there anything besides fish on the menu?” 

I’ve seen a few other approaches to keep things fresh and keep morale up. My first I&A problem solving workshop was unlike any other. They gave all randomly assigned groups this prompt: “ You have all the money and resources you desire… How do you take our company down?" Let’s just say the room was buzzing! Though not traditional by any means, this alternative method still met the purpose of the event: to reflect and identify ways to improve. 

Problems don’t actually get solved in the workshop

With a name like “problem-solving workshop,” you’d think you solve problems. A more accurate name would be “problem exploring and solution proposal workshop,” but that really doesn’t have the same ring to it.

Let me explain. In the problem-solving workshop, the problems proposed should be experienced cross-team and are usually systemic. Their root causes often lie in culture, process, or environment. They’re big problems! Realistically, some could take years to properly solve. 

The vast majority of the time-box in the workshop is allotted to identifying these root causes. Even with less time, groups tend to brainstorm multiple possible solutions and present their top ideas to the whole group. Since problems are big, often the first step in the solution is to explore the problem more.

So, what’s the point? In my opinion, the problem-solving workshop raises problems to the surface and gets the conversation started. The “solving” often takes some more time, coordination, and prioritization.

Some people can’t participate

…. because they facilitate! Scrum masters, coaches, and other volunteers are usually necessary to guide small groups through a typical problem solving workshop. Why? To avoid the chaos that can often occur in group discussions:

         • dominating the conversation and others not feeling safe to share

         • Groups getting off topic due to confusion or boredom

         • Skipping “less exciting” steps like problem exploration to get to “more exciting” steps like solutioning 

Still, knowing some teammates aren’t engaged in problem solving can feel like a disservice to the whole group. Everyone has experiences, knowledge, and context to add to the collective pool of knowledge which would contribute to a more holistic and, therefore, successful solution. My advice? Rotate facilitators every quarter when possible, especially if they aren’t in a dedicated coaching role.

It takes a lot of behind the scenes work to make the I&A happen.

Though many will just show up, listen, and problem solve with their teammates at the end of the quarter, the I&A event requires several people several hours to prepare for. 

Product management is usually accountable for the demo though may get some support from scrum masters. They usually connect with teams, team leads, and feature-owners to coordinate a demo (ideally live and not death by PowerPoint) of the holistic product, highlighting new features delivered this quarter.

Good data doesn’t just happen; it’s quite intentional. Success and predictability metrics should be agreed upon and defined before the quarter, ideally as a constant to compare quarter to quarter. Once collected and visualized, it needs to be presented in a way that is concise and motivating regardless of the results. Not an easy task.

Retrospective

Running a 30-minute retrospective with 100 people on identifying and defining systemic problems experienced across several teams in the last 3 months is a tall task. With the teams I’ve been on, usually we’ve taken the extra step ahead of the I&A to gather problem statements. As the scrum master, I’d design and facilitate a retro of the past three months and coach teams through what’s an appropriate problem to bring and the information it needs. It’s still a tall task, but a little less tall. We could make the task even shorter by using ScatterSpoke’s Team Pulse 👀

Designing the format, forming the small groups, training the facilitators, collecting improvement items, voting on them, and finding a way to squeeze them into an already tight backlog is all in a day’s work for the coach leading this event. Just reading it all makes me sweat!

Even if you haven’t been there, with the inside scoop from me, the I&A in practice should be a bit demystified. It’s not just a problem-solving workshop. And the problem-solving workshop isn’t really a problem solving workshop. You can vary the protein served beyond fish, and not everyone gets to eat (but definitely next time!). Last but not least, preparing for the I&A takes time, energy, and passion. Systemic problems aren’t easy, but this unique SAFe event is an inclusive and brave first step toward solving them.

Related Posts

The power of developer feedback.

Listening to team feedback is essential in tech for building high-quality software and staying competitive. Developers and support teams provide practical, hands-on insights that can lead to immediate improvements. Creating a continuous feedback loop, acting on the feedback, and building trust within the team are critical steps for fostering a culture of continuous improvement and collaboration.

Why Quarterly Retrospectives Guarantee Nothing Ever Changes in Agile Release Trains

Quarterly feedback may align with SAFe's Program Increments, but it can hinder the success of Agile Release Trains. Discover how Agile Delivery Managers and RTEs can drive continuous improvement through frequent retrospectives and actionable insights. Learn why embracing agility and faster feedback loops is crucial for your organization's growth and success.

John Samuelson

How scatterspoke developers improved flow state time with ai coding assistant cody.

The developers at ScatterSpoke enhanced their flow state time and sped up their delivery process by integrating an AI coding assistant named Cody, which helped automate repetitive tasks, provide code suggestions, and quick-fix common errors. As a result, their workflow improved significantly with increased productivity, enhanced knowledge, improved focus, and reduced coding errors, leading to the delivery of high-quality software products.

Act On Feedback Faster

Join the ranks of data-driven companies seamlessly acting on feedback and driving substantial improvement with less effort.

ScatterSpoke helps you eliminate waste in your dev process.

© XXXX ScatterSpoke. All Rights Reserved.

• +44 (0)20 8145 5000
• [email protected]
• 63/66 Hatton Garden, Fifth Floor Suite 23, London, EC1N 8LE

• Agile HR Course
• Lean Agile Centre of Excellence
• Agile Coaching

Which activity happens in the Inspect and Adapt workshop?

Pick one of 4 options:.

A) A retrospective of the iteration B) Planning the next PI C) A demo of the integrated system D) Refreshing the Program Backlog

Scroll to the bottom to find out! But first, learn more below…

Inspect and Adapt

In SAFe, the Inspect and Adapt (I&A) Workshop is a regularly scheduled event that is held at the end of each Program Increment (PI). The purpose of the I&A Workshop is to review the progress made during the PI, identify any improvements that can be made to the process, and make adjustments as needed to ensure that the organization is able to continue delivering value to the customer on a regular basis.

As part of the review process, participants also assess the effectiveness of the practices and processes that were used during the PI and identify any areas where improvements can be made. This may involve evaluating the use of Scrum, Lean, and other Agile practices, as well as the effectiveness of the technical infrastructure and tools that were used.

Once the review is complete, participants work together to identify any improvements that can be made to the process. This may involve making adjustments to the way that work is organized and prioritized, improving the way that teams collaborate and communicate, or introducing new tools or practices that will help the organization to be more effective.

The I&A Workshop is an important part of the SAFe framework, as it provides a regular opportunity for the organization to review its progress and make adjustments as needed to ensure that it is able to continue delivering value to the customer. By regularly reviewing and adapting its practices, the organization can continuously improve its ability to deliver value and respond to the changing needs of the customer.

Who Participates?

Ideally, everybody involved in building the solution. In the context of the ART, this includes the agile teams, the RTE, system and solution architects, etc. All are welcome to help identify backlog items.

And now for the answer…

C) A demo of the integrated system!

Go into more depth on the Scaled Agile Framework and its various events on a SAFe- certified course . Or, learn more about the Inspect & Adapt workshop specifically and download an overview here .

Connect with Value Glide!

 Are you looking to adopt Agile ways of working? If so, SAFe, Scrum and Kanban could be the perfect solution for you. For expert guidance to successfully adopt and implement SAFem Scrum or Kanban, Value Glide is here to help. Our team has the skills and experience to ensure your Agile adoption is seamless and successful.

Connect with us for Agile Training, Agile Consulting, and Agile coaching.

• SAFe Training
• SAFe Consulting
• SAFe Quickstart ART Launch
• Value Stream Mapping Workshops
• Scrum Training
• Kanban Training

Visit https://www.valueglide.com for more information.

You may also like...

Feeling blocked ? Try a Systems Thinking Workshop

Do you get the sense of silo thinking, fixed mindset, or “this is alway the way we’ve done things around here”. You might be blocked.

State of Agile Report

The yearly State of Agile report is back now in its 16th edition, and once again it provides some fascinating insights.  The Scaled Agile Framework

How Much of a Role Does a SAFe Consultant Play in PI Planning in the Initial Adoption of SAFe

What is the role of the Scrum Master in SAFe?

How Would You, as a SAFe Consultant, Handle Conflict between Teams in an Agile Release Train

Leadership-Clarke Ching: Cash Cows make the Best Burgers

Profit is, for businesses, like oxygen is for humans – we need it to exit, but it’s not the reason you exist. In this talk,

Latest Blog Posts

What does Agile HR look, sound and feel like in practice?

Case Studies in Agile HR: How Leading Organizations Align HR with Agile Values As the business world continues to embrace Agile methodologies, many organizations are

how does the agile hr course align with agile principles and frameworks, and how does that help hr departments?

Embrace Agility with the Agile HR Course: Transforming HR for the Future As organizations embark on their Agile and digital transformation journeys, the role of

Why is the Agile HR course relevant?

Why the Agile HR Course is Essential for HR Professionals In a world where change is the only constant, HR professionals are increasingly finding themselves

Transforming Vision into Velocity : Elevate Your Agile Journey with Value Glide’s Expert SAFe Consulting, Coaching, and Training.

Useful Links

Connect with us.

Connect with us on social media and stay up to date with our latest offers, news, and mastering SAFe series.

©2024. Value Glide. All Rights Reserved.

Website created & supported by FireWerks Marketing + Design

Home > Learning > Three Steps to Prepare for a Successful Value Stream Workshop – SAFe Transformation

Three Steps to Prepare for a Successful Value Stream Workshop – SAFe Transformation

The Value Stream and Agile Release Train (ART) identification workshop are some of the most critical steps to generate meaningful results from your SAFe transformation. That’s because it enables you to respond faster to customer needs by organizing around value. This workshop can also be the hardest step. It’s complex and politically charged, so organizations often skip or mismanage it.

A savvy change agent would invest in the organizational and cultural readiness to improve the chances of its success. Attempting to shortcut or breeze through change readiness would be the same as putting your foot on the brake at the same time you’re trying to accelerate. Get this workshop right, and you’ll be well on your way to a successful SAFe implementation.

Why Is It So Difficult?  

Aside from the complex mechanics of identifying your value streams, there is also a people component that adds to the challenge. Leaders are often misaligned about the implications of the workshop, and it can be tough to get the right participants to attend.  For example, a people leader could soon realize that ARTs may be organized in a way that crosses multiple reporting relationships, raising the concern of their direct reports joining ARTs that don’t report to them. 

In reflecting on my battle scars from the field, I’ve distilled my advice to three steps to prepare the organization for a successful workshop.

Step 1: Engage the right participants

The Value Stream and ART identification workshop can only be effective and valuable if the right audience is present and engaged. This is the first step to ensure the outcome of the workshop solves for the whole system and breaks through organizational silos.

“… and If you can’t come, send no one.” —W. Edwards Deming

The required attendees will fall into four broad categories:

• Executives and leaders with the authority required to form ARTs that cut across silos.
• Business owners and stakeholders who can speak to the operational activities of the business, including ones with security and compliance concerns.
• Technical design authorities and development managers who can identify impacted systems and are responsible for the people who are working on them.
• Lean-Agile Center of Excellence and change agents supporting the SAFe implementation and facilitating the workshop.

Use some guiding questions to identify the right audience for the workshop within your organization. Are the participants empowered to make organizational decisions? Do the participants represent the whole value stream? Is the number of attendees within a reasonable range to make effective decisions?

Step 2: Build leadership support and pre-align expectations

To support engagement and address potential resistance, I recommend performing a series of interactions with leaders in advance of the workshop. In such interactions, the change agent would socialize a crisp and compelling case for change in the organization, supporting the “why” behind running the workshop.

The change agent needs to be prepared to address leader trepidation about the possibility of having their reporting-line personnel on ARTs that they don’t fully own.  Most compelling is a data-based case made by performing value-stream mapping with real project data to expose the delays in value delivery due to organizational handoffs. 

Interaction opportunities can include one-on-one empathy interviews, attending staff meetings, internal focus groups, and overview sessions open to all workshop participants. 

I highly advise setting expectations with leaders in advance of the workshop. This will help them understand the workshop implications, help identify potential misalignment or resistance, and coach them in how to signal support for the workshop purpose.  

The following are useful expectations to set with the participants in advance to help shape how they view the upcoming workshop:

• Allow the designs to emerge during the session. This is meant as a collaborative workshop.
• Expect to be active and on your feet during the session, actively contributing to the designs.
• Be present and free up your schedule for the duration of the workshop as key organizational decisions are being made.
• Alleviate the anxiety of broad, big-bang change by clarifying that they get to influence the implementation plan and timing to launch the ARTs.
• Address the misconception about organizational change by explaining that ARTs are “virtual” organizations, and that reporting lines need not be disrupted.

Step 3: Prepare the workshop facilitators

A successful Value Stream and ART identification workshop will have the main facilitator, ideally someone with experience running this workshop. Additionally, you’ll need a facilitator, typically an SPC, per every group of six to eight attendees. Prior to the workshop date, schedule several facilitator meetings to prepare and align them on the game plan. This will go a long way in helping your facilitators project competence and confidence during the workshop. Discuss the inherent challenges and potential resistance, and how the facilitators can best facilitate such moments. Share insights on change readiness based on the leadership interactions and empathy interviews. Finally, prepare a shared communication backchannel for facilitators, and build in sync points during the event to ensure alignment across the groups.

While these simple steps and readiness recommendations don’t necessarily guarantee a successful workshop, they’re a great starting point. You’ll still need to understand the mechanics of identifying value streams. This is what Adam will cover in the next post in our value stream series. Look for it next week.

In the meantime, check out the new Organize Around Value page on the SAFe Community Platform.

About Deema Dajani

Deema Dajani is a Certified SAFe® Program Consultant Trainer (SPCT). Drawing on her successful startup background and an MBA from Kellogg Northwestern University, Deema helps large enterprises thrive through successful Agile transformations. Deema is passionate about organizing Agile communities for good, and helped co-found the Women in Agile nonprofit. She’s also a frequent speaker at Agile conferences and most recently contributed to a book on business agility.

View all posts by Deema Dajani

Back to: All Blog Posts

Next: Leading the SAFe® Conversation to Win Over Your Peers

• Events in SAFe

by WOA Author | Dec 2, 2022 | Scaled Agile

As part of t he Introduction to Scaled Agile Framework  series, this article will explain Events in SAFe and how they scale.

Events in SAFe At Essential SAFe Layer

Essential SAFe covers 2 layers the Team and ART Layer- each layer has its own event. The ART events contain the iteration events within the PI – The Planning Interval

ART Events Drive The Planning Interval

ART events drive the Planning Interval . The Planning Interval (Pl) is a timebox during which an Agile Release Train (ART) delivers incremental value. This value is in the form of working, tested software and systems. Pis are typically 8 – 12 weeks long. The most common pattern for a Pl is four development Iterations, followed by one Innovation and Planning (IP) Iteration. Each individual Iteration has its own events. The section below will describe the individual Iteration events.. This section discusses about events at the ART or PI level.

PI Planning

Planning Interval planning (PI Planning) is a two-day event. PI Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART). This event aligns all the teams on the ART to a shared mission and Vision.

In this event, everyone in the ART gets together to agree team and overall PI objectives. They also forecast which iteration the priority features on the ART backlog will be completed. As part of this event, dependencies between teams are identified and planned in. While risks are identified and either resolved, owned, accepted or mitigated.

PI planning happens during the IP iteration of last PI. For an example, for the PI 3, the PI planning will happen during IP iteration of PI 2.

ART Sync, Scrum of Scrums and PO Sync

Over the course of the PI, there are regular check in sessions for team representatives. During this event representatives discuss progress towards the PI objectives and other topics. The ART Sync is the parent ART event that combines the Product Owner (PO) Sync and Scrum of Scrums (SoS).

For large ARTs , usually ART sync is divided in two separate meetings, PO Sync and SoS

In the scrum of scrums events the RTE, scrum masters and other selected team members J oin. These particpants discuss progress, impediments and inter-team dependencies. Usually the RTE acts as the meeting facilitator

In PO Sync events where product manager, product owner and other selected stakeholders join. These participants discuss progress, priorities and scope adjustment.

For smaller ARTs, the PO sync and SOS meetings can be combined into one single meeting .

System Demo

Shortly after the end of each iteration in the PI, the completed work from all of the teams is integrated into a staging environment and is demonstrated to business owners and other stakeholders. It is essential that the demonstration is of fully integrated work. This event does not replace, but is in addition to, the team’s iteration reviews.

Inspect and Adapt workshop

This event takes place right at the end of the PI dueing the IP iteration of that PI.

This event has of three parts: the PI system demo; quantitative and qualitative measurement; and the problem‑solving workshop.

• The PI system demo is similar to the system demo, but it shows the current state of the solution. It highlights the work done throughout the whole PI, not just in the last iteration. Also, every member of ART attends this event.
• During the quantitative and qualitative measurement part, the RTE presents ART metrics to the members of the ART.
• In the problem-solving workshop, the teams conduct a relatively short (1-2 hours) retrospective on the PI. The focus is to identify the root causes of problems and identify actions that can address the root cause to stop the issues presenting themselves in future programme increments.

Iteration Level Events

Each iteration has the events similar to those explained in the Scrum Guide

• Iteration Planning
• Iteration Review/ Demo
• Iteration Retrospective

The diagram below shows how the terms used by SAFe relate to those in the Scrum Guide

Events in SAFe at Solution Level Events

For a large solution, the cadence does not change from the ART level, it is still a Planning Interval of 8-12 weeks. At the large solution level, the solution backlog contains, capabilities of the system, rather than features or stories.

Pre- and Post-PI Planning In order to coordinate work across multiple ARTs and also with suppliers, there is an alignment meeting both before and after the individual ART PI planning sessions. Synchronisation of the PI planning events is essential in order for the pre- and post-PI planning events to be meaningful and happen within a few days of each other.

Solution Demo During the solution demo, the development efforts of the solution train (multiple ARTs and work from suppliers) are made visible to customers and other stakeholders. This event is a both a celebration of the work achieved in the last PI and an opportunity to gain feedback ahead of the next one. It is an opportunity for the customer and other stakeholders to influence upcoming work. During the event, capabilities are demonstrated, including any stated compliance and non-functional requirements.

Attendees usually include, customers, large solution stakeholders, representatives from each of the ART (e.g. product managers and product owners), solution management, lean portfolio management (if used) and the solution train engineer (STE), who is likely to be facilitating this event.

• Be Agile – Learning from 2020
• Agile Project Management
• Agile Manifesto
• Agile Methodology and Frameworks
• 5 Levels of Planning
• What is Kanban
• Risk Boards
• Burn Down Chart
• Cumulative Flow Diagram
• Burn Up Chart
• Kanban Boards or Task Boards
• Why is User Story not part of core Scrum?
• Splitting User Stories in Scrum
• Story Point Estimation
• Connection Between Lean, Agile, DevOps, Six-Sigma, ITSM, Scrum
• What’s new in Scrum Guide 2020?
• Applicability of Scrum
• Empirical Process Control
• Scrum Values
• Servant Leadership
• A Day in the life of a Scrum Master
• Change Management in Scrum
• Scrum Master
• Scaling PO Role
• Difference between PO and Business Analyst
• Distributed Scrum Teams
• Building Self Managed Teams
• Product Backlog
• Sprint Backlog
• Product Increment
• Product Goal
• Sprint Goal
• Definition of Done
• What is Sprint?
• Is Planning required in Scrum?
• Sprint Planning
• Daily Scrum
• Handling a 15 minute Daily Standup Meeting in Scrum
• Is the 3-Question format compulsory in Daily Scrum?
• Sprint Review
• Handling a Sprint Review Meeting
• Sprint Retrospective
• PB Refinement
• Why Industries are in Need to Adopt Scaled Agile?
• Scaling Context – Some Basics Concepts
• SAFe as Dual Operating System
• How SAFe® helps with Business Agility
• SAFe Big Picture – An Overview
• SAFe Configurations
• How The Backlogs Scale in SAFe
• Roles in SAFe
• Real Life Scenarios Of Sprint Planning
• Real Life Scenarios Of Daily Scrum
• Real Life Scenarios Of Sprint Review
• Is Daily Scrum Status Meeting?
• Is Scrum Master a PM ?
• Does Sprint Backlog represent Commitment?
• Important to decide DOD at Start?
• Myths around Sprint Length
• Myths around Sprint Planning
• Is sprint Review a Sign-off Meeting?
• Myths about Cross Functionality and Self-Management
• Should we create Multiple Backlogs?
• Scrum is useful for only Small Projects?
• PO should not be invited in Sprint Retrospective
• Sprint review being the review of the developers done by PO
• Hardening Sprint
• Sprint ZERO
• Scrum Master the solver of all impediments
• Scrum Master the Overprotector
• Product Owner as the mediator between Developers and Stakeholders
• Agile Transformation with an Improvement Backlog
• Planning Agile Transformation Sprints
• Define Tangible Agile Transformation Items
• Agile Transformation Challenges
• Choosing Right Pilot for Agile Implementation
• One-Team-Culture
• Adjusting Master Contracts during Agile Transformations
• Agile Contracts
• Metrics in Agile Projects – What Should We Focus On?
• Some Sample Agile Metrics
• Agile Metrics and The Scrum Master
• Defining Your Metrics Framework
• Early Warning Signs That Your Agile Metrics Are Not Set Right!
• Toyota Production System
• Agile Tester Skills
• Agile Test Pyramid
• Agile Testing Quadrant
• Product Strategy and Product Roadmap
• Product Lifecycle
• Product Vision
• Requirements Elicitation Techniques
• Requirements Classification Techniques
• Requirements Documentation Techniques
• Lean Software Development
• What is Muda, Muri, Mura?
• What is Six Sigma?
• Why Lean-Six-Sigma go hand-in-hand?
• What is Change Management?
• Lean and Agile Process Improvement Road maps
• DevOps Myths
• DevOps Anti-Patterns
• Benefits of DevOps
• DevOps Culture
• DevOps Organisation Structure
• DevOps Principles
• DevOps and Software Development Process
• Automation for Effective DevOps
• DevOps and Agile
• DevOps and Lean
• DevOps and Scrum
• DevOps and ITIL
• Continuous Integration
• Continuous Delivery
• Deployment Pipeline
• Continuous Deployment
• Automation Testing
• Configuration Management in DevOps
• Infrastructure as Code
• End of Service or Product Life
• DevOps Tool – Jenkins
• Cucumber – BDD Testing Tool
• Amazon Elastic Block Store (EBS)
• Amazon Elastic Compute Cloud (EC2)
• PRINCE2 Principles
• PRINCE2 Themes
• PRINCE2 Processes
• Product based Planning Technique in PRINCE2
• Tracking Business Case in PRINCE2
• Project Product Description & Product Description
• What is Risk as per PRINCE2 and How to Manage it?
• How to Embed PRINCE2 in the Organisation
• PRINCE2 Project Organisation and Scrum
• Difference Between PRINCE2® and PRINCE2 Agile®
• Tailoring PRINCE2 to suit your Project Environment
• Track Progress in a Typical PRINCE2® Project
• Blending PRINCE2 and Agile Together
• What to fix and what to flex for a PRINCE2 Agile project?
• PRINCE2 Agile Behaviours
• PRINCE2 Agilometer
• Rich Communication with PRINCE2®
• Workshops for Rich Agile Communication
• What is ITIL?
• ITIL4 Certification Scheme
• 4 Dimensions of Service Management
• Utility and Warranty in ITIL
• 7 Guiding Principles
• ITIL 4 General Management Practices
• ITIL 4 Service Management Practices
• ITSM – ITIL : How Similar and How Different?
• What is Service Desk?

WhatsApp us

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

• SAFe Contributors
• Extended SAFe Guidance
• Community Contributions
• SAFe Beyond IT
• Books on SAFe
• Download SAFe Posters & Graphics
• Presentations & Videos
• FAQs on how to use SAFe content and trademarks
• What’s new in the SAFe 5.1 Big Picture
• Recommended Reading
• Learn about the Community
• Member Login
• SAFe Implementation Roadmap
• Find a Transformation Partner
• Find a Platform Partner
• Customer Stories
• SAFe Training

Everything must be made as simple as possible. But not simpler. —Albert Einstein

Large Solution SAFe

Large Solution SAFe (Figure 1) configuration includes the following constructs:

• The Essential SAFe configuration
• An additional competency, Enterprise Solution Delivery that describes how to apply Lean-Agile principles and practices to the specification, development, deployment, operation, and evolution of the world’s largest and most sophisticated software applications, networks, and cyber-physical systems.
• The large solution level roles, artifacts, and events
• The full spanning palette
• A connection to the Enterprise or Government entity the solution supports

This configuration includes a stronger focus on capturing requirements in the Solution Intent, coordinating multiple Agile Release Trains (ARTs) and Suppliers, and ensuring compliance with regulations and standards.

Large Solution SAFe is meant for enterprises that face the biggest challenges—building large-scale solutions that are beyond the scope of a single ART to develop. Building these solutions requires additional roles, artifacts, events, and coordination.

The remainder of this article describes the highlights, roles, events, and artifacts presented in the large solution level (Figure 2).

The Solution Train is the organizational vehicle that coordinates the efforts of multiple ARTs and suppliers to deliver the world’s largest and most complex systems. The value delivered by Solution Trains can range from core banking applications in global financial institutions to jet fighters and satellite systems. Lean Enterprises that build these systems-of-systems require abilities, principles, and practices beyond those followed by a single ART. For further discussion and a set of best practices for building large solutions read the Enterprise Solution Delivery competency article.

Large Solution Highlights

Below are the highlights of the Large Solution level:

• Solution Train – The solution train is the key organizational element of the Large Solution SAFe and aligns the people and the work towards a common solution vision, mission, and backlog.
• Solution Intent – Solution intent is a repository for current and future solution behaviors, which can be used to support verification, validation, and Compliance. Solution intent is also used to extend Built-In Quality practices with systems engineering disciplines, including Set-Based Design , Model-Based Systems Engineering  (MBSE), Compliance , and Agile Architecture .
• Solution Kanban – Solution Kanban is a method used to visualize and manage the flow of business and enabler capabilities from ideation to analysis, implementation, and release.
• Spanning Palette  – Includes the full spanning palette and all its elements.

The Large Solution SAFe roles help coordinate multiple ARTs and suppliers and provide the necessary cross-ART coordination and governance:

• Solution Architect/Engineering – The Solution Architect/Engineer represents an individual or small team that defines a common technical and architectural vision for the solution under development.
• Solution Management – Solution management is the content authority for Large Solution SAFe. They work with customers to understand their needs, create the solution vision and roadmap, define requirements (capabilities and enablers), and guide work through the solution Kanban.
• Solution Train Engineer (STE) – The Solution Train Engineer is a servant leader and coach who facilitates and guides the work of all ARTs and suppliers.
• Supplier – Suppliers are an internal or external organization that develops and delivers components, subsystems, or services, which help Solution Trains deliver solutions to customers.
• Shared Services – Shared services represents the specialty roles, people, and services required for the success of an Agile Release Train (ART) or Solution Train, but that cannot be dedicated full-time.
• Communities of Practice (CoP) – CoPs are organized groups of people who have a common interest in a specific technical or business domain who regularly share information, improve their skills, and actively work on advancing the general knowledge of the domain.

Large Solution SAFe uses three major activities to help coordinate multiple ARTs and suppliers:

• Pre- and Post-PI Planning – Pre- and post-PI Planning are used to prepare for, and follow up after, Program Increment (PI) Planning for ARTs and suppliers in a Solution Train.
• Solution Demo – The solution demo shows the results of all the development efforts from multiple ARTs—along with the contributions from suppliers—are integrated, evaluated, and made visible to customers and other stakeholders.
• Inspect & Adapt (I&A) – Inspect & adapt is a significant event where the current state of the integrated solution across all ARTs is demonstrated and evaluated. Solution Train stakeholders then reflect and identify improvement backlog items via a structured problem-solving workshop.

The following Large Solution SAFe artifacts help coordinate multiple ARTs and suppliers:

• Capabilities – Capabilities are a higher-level solution behavior that typically spans multiple ARTs. They are sized and split into multiple features so that they can be implemented in a single PI.
• Enabler Capabilities – Enabler capabilities support the activities needed to extend the  Architectural Runway  to provide future business functionality and include exploration, architecture, infrastructure, and compliance.
• Solution Epics – Solution Epics are epics implemented by a single Solution Train.
• Nonfunctional Requirements (NFRs) – NFRs define system attributes such as security, reliability, performance, maintainability, scalability, and usability. These are incorporated in solution intent.
• Solution Backlog – Solution Backlog is the holding area for upcoming capabilities and enablers, each of which can span multiple ARTs and are intended to advance the solution and build its architectural runway.

Apply SAFe Elements to Other Configurations

SAFe introduces a number of unique elements in the different configurations. Generally, any SAFe element may be applied to any SAFe configuration. For example, a single ART building a medical device of modest scale will likely have one or more suppliers and a solution intent to manage compliance. Or DevOps could be used by a solution train building a LIDAR system for autonomous vehicles. This is part of SAFe’s scalability and versatility (Figure 4).

Last update: 10 February 2021

Privacy Overview

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.