problem solving workshop in safe

• 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

Conflict Management: 5 Key Sources of Conflict

Mastering SAFe: What Every Business Professional Should Know

• Practice Exam

Navigating the Inspect & Adapt Workshop: The Key to Continuous Improvement in SAFe

0  Comments

In the dynamic world of Agile, the Inspect & Adapt Workshop stands as a cornerstone in the Scaled Agile Framework (SAFe). It’s a pivotal moment where Agile teams converge to reflect, learn, and plan for the future. But what exactly are the outcomes of this workshop? Today, let’s delve into the heart of this process and understand why “Identifying and prioritizing process improvements” is not just an option, but the primary outcome of the Inspect & Adapt Workshop.

The Essence of the Inspect & Adapt Workshop

At its core, the Inspect & Adapt (I&A) Workshop is a structured problem-solving session. It marks the end of the Program Increment (PI) and serves as a critical reflection point. Teams gather to inspect their achievements and adapt their processes, learning from their experiences. It’s not just about what we did, but how we did it and how we can do it better.

Why Process Improvement is Key

Among the options provided – creation of user stories, release of the product to customers, and setting the agenda for the next PI – identifying and prioritizing process improvements stands out. Why? Because continuous improvement is the lifeblood of Agile. While releasing products and creating user stories are essential, they are part of the ongoing Agile process. The I&A Workshop’s unique contribution is its focus on elevating the process itself.

Real-Life Application

Imagine a team working on a software development project. They’ve had a successful PI, with several user stories completed and features shipped. However, during the I&A Workshop, they realize that certain bottlenecks in communication slowed them down. By identifying and addressing these issues, the team sets the stage for more efficient sprints in the future, ultimately leading to better products and happier customers.

The Inspect & Adapt Workshop is more than a routine meeting; it’s an opportunity for genuine growth. By focusing on process improvements, SAFe practitioners ensure that their Agile journey is not static but a path of continuous evolution and enhancement

You may also like

Agile vs. waterfall: why agile development wins for businesses and teams, the plan-do-check-adjust cycle in scrum: a continuous process, get in touch.

Session expired

Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.

SPCT Journey Webinar by Jayaprakash Prabhakar (JP) : Register Now

What is Inspect and Adapt in SAFe Framework and How does it Work?

Agile teams believe in continuous feedback system. In every iteration, feedback comes in multiple ways

• Product Feedback is received through iteration review at the end of every iteration
• Iteration retrospective to look back and improve in terms of people and process

This helps the team to continuously improve and become a much better product and product team. However, in a Scaled Agile environment, there are multiple teams working on a single product. Its equally important for the program (or Agile Release Train) to get into a feedback system.

There are many methods, events, and principles that are incorporated with SAFe, and most of them are being used in the product development on a large scale. One thing that is still needed to get a spot is the concept of Inspect and Adapt (I&A). 

In Scaled Agile, Inspect & Adapt is the way to look back and take feedback on product, process, people etc. Like how Iteration Review and Retrospective happens at the end of the iteration, Inspect & Adapt happens at the end of the Program Increment, is also called as PI.

Not only you are going to learn all about this concept, but we are going to let you know about SAFe Agile certification that will help you open various doors for your bright career. So let us begin by diving deep and getting to know I&A more.

What is Inspect and Adapt in SAFe?

It is known as one of the significant events that will happen at the end of each Program Increment (PI). The PI mentioned here generally consists of 8-12 weeks. During this period, the Agile Release Train delivers incremental value to the customer which is the fully working systems built in the last 1 PI.

The current state of the product along with the process which was used to get to that position is being discussed during the I&A event which happens at the end of every Program Increment (PI).

With this event, it can be made sure that the upcoming PI is going to be better and more efficient. Inspecting and putting efforts into improving the product as well as the process will help in getting there. The event is attended by the stakeholders as well and they help in providing the inputs that are added to the backlog of the next PI planning.

In the SAFe Agilist training , you will be able to learn more about PI and how to calculate the metrics as well.

How does this Work?

Inspect & Adapt consists of 3 parts

• The PI system Demo
• Quantitative & Qualitative Measurement
• Retrospective and problem solving workshop

The PI System Demo

The first part of I&A is the PI System Demo. As the name suggests, the ART would showcase the current system that was built in the last 1 PI. This will cover a larger set of people in the event so that this information is available to all. This includes all the key stakeholders from Portfolio, Customers to attend the demo.

This is to demonstrate the solution that was built the entire ART during this PI. This event is time-boxed to 1 hour. The focus of this event is all about product demo.

At the end of the PI system demo, Business Owners connect with each team and rate their team’s PI objectives by providing actual business value.

Quantitative & Qualitative Measurements

This is another 60-minute session where quantitative, as well as qualitative measures, are being taken to evaluate the products and processes that are part of ART. In this event, 

Program / ART level metrics are displayed to the entire audience. One of the primary measures displayed is “Program Predictability Measure”. Each team’s predictability based on business value delivery is measured and then the overall program predictability is consolidated, like it is depicted in the below picture.

ART can also measure few qualitative measures like agile assessments, product delivery assessments, role specific assessments etc.

Retrospective 

The teams come together and addresses the issues that need to be put on the table during the problem-solving workshop. From the issues that they have identified in different teams, they will choose the top few issues for the problem-solving workshop.

Teams can use any of the retrospective techniques to conduct this retrospective to identify their issues.

Problem-Solving Workshop

ART comes together and conducts this workshop to identify 1-2 key problems, find root causes and find solutions for the root causes. This is a six-step process .

The whole process takes approximately 4 hours for the entire ART . Let’s quickly look at each step.

• Agree on the problem to solve

A well stated problem is half-problem solved. Hence, it is critical to identify and state the problem clearly. A well-stated problem addresses “What?”, “Where?”, “When?” and “Impact”.

• Apply root-cause analysis

Once the problem is well-stated, team gets into identifying the root causes for the problem, in – process, people, tools, program and environment. 

• Identify the biggest root cause

There can be multiple root causes for a specific problem identified. Its not humanly possible to fix all the root causes, hence its important to identify the biggest root cause. This is done using Pareto analysis tool.

• Restate the new problem

This step is to restate the problem with the biggest root cause identified.

• Brainstorm solutions

Identifying some potential solutions is the objective in this step. Here are few rules for applying brainstorming

• Come up with as many ideas as possible
• All ideas are welcome
• Combine / merge ideas
• Create Improvement backlog items

The last step is to identify 1-2 solutions that can be implemented in the next PI itself. RTE facilitates the entire I&A event. 

Why is Inspect &Adapt an Important Event?

I&A should be done in every PI, because this is a great opportunity to get the feedback on the product, people and process. It helps the entire ART to continuously improve in every PI.

Adopting lean-agile thinking and practices takes time and will involve a lot of best approaches to achieve. To incorporate lean-agile thinking to make decisions, the use of SAFe Inspect and Adapt becomes very crucial. This allows the business to make sure that the products, as well as processes, are going on the right track.

This will strengthen that Agile Release Train and make sure that proper guidelines of a SAFe framework are being practiced. This will push the teams to give their best in the product development. With the best SAFe Certification training from LeanWisdom , you can ensure that you are getting trained by the best professionals in the industry.

Not only it will open a plethora of doors of opportunities for you, but prepare you for the challenges that you need to face while climbing up the ladder of success in this field. So choose the right platform for your bright career and get started.

You May Also Like

VMO’s Critical Role in Improving Value Stream Flow

10 differences between Scrum & SAFe

Utilizing Kanban Systems for Capability Delivery

Understanding SAFe Roadmaps

SAFe Implementation Roadmap: The Definitive Guide

Role of System Architects in PI Planning and Execution

INVEST Criteria For User Stories in SAFe

Leading SAFe vs SAFe POPM – A detailed Comparison

A deep dive in SAFe Configuration and Customization

Drop Your Query

Lean Agile Guru

Lean Agile Ideas Worth Spreading For The SAFe Enterprise

• Lean Agile Software Factory
• New Book! The Inner and Outer Game Of SAFe 6.0
• Merchandise
• SAFe Classes
• Meet The Guru
• Testimonials
• Free Members Only
• Platinum Members Only
• Elite Circle Members Only
• Login/Logout
• Your Partner
• Take Action

Drive Relentless Improvement via ‘Inspect and Adapt’

Application: the famous Plan, Do, Check, Adjust/Adapt (PDCA) is a learning cycle…things are inspected and adaptation follows based on what has been learned and observed. This cycle occurs at every level be it team level, program level, or solution level… hence the mantra ‘Inspect and Adapt’ for relentless and continuous improvement.

At the program Level of SAFe, there is a program event called ‘Inspect and Adapt (I&A)’. No surprise there. The purpose of which is exactly that, to pursue relentless and continuous improvement.

It comes in three parts: 1) the system demo; 2) the quantitative measurement; 3) retrospective and problem solving workshop.

Remember relentless and continuous improvement? Yeah…make sure that you put the improvement items to the team/program improvement backlog and roadmap… and address / act upon these… otherwise, what’s the point of having this ‘Inspect and Adapt’?

Kaizen is about changing the way things are. If you assume that things are all right the way they are, you can’t do kaizen. So change something! —Taiichi Ohno

You will get a FREE SIGNED COPY if/when you register, pay, and complete a class by the Lean Agile Guru .

Share this:

By Clarence Galapon

CE, MBA, Lean Agile Coach, Trainer, Teacher, SPC, RTE, PSM, PMI-ACP, PMI-PBA, PMP, CC, ABNLP NLP (Neuro Linguistic Programming) Practitioner, NLP Coach, NLP Trainer, Practical Psychologist, Life Coach, Software Executive, Entrepreneur, Author, Investor, and Innovator with a Creative, Lean, Agile, and Wander mindset. https://LeanAgileGuru.com

Related Posts

Start With The End In Mind

The Snowball Effect

When is Inspect and Adapt?

Remember me

Forgot Password?

Discover more from Lean Agile Guru

Subscribe now to keep reading and get access to the full archive.

Type your email…

Continue reading

{{ ftc.framework.name }}

Your email address is used to securely create and identify your SAFe® Collaborate account so that you can access the data created when you participate in SAFe® Events . Your email is not stored until you give consent.

Forgot password?

Learn more about SAFe® Studio access and benefits, including access to this and other advanced collaboration templates and much more.

• SAFe® Community
• SAFe® Support
• Privacy Policy

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.

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

Whenever you let up before the job is done, critical momentum can be lost and regression may follow. —John Kotter, Leading Change

Coach ART Execution

This is article nine in the SAFe ® Implementation Roadmap series. Click here to view the entire roadmap.

The previous articles in the SAFe Implementation Roadmap series described the first eight steps:

• Reaching the Tipping Point
• Train Lean-Agile Change Agents
• Train Executives, Managers, and Leaders
• Create a Lean-Agile Center of Excellence (LACE)
• Identify Value Streams and Agile Release Trains (ARTs)
• Create the Implementation Plan
• Prepare for ART Launch
• Train Teams and Launch the ART

At this stage of the implementation, the first big events are now in the rearview mirror. Teams have been trained, the first ART is launched, and the first Program Increment (PI) Planning event has been held. The result of all this effort is an empowered, engaged, and aligned team-of-Agile-teams ready to begin building solutions that deliver value.

Before moving on to the critical work of the train, it’s important to understand that training and planning alone do not make the newly formed teams and ARTs Agile . They simply provide the opportunity to begin the journey of becoming Agile. To support this journey, leadership—and SAFe Program Consultants (SPCs) in particular—must be mindful that knowledge does not equal understanding. It takes time to achieve effective team-level Agile practices and behaviors (typically several PIs), which is why significant effort must be made to coach ART execution.

To reach this point, the enterprise has made a significant investment in developing SPC change agents and training stakeholders in the new way of working. Now is the time for that investment to pay off, as SPCs and Lean-Agile Leaders focus on what really matters: helping to assure the delivery of value in the shortest sustainable time while producing the highest quality. That will start to happen with team-level and ART-level coaching.

Team Coaching

While new SPCs often focus on enabling the program level roles and events, the foundation of Program Execution is built upon is a competency in Team and Technical Agility .  SPCs must also provide coaching to  Agile Teams .

Initially, team coaching will likely focus on mastering the team level SAFe roles and events, including:

• Iterati on planning – refine and adjust initial iteration plans developed during PI Planning
• Backlog refinement – refine and adjust the scope and definition of user stories defined during PI Planning
• Daily stand-ups – to help the team stay aligned on progress toward iteration goals, raise impediments and get help
• Iteration Revi ews  and  System demos – to get feedback from stakeholders and assess progress toward PI Objectives
• Iteration Retrospectives – to review team practices and identify ways to improve
• Scrum-of-Scrums , PO Sync and ART Sync – to maintain alignment and resolve issues with other teams on the ART

But this is only the beginning.  As teams gain confidence in their roles and events, and because of the transparency they create, technical proficiency and best practice will become the next opportunity for relentless improvement.  In order to establish a smooth and consistent flow of value, Agile Teams working on software solutions must become proficient in modern software engineering techniques and disciplines such as Test Driven and Behavior Driven Development, Continuous Integration/Deploy, Test Automation, and Pair Programming. These practices were established in the Extreme Programming (XP) movement and remain the foundation for software craftsmanship. For a summary of these practices, see the article on Built-in Quality  as well as the Team and Technical Agility competency article.

The Agile Software Engineering course can be used as a continuing education offering during the first  Innovation & Planning iteration, or during a subsequent PI as need and opportunity dictates, to accelerate the development of these critical software engineering disciplines.

During this three-day, workshop-oriented course, attendees will learn how Lean-Agile principles are driving these changes.  They will connect these principles to modern developing practices including XP technical practices, Behavioral-Driven Development (BDD), Test-Driven Development (TDD), and applying the Agile Testing Quadrant. Attendees will learn the best practices to model, design, implement, verify, validate, deploy, and release stories in a SAFe Continuous Delivery Pipeline.

ART Coaching

While Team and Technical Agility forms the foundation of Program Execution, it’s the Agile Product Delivery competency that enables the shortest sustainable lead-time to value.  Without coaching from SPCs to develop and grow this competency, Essential SAFe can become reduced to the coordination and orchestration of Agile teams – a pale shadow of its potential. Therefore, SPCs engage with Scrum Masters across the ART to help accelerate adoption and mastery of this competency.

As with Agile Teams, coaching the ART typically starts with the essential SAFe roles and events, including:

• PI Planning – create alignment and shared commitment to a common set of objectives
• System Demos – close the rapid feedback loop through integration and validation of working systems
• Inspect & Adapt Workshops – enable relentless improvement and systems thinking
• Scrum-of-Scrums, PO Sync, and ART Sync – maintain alignment, resolve issues, and enable attainment of PI Objectives

But these just scratch the surface of the ART’s purpose and potential.  To help ARTs optimize the flow of value, SPCs must coach ART leaders to look beyond the current PI and current capabilities.  As roles and events are mastered, the focus must shift to the Continuous Delivery Pipeline  and the enterprise competency of  Agile Product Delivery .  This involves both managing and continuously improving the speed and quality of the ART’s capability to:

• Continuously Explore :  Sense and respond to market/business needs to build and maintain the program Vision ,  Roadmap , Backlog and Architectural Runway .
• Continuously Integrate :    Build, validate and learn from working system increments
• Co ntinuously Deploy :   Deliver validated features into production, where they are ready for release

The Program Kanban is the primary tool for visualizing and managing the continuous delivery pipeline, while DevOps , Value Stream Mapping, and the Problem Solving Workshop are the coach’s primary tools for enhancing these capabilities.

The SAFe DevOps course can be used as a foundation for these practices during the 1st Innovation & Planning iteration , or for continuing education during subsequent PIs as the need and opportunity dictates, to accelerate development of this competency.

The course will build an understanding of the complete flow of value from Continuous Exploration to Continuous Integration, Continuous Deployment, and Release on Demand.

Attendees will leave with the tools they need to execute an implementation plan for improving their delivery pipeline, and the knowledge they need to support the plan. The course also prepares students for the optional SAFe® 4 DevOps Practitioner (SDP) certification exam.

Clearly, there’s no shortage of opportunities for SPCs and Lean-Agile Leaders to practice and demonstrate their new skills and mindset.

An important note: For first-line development and engineering managers, the move to SAFe and Lean-Agile adoption can be scary. Traditional daily and task-oriented supervision is no longer required. Instead, these new ‘Lean-thinking manager-teachers’ adopt a servant-leader approach and take on a different set and style of activities as described in the Lean-Agile Leaders article. The short coaching list above also serves notice that the knowledge and skills of our managers and leaders are incredibly valuable, as there is much work to be done. It just needs to be done differently.

Inspect and Adapt

This gives teams the tools they need to improve their performance independently. It also allows them to work together—along with their management stakeholders—to collaboratively address the larger impediments that they face.

Moving Forward

For the first ART, then, it’s onward in their journey of relentless improvement. But for the reader, it’s on to the next article in the Implementation Roadmap series: Launch More ARTs and Value Streams .

Additional Resources

SAFe Program Increment Toolkit

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.

Back to Guides

How to run a problem-solving workshop.

What is a problem-solving workshop?

A problem-solving workshop is a rapid session that helps you:

• Understand the root cause of a problem
• Quickly generate ideas to solve it
• Evaluate the ideas to ensure they’re robust
• Make a plan to test or implement the solution

This workshop critically assesses what’s going wrong and helps you find out what your options are to solve it, before you decide on the perfect solution.

Who should run a problem-solving workshop?

Product team leads, such as designers, product managers or engineers can run this type of workshop. There’s no one right person to lead something as important as this.

In fact, the core of your product development should start with the problem rather than the solution itself. It can be tempting to jump straight into features, but until you understand the problem well, you can’t begin to solve it.

When to run a problem-solving workshop

This workshop can be used in various circumstances:

• A show-stopping problem that grinds everything to a halt
• An intermittent problem that you want to get to the bottom of
• A customer or user problem, such as a pain point when using a service or product
• A high-level business problem, for example “too many customer complaints”, “conversion rate is too low”, or “operating costs are too high”

1. Get the right people together

2. identify the right problem.

• 3. Come up with ideas to solve the problem

4. Evaluate the ideas to ensure they’re robust

5. make a plan to test or implement the solution.

Read on to find out how to do all that, and more.

Invite all affected parties to a session. These are people that the problem has a direct impact on. Including those that aren’t impacted may offer a more objective view, but ultimately; more people equals more time. We want to solve problems with haste, so we can find out if it’s the right solution sooner rather than later!

What may appear like the problem, could be one of many observable results of a deeper underlying problem. To identify the ‘right’ or ‘true’ problem, we need to delve into it. This method is often called “Root Cause Analysis”.

There are many ways to conduct a Root Cause Analysis, but the easiest and most pragmatic way is to use the  Five Whys Analysis tactic .

Simply put, asking “why?” at least five times will lead you to the real problem. Solving this root problem subsequently solves all of the surface problems associated with it.

Learn how to run the Five Whys Analysis tactic

3. Come up with ideas to solve your problem

What normally follows identifying the right problem is a flurry of ideas. This usually takes the form of blurting them out at each other – but there are better, more structured ways to capture ideas.  Generating ideas in a structured way gives you time and space to think, as well as building on others’ ideas. The result means more thorough and refined ideas, over a back of the napkin sketch that the loudest person in the room decides is the best thing to do.

Idea-generation tactics for problem solving:

• Mind Map  – Get your brain on to paper, so you can start to form ideas for the methods below.
• Crazy Eights  – Eight ideas in eight minutes
• Reverse Brainstorm  – Come up with ways to make the problem  worse,  then reverse it to get the solution
• Round Robin  – Generate an idea, then have the person next to you build on it
• Storyboard  – Turn your idea into a sequence of events to understand how it might actually work in reality

Once you have a suite of ideas, you’ll want to review them and try some  evaluative tactics .

If you have a lot of ideas, you might want to prioritise the most promising ones to take forward with a decision tactic such as  Priority Map  or  Blind Vote .

Once you have a shortlist of ideas it can be tempting to go with the one that appears most promising. If time is of the essence, and it’s low risk – it might be the right call to just try it out.

However, it’s vital to evaluate ideas for solutions that may be more costly or complicated. Kick the tyres, so to speak.

Evaluating ideas gives you the confidence that your promising idea truly is promising, and is worthy of taking forward to the next stage: prototyping and implementation.

Evaluation tactics for ideas:

• Idea Beetle  –  a set of questions that help you assess if your idea is robust before you progress with it
• Rose, Thorn, Bud  –  a way to review the good, the bad and the potential of an idea
• SWOT Analysis  –  articulate an idea’s strengths, weaknesses, opportunities or threats

If you still have a lot of ideas, you might want to prioritise the most promising ones to take forward with a decision tactic such as  Priority Map  or  Blind Vote .

Now you should have one or two (or more!) evaluated, robust and promising ideas that you want to try out to solve the problem.

Whether you need to work out how to prototype and test the idea, or go ahead and implement the solution right away – you need a plan.

To work out a plan, use the  Sticky Steps tactic , which mentally starts you off at having the solution implemented or prototype tested, then works backwards to today in order to see what steps you need to take.

Once you have a solid plan, create accountability by creating a list of tasks to do, and assigning them to people with a deadline. You can do this with the  Who, What, When tactic .

2 thoughts on “How to run a problem-solving workshop”

Hi I’d love to know approx about how long it should take to run one of these workshops. If you could include that in your very helpful summaries – I think that would be very helpful to plan and market these types of servies.

Appreciate all you do! R

All activities are very helpful.

Appreciate you Nazia Psychologist

Leave a Comment Cancel reply

Let us know what thoughts or questions you have about this guide so we can improve it.

If you leave us your email, we'll let you know if we update this guide based on your feedback.