problem solving workshop in agile

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

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

Inspect and Adapt

Inspect & adapt: overview.

The Agile Manifesto emphasizes the importance of continuous improvement through the following principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

In addition, SAFe includes ‘relentless improvement’ as one of the four pillars of the SAFe House of Lean as well as a dimension of the Continuous Learning Culture core competency. While opportunities to improve can and should occur continuously throughout the Program Increment (PI) (e.g., Iteration Retrospectives ), applying some structure, cadence, and synchronization helps ensure that there is also time set aside to identify improvements across multiple teams and Agile Release Trains.

All ART stakeholders participate along with the Agile Teams in the I&A event. The result is a set of improvement backlog items that go into the Program Backlog for the next PI Planning event. In this way, every Agile Release Train (ART) improves every PI. For large solutions , a similar I&A event is held by the Solution Train .

The I&A event consists of three parts:

PI System Demo

Participants in the I&A should be, wherever possible, all the people involved in building the solution. These include for an ART:

Additionally, Solution Train stakeholders may attend this event.

The PI System Demo is the first part of the I&A, and it’s a little different from the regular system demos that happen after every iteration, in that it is intended to show all the Features that the ART has developed over the course of the PI. Typically the audience is broader, for example, customers or Portfolio representatives are more likely to attend this demo. Therefore, the PI system demo tends to be a little more formal, and some extra preparation and staging are usually required. But like any other system demo, it should be timeboxed to an hour or less, with the level of abstraction high enough to keep stakeholders actively engaged and providing feedback.

Prior to, or as part of the PI system demo, Business Owners collaborate with each Agile team to score the actual business value achieved for each of their Team PI Objectives .

Quantitative and Qualitative Measurement

In the second part of the I&A event, teams collectively review any quantitative and qualitative metrics they have agreed to collect, then discuss the data and trends. In preparation for this, the RTE and the Solution Train Engineer are often responsible for gathering the information, analyzing it to identify potential issues, and facilitating the presentation of the findings to the ART.

One primary metric is the program predictability measure. Each team’s planned vs. actual business value is rolled up to create the program predictability measure, as shown in Figure 2.

Reliable trains should operate in the 80–100 percent range; this allows the business and its external stakeholders to plan effectively. (Note: Uncommitted objectives don’t count toward the commitment but do count toward the actual business value achievement, as can also be seen in Figure 1.)

Retrospective

The teams then run a brief (30 minutes or less) retrospective, the goal of which is to identify a few significant issues they would like to address during the problem-solving workshop . There is no one way to do this; several different Agile retrospective formats can be used [3].

Based on the retrospective, and the nature of the problems identified, the facilitator helps the group decide which issues they want to tackle. Each team may work on a problem, or, more typically, new groups are formed from individuals across different teams who wish to work on the same issue. This self-selection helps provide cross-functional and differing views of the problem, and it brings together those who are impacted and those who are best motivated to address the issue.

Key ART stakeholders—including Business Owners, customers, and management—join the teams in the retrospective and problem-solving workshop. Often it is the Business Owners alone who can unblock the impediments that exist outside the team’s control.

Problem-Solving Workshop

For addressing systemic problems, a structured, root-cause problem-solving workshop is held by the ART. Root cause analysis provides a set of problem-solving tools used to identify the actual causes of a problem, rather than just addressing the symptoms. The session is typically facilitated by the RTE, in a timebox of two hours or less.

Figure 3 illustrates the steps in the problem-solving workshop.

The following sections describe each step of the process.

Agree on the Problem(s) to Solve

American inventor Charles Kettering is credited with the statement that “a problem well stated is a problem half solved.” At this point, the teams have self-selected the problem they want to address. But, do they agree on the details of the problem, or is it more likely that they have differing perspectives? To this end, the teams should spend a few minutes clearly stating the problem, highlighting the ‘what’, ‘where’, ‘when’, and ‘impact’ as succinctly as they can. Figure 4 illustrates a well-written problem statement.

Perform Root Cause Analysis

Effective problem-solving tools include the fishbone diagram and the ‘5 Whys.’ Also known as an Ishikawa Diagram , a fishbone diagram is a visual tool used to explore the causes of specific events or sources of variation in a process. Figure 5 illustrates the fishbone diagram with a summary of the previous problem statement written at the head of the ‘fish.’

For our problem-solving workshop, we preload the main bones with the categories people, process, tools, program, and environment. However, these may be adapted as appropriate.

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.

Identify the Biggest Root Cause

Pareto Analysis , also known as the 80/20 rule, is a technique used to narrow down the number of actions that produce the most significant overall effect. It uses the principle that 20 percent of the causes are responsible for 80 percent of the problem. It’s especially useful when many possible courses of action are competing for attention, which is almost always the case with complex, systemic issues.

Once all the possible causes-of-causes have been identified, team members then cumulatively vote on the item they think is the most significant factor contributing to the original problem. They can do this by dot voting (five votes are allocated to each person, which can be spread among one or more items as they see fit) on the causes they think are most problematic. The team then summarizes the votes in a Pareto chart, such as the example in Figure 6, which illustrates their collective consensus on the most significant root cause.

Restate the New Problem

The next step is to pick the cause with the most votes and restate it clearly as a problem. This should take only a few minutes or so, as the teams have a good understanding of this root cause by now.

Brainstorm Solutions

At this point, the restated problem will start to imply some potential solutions. The team brainstorms as many possible corrective actions as they can think of within a fixed timebox (about 15–30 minutes). The rules of brainstorming apply here:

Create Improvement Backlog Items

The team then cumulatively votes on up to three most likely solutions. These are rephrased as improvement stories and features to be fed directly into the PI Planning event that follows. 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.

Inspect and Adapt at the Large Solution Level

The above describes a rigorous approach to problem-solving in the context of a single ART. If the ART is part of a Solution Train the I&A event will often include key stakeholders from the Large Solution level. In larger value streams, however, an additional large solution level I&A event may be required, following the same format.

Due to the number of people in a Solution Train, attendees at the large solution I&A event cannot include everyone, so stakeholders are selected that are best suited to address the problems faced. This includes the primary stakeholders of the Solution Train, as well as representatives from the various ARTs and Suppliers .

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.

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. ).

Definition of Done: Why is it so important?

Implementing change in complacency-filled organizations

Privacy overview.

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.

Not a Member?

The sun never sets on the problem-solving workshop, about this publication.

A fundamental agile principle is “…the team reflects at regular intervals how to become more effective” The SAFe Inspect and Adapt Problem Solving workshop is a wonderful opportunity for everyone on an Agile Release Train (ART) to reflect on becoming more effective. However, what happens when the ART teams are massively distributed, such that the Sun truly never sets on the ART? How do you provide everyone on the ART an opportunity to reflect and collaborate with others who have similar interests, and not just their local cohorts? How do you enable all to participate in the problem-solving session, to raise and solve problems that are important to them, and not just the problems that are important and visible to “home base” or as we called it, the mother ship? This is the situation we faced at a large multi-national energy company preparing to conduct their first SAFe problem-solving workshop. This is our story for how we executed a problem-solving workshop for an ART on which the Sun never set.

1. INTRODUCTION: “ The Team Reflects at Regular Intervals How to Become More Effective ” – Agile Principles

Agility is not just about continuously learning and adapting the work product, but also reflecting on and adapting the work process itself. Continuous improvement is fundamental to high performing teams and most agile methodologies have a built-in process review like Scrum’s retrospective. The Scaled Agile Framework (SAFe tm ) builds on top of this team level view with a problem-solving workshop that is conducted at the end of a Program Increment (big time box) to understand the opportunities for improvement across all teams on the Agile Release Train (ART).

2. BACKGROUND

Our client is a marquee multi-national energy company with operations around the globe and with an ART spanning the globe. While headquartered in US, teams are located across the US and around the world including London, Buenos Aires, Manila, Perth, and Kazakhstan. Literally, the Sun does no set on the program. Our program was moving applications from the on-premise data center to the cloud. While our program was organized on paper as SAFe Solution Train (a train of trains), it operated very much like an oversized single ART, with over 30 teams and with nearly 400 people involved. Our “train” ran 6 two-week iterations, including a 2-week IP sprint. This was our sixth PI and to date, and while the individual teams conducted team level retrospectives, there had not been an overall review of how the train(s) worked together. As the trains were growing rapidly beyond what heroic ad hoc problem solving could resolve, we decided it was important to start systematically “reflecting at regular intervals how to become more effective” and began planning a SAFe problem solving workshop.

3. NO MOTHERSHIP

The SAFe problem-solving workshop is part of the SAFe Inspect and Adapt event. General guidance for the problem-solving workshop is that it is about a two-hour process, where all members of the ART participate. This creates a fantastic opportunity for people to collaborate with others beyond their immediate team members. There is an implied assumption that everyone is in the same room. This, of course, was totally impossible for us, unless we wanted to fly everyone to corporate head office in the US.

A typical solution to this distribution problem is what we sometimes referred to as the “mothership” approach. We could hold the problem-solving session at the head office – the mothership – and use video collaboration tools like WebEx or GotoMeeting or Zoom to engage everyone else. Unfortunately, this approach was most likely to only give us a North American point of view and not a true global view. We wanted to avoid a North America centric problem-solving session for as one plucky Australian noted, more than 50% of the value of the train came from outside of North America. Experience suggests when there is a face to face mothership style meeting with other members engaging online, the online members are not engaged and are at best lurkers.

Conducting a “mothership” problem solving workshop, could have reinforced the perception that head office was the center of the universe as most of the senior staff such as the RTEs, Program Managers, Architects, were located there. Finally, scheduling a single “mothership” session is not respectful of people because we would be asking a fair portion of the train to participate in the middle of their night. Therefore, we did not want to conduct a “mothership” style of problem-solving workshop. We needed an approach that created the same opportunity for everyone to participate.

4. EVERYONE ONLINE

While co-location and face to face conversations are much touted in the agile community, the reality of large-scale systems development is that many people from around the world collaborate to create those large systems. The Agile Principles were written nearly 20 years ago when collaboration technology was at its infancy. Ideally teams that must work closely together are physically close together, but they still need to interact with their global colleagues. Online collaboration is a fact of life and modern tools offer a fair approximation of a physical face to face meeting. With the decision made to conduct the problem-solving workshop online, the next issue was determining how to run the meeting on a program with a never setting Sun.

5. AN AGENDA FOR A GLOBAL WORKSHOP

SAFe outlines a six-step agenda for the two-hour problem-solving workshop:

It was apparent that we were not going to execute this agenda as a two-hour workshop, at least not if we wanted the entire train to actively participate. Instead, we devised a 1 week rolling agenda:

5.1 Step 0: Train the Scrum Masters on the Process

We were relying on the Scrum Masters to “fly solo” and work with their teams to facilitate the event. Thus, we trained our Scrum Masters with the intention behind the SAFe problem-solving workshop, our multi-day rolling agenda, and their role in making it happen. This was a two-hour training session with the agenda dates and activities.

5.2 Step 1: Agreeing on the problem to solve.

Step one in the SAFe problem-solving agenda is to come up with the three to five problems that are of the highest interest to everyone on the train. The intention of this step is to give everyone in the room a voice. In a text book problem-solving session, everyone is in the same room and usually writes issues of concern to them on a sticky note. These are posted on a board and everyone dot votes on the top five or so issues. Groups of people with a common interest can then collaborate. This creates a wonderful opportunity for greater social cohesion because people can collaborate with others who share a common interest rather than just their familiars.

Unfortunately, or fortunately, depending on your point of view, corporate IT is conservative While there are numerous cloud-based shared document tools, access to these tools are blocked through the corporate firewall due to security concerns. While this is often annoying, as one IT manager once remarked “we haven’t been in the news, and we don’t intend to be” Conservatism certainly has its virtues, but we needed the equivalent of an electronic flipchart. Fortunately, the organization used Microsoft OneNote which worked quite admirably for us.

Instead of writing issues on post-it notes and sticking the notes onto a flip chart sheet, the Scrum Master worked with their team to capture in Microsoft OneNote the issues the team believed were impeding progress at the “program level”. In our distributed agenda, we gave the Scrum Master three days to gather candidate issues and get them into a OneNote team page. After the issues were captured by the teams in OneNote, the three authors of this paper consolidated the issues and created a list of 20 program level issues. In retrospect it may have been more appropriate to have the teams themselves perform an affinity mapping exercise to consolidate the team issues. However, in our opinion at this time, this would have been a significant coordination effort with very little gain.

For the dot voting, we used PollEv.com and asked people vote on their top issues over a 2-day period. PollEv.com enables people to respond to online questionnaires using either their mobile device or desktop computer. We ran a quick spike to test PollEv.com to create familiarity with the tool by asking people to vote for their favourite science fiction movie. The poll response was at best disappointing, only 20 people responded to the poll or about 5% of the train. While we were disappointed by the lack of interest, we were also thankful that nearly 400 people were not eagerly waiting to collectively jump into the workshop.

Despite the low polling response, this problem identification step was an important step for us because the problems raised were the problems the teams were experiencing and not necessarily the problems program management at the mothership thought were relevant. Without this step, we would have had a very limited view of the problems the widely-distributed teams were experiencing.

The top 5 problems identified were:

The benefit of this step was these issues caught head office – the mothership – a bit by surprise. For example, head office had good visibility into team ownership of features and therefore assumed that of course the teams must also have good visibility. By giving voice to all members of the train, we were able to draw attention to a real problem that was not on the management radar.

5.3 Steps 2 to 5: The Workshops

In the textbook version of the problem-solving workshop, after agreeing on the problem to solve, the group immediately rolls into the root cause analysis. That is the benefit of co-location and face to face communication: rapid decision-making action. Distribution across time zones, unfortunately, extends decision making time because of the coordination delays. It took us 3 days to get set up for the root cause analysis. The first day was spent setting up and verifying access to our pages in OneNote. The second day was spent scheduling the workshops. The third day was used to conduct the training to prepare the participants for the workshop.

Scheduling the workshop was at best a compromise between having the whole team present and respect for people. A consequence of having a program on which the Sun never sets is if we wanted to create the opportunity for everyone to simultaneously participate on the issue of their choice, then someone was losing sleep. This is not showing respect for people. The best compromise we came up with, was to schedule three, two-hour workshops throughout one day: one at noon central time (GMT-6), one at 6 pm central, and the final one at 10 pm central. While we had started with 5 issues, we reduced our list to the top three because we did not have enough facilitators to cover 5 workshops.

The intention behind our scheduling was to have at least one workshop scheduled for a time that someone could attend that would be reasonably convenient for them in their time zone. Of course, the topic for the reasonably convenient workshop may not be of interest to the participant. In addition, for someone who had a keen interest in a specific problem that was scheduled at an inconvenient time may have to choose between sleep and collaborating. Not ideal, but at least that would be their choice.

We continued to use Microsoft OneNote as our collaboration tool. In a OneNote document we created three sections, one for each problem and set up the SAFe fishbone diagram for each. OneNote allows multiple individuals to simultaneously create and edit content on the page; very much an electronic flip chart. The workshops were conducted in WebEx and we had two facilitators per workshop. One facilitator was the “driver” actively engaging and facilitating the session, while the other was the “navigator” keeping an eye on the chat window and engaging with individuals through chat.

Participation was voluntary for this first problem-solving session because we only needed to validate whether our agenda and tooling worked. While we were disappointed by the low participation rate of 20-30 per workshop, we were also grateful that we did not have to facilitate an interactive online workshop with 100+ people in it with our initial attempt in combining all the different technologies.

We timeboxed the root cause analysis to 20 minutes. Participants were initially a little hesitant to engage with the fishbone diagram but that is what the facilitators are for: to help participants move out of their comfort zones. Soon, issues began to, almost magically, appear on the shared page. It was fun to watch as participants engaged in the root cause analysis.

After root cause analysis, we moved to the next agenda item – identify the biggest root cause. We identified the biggest root cause by requesting participants “dot vote” on the fishbone diagram and simply place an “X” on what they believed was the biggest root cause. This was in a word, messy. It would certainly have not work well if we had a large group to work with. For future workshops we would have to transcribe the analysis to another OneNote page for the dot voting.

Once we identified the biggest root causes, we moved onto re-writing the problem statement. The SAFe training materials remind people that a problem well-stated is a problem half solved. In one workshop, the original problem “lack of team objectives make it hard to understand what a team does” was re-written as “I don’t know what other teams are doing and therefore I do not know who I depend on and therefore who I need to talk to” As facilitators, we probably overstepped our boundaries: rather than asking “powerful questions” we almost took the wheel ourselves. It is one thing to ask people to post their thoughts on a fishbone diagram. It is quite another to get people to collaboratively write a statement online. Part of our motivation to “grab the wheel” was to get something done within the timebox. This behaviour on our parts is something we will have to be more cautious about in future. We also took note that future participants will be more familiar with the process and will hopefully be less hesitant to participate.

After restating the problem, we moved to the next agenda item and brainstormed solutions. We simply used a blank page in OneNote to let everyone write their solutions, and then we followed up with a dot vote to pick the actions for us to take. These actions were either implemented as new “working agreements” or added to the program backlog:

A day after the workshop we consolidated the contributions and outcomes in the problem-solving workshop page in OneNote and broadcast a summary to all members of the train.

6. LESSONS LEARNED

This experience highlighted the importance of the problem-solving workshop and creating an opportunity for all voices to be heard. This was the sixth PI for these trains and yet this was their first problem solving workshop. The workshop revealed problems that the members of the trains were experiencing but were not on the management radar. Even with the best of intentions, on a very large distributed train, it is all too easy to become disconnected from the needs of the far-flung teams. This problem-solving workshop is a massive opportunity to mitigate this “mothership” syndrome. Our experience demonstrates the value of a globally distributed problem-solving workshop that creates equal opportunity for all voices to be heard.

While we were able to validate our global agenda, the next lesson learned is running a highly distributed workshop is a significant logistical undertaking. Potentially two orders of magnitude more planning than a comparable co-located workshop. The logistics for running the workshop had long been an impediment to scheduling the workshop. For a large distributed train, there will be considerable effort required to prepare and coordinate all teams around the globe. SAFe suggests the workshop only requires two hours. It took us over a week to plan and execute the workshop. One person was almost fully dedicated to this effort. The price of a large distributed team is an order of magnitude increase in both coordination effort and coordination delays. The value in learning what is really impeding work can be priceless.

Some other lessons learned:

Was it worth it? Yes, for if the Sun never sets on your program, then you owe it to everyone in the program to discover what their concerns and issues are and not what the mothership thinks they are.

7. ACKNOWLEDGEMENTS

We would to thank Lise Hvatum our shepherd whose guidance and recommendation was greatly appreciated. Also we wish to express our gratitude to Rebecca Wirfs-Brock for her support and help.

About the Author

Rochelle Tan

As an Agile Evangelist, Rochelle Tan has over 20 years of experience in agile transformation with small to large organizations from various industries in North America and Asia: Oil and Gas, IT, Finance, Insurance, Government, and Publishing. Rochelle is an accomplished Agile Coach, providing Portfolio and Program level transformation to help companies successfully deliver the highest value for their customers. Rochelle graduated at the top of her class with a BS in Computer Science from Ateneo de Davao University(AdDU) in the Philippines. She is also a mother of two and enjoys traveling with her hubby and two active kids.

William Adehlph

If you remember Fortran, PDP-11s, and TTL then you've been in the industry as long as I have. Spent 20 years developing telephone switches, and railway signaling systems. Somewhere in the 1990s I crossed over to the dark side became an engineering manager and then a consultant....old engineers never die, they just become consultants. Humour aside, I became a consultant because I realized late in my career it did not matter how amazing my individual engineers were, if we did not know how to work together then we were completely hooped. I have seen too many groups of brilliant engineers fail simply because they could not work as a team to solve problems. This is when I became intently interested how people work together. By the way, non of this is new, coal miners in the 1930s knew about this long before we got all excited about it.

Experience Report

Steve Adolph

August 2019, Agile2019 Conference

Please Note: You must be logged in as a Member to download this content.

About The Alliance Agile Alliance Brazil Agile Alliance New Zealand Our Initiatives Policies, Reports, & Bylaws Corporate Members Board of Directors Our Team News and Press Logo Files Membership Benefits Our Community Volunteer Signup Write for Us Contact the Alliance

Your Subscriptions

You are not logged in.

Privacy Preference Center

Consent management, privacy overview.

Enterprise Agility Need to respond to change faster? To do more with less? To surpass your competition? Adopting a holistic approach to change and continuous improvement across the organization can achieve all that and more Learn more >

Global Talent Elevate your pool of talent to beat the global tech talent shortage and remain competitive in the marketplace with end-to-end solutions for enhancing your tech teams Learn more >

Development Support lean, cost-effective workflows focused on delivering value to your customer by leveraging individual specialists or entire teams of experienced software engineers to build custom applications and integrations Learn more >

Business Technology Establish the optimal tool stacks to streamline workflows, data capture, and transparency across the organization, supporting decision making and agility Learn more>

Training Move your teams or your own career forward with the right training solutions. From new ways of working to deeply technical tools-based topics, you can leverage 30 years of experience to obtain the certifications, accreditations, and enhanced learning you and your organization needs Cprime Learning >

Subscribe to our blog for the latest updates on new articles

SAFe® in a Nutshell – The Inspect & Adapt (I&A) Workshop

In our last installment , we explored the activities involved in the execution of a Program Increment (PI). Now, let’s take a look at what happens in a SAFe Inspect & Adapt (I&A) Workshop and how it influences the next PI planning session.

What is the SAFe Inspect & Adapt Workshop?

The importance of the Inspect & Adapt ceremony in SAFe™ cannot be understated. It enables every Agile Release Train (ART) to embody “relentless improvement” as referenced in the SAFe House of Lean, maintain its overall health and deliver ever-increasing business value.

The Inspect & Adapt Workshop is essentially the release train equivalent of the team’s Sprint Review and Sprint Retrospective. Both ceremonies at the team level are encapsulated into the single Inspect & Adapt workshop for the ART.

The I&A, which occurs at the end of each PI during the Innovation and Planning (IP) Sprint, is a key event for teams to highlight what was accomplished and receive feedback that will help inform the next PI.

The entire train is present at this Inspect & Adapt Workshop, including the Business Owner(s), other key stakeholders, and potentially even customer representatives.

What are the Three Parts of a SAFe I&A?

Pi system demo.

The PI System Demo is the final installment and is focused on demonstrating what was accomplished in the entire PI. Since we’re in the IP sprint (and this is not considered a development sprint because we’re no longer planning stories) this is the final version of the System Demo (which we learned in PI execution occurs each sprint in the PI after the first to illustrate increment integration of the team’s sprint output) where the team will show all the end-to-end functionality that was achieved throughout the PI. Team representatives may conduct the demo, or the product management team themselves can take ownership.

An objective-focused PI demo is most effective; this demo should illustrate the business value delivered by focusing on those objectives, and tell the story of how those objectives are now implemented within the system.

Overall, the PI System Demo should:

Quantitative and Qualitative Metrics

This second part of the I&A is a review of metrics on what was accomplished.

(Fig. 1 – Team PI Objectives )

(Fig. 2 – Team PI Performance Reports and Program Predictability Measure )

The goal here is to show a trend of key metrics to serve as discussion points for what might be driving a positive or negative trend to the metric.

Problem Solving Workshop

Essentially, this is the equivalent of the team-level retrospective. Now that the teams have received feedback and everyone can see what was delivered in the current PI, it’s important to relentlessly improve as a train and discuss challenges and impediments. During this Problem Solving Workshop, we aim to understand how we can systematically improve and mitigate those impediments better going forward.

Download this webinar to learn more about how to break through the barrier of virtual impediments and successfully run a virtual Problem Solving Workshop.

The problem solving workshop should focus on large issues that have affected multiple teams, for example:

The workshop starts with the RTE presenting candidate problems for the teams to discuss. This could have been collected throughout the PI during the Scrum of Scrums as the teams were highlighting impediments that continued to be an impact. Alternatively, the RTE could also facilitate a quick brainstorm at the start of the event to elicit other nominations and then do a quick dot vote to see which ones bubble to the top.

Afterward, once the RTE has identified a small number of candidate problems to discuss, the teams on the ART should self-organize into teams around the problems to discuss. These teams generally do not align to the actual teams on the train (and it’s better if they do not). Ultimately, people should self-select which problem they want to be part of based on their context with that problem and where they might best contribute. You should still strive to have scrum-sized teams for each problem. Also, you might have to form multiple teams to discuss the same problem as needed. This way, you’ll get multiple perspectives on potential root causes and actions that could be taken to address.

Once the teams have been formed around the various problems, we head into a six step process:

Teams will use a fishbone diagram, otherwise known as an Ishikawa diagram, and use the 5 Whys technique to reflect on why each problem occurred

Identify the most significant root cause

Team members will use a Pareto Analysis to try to find 20% of the root causes that caused 80% of the problem. Team members dot vote on all the root causes that came up to identify the most significant root cause.

Restate that original problem statement in terms of the root cause

The problem is no longer the original problem statement. Rather, it’s the root cause that actually led to the problem.

Brainstorm potential solutions

Team members will brainstorm potential solutions to the restated problem in step 4 to fix the problem moving forward..

Prioritize, dot vote, and create backlog items to track solutions and improvements moving forward

(Fig. 3 – Steps in the Problem Solving Workshop )

What Happens Next?

As we head into PI Planning for the next PI, with our business value score, an overview on metrics, and identified improvement items at our disposal, the teams can incorporate the feedback from this I&A into the next PI, both in terms of the functionality of the system, as well as those improvement areas that we can proactively plan.

Now, with the completion of the I&A Workshop, that concludes the part of our series involving the planning, executing, and relentless improving of an Agile Release Train. In our next installment, we’ll discuss the Large Solution Level of SAFe. This is an optional level that is only used by larger systems and organizations that require multiple ARTs collaborating and aligning to build and deploy some of the most complex systems in the world. All you “rocket scientists” out there might want to tune in for this one!

SAFe® Solutions

Ken France, VP, Scaled Agility

You may also be interested in:, how do safe and lean work together.

SAFe® (Scaled Agile Framework®) is built on the foundation of Lean principles, which originated from manufacturing. “Lean” espouses optimization of…

The Pragmatic Agile Coach’s Guide to Managing SAFe Features

As customers scale from their loose confederation of Scrum teams to the formality of the Scaled Agile Framework©, features often…

SAFe DevOps: 5 Tips for Success

While some may disagree with this, I believe that SAFe® (Scaled Agile Framework) is a highly complex model that requires…

Workshop Problem Solving with Agile Thinking and Practices

Learn how to deal effectively and faster with impediments and improve your problem-solving skills in the workshop Problems-Solving with Agile Thinking and Practices.

Impediments can be something in the way of working, be it processes, tools, or organizational rules or structures. They slow down teams or block the delivery of products or services. Agile can help to identify problems, it tends to bring problems to the surface and provides solutions for addressing them.

Problem-Solving with Agile Thinking and Practices

Teams will face problems in their daily work. Agile calls these problems impediments. Teams need to be able to deal with impediments as they have an impact on the flow of work, they are problems that reduce outputs and results.

In the workshop Problems Solving with Agile Thinking and Practices, you will learn how to recognize, analyze, and solve problems effectively and faster using agile thinking and practices.

You will practice:

Handling impediments is a key value for all teams and organizations to increase their agility. Regardless of the methods or frameworks used or how it’s called, problem-solving is an essential skill for all employees.

This workshop is intended for:

The practices in this workshop will help you to get problems out of the way quickly and effectively.

What will you get out of this workshop:

Practical information

This workshop can be tailored to the specific situation and needs of your organization. Contact me !

Duration: 1 day.

Testimonials

This what people say after playing one of my Impediment games or reading my book Problem? What Problem? Dealing Effectively with Impediments using Agile Thinking and Practices :

I have attended Ben’s workshop about Impediments at Agile Middle East 2019 in Dubai. Ben has an amazing style of explaining and convincing the people through his workshop’s board game. The Impediment board Game is a great source of realizing for self organizing teams that actual way of dealing with impediment is to face it as a team. The team learns how to deal with their work related impediments and avoids waiting for someone outside the team to resolve for them, which actually is never going to happen. Wajih Aslam, Scrum Master, Agile Leader, Agile Coach Ben Linders steps into the gap between finding a problem and living happily ever after with his new book, Problem? What Problem? This book directly addresses problem-solving at a level that agile teams can use, right now! Thomas Cagley, Transformation Coach This book is a very useful resource for figuring out how to navigate [impediments and problems]. Ben has collected a wide range of experience-based advice that you will find helpful. Scott Duncan, Lead Coach & Trainer at Agile Software Qualities Ben Linders provides a go-to resource in Problem? What Problem? that is full of practical advice for individuals, teams and organisations seeking strategies to deal with their problems. David Spinks, Agile Adventurer, PST, AKT

This is what people say who attend my workshops:

Upcoming public events

Past events, problem solving with agile thinking and practices – full-day tutorial at agile testing days 2022, workshop problem solving with agile thinking and practices – live online, workshop problem solving with agile thinking and practices – live online, devopscon munich 2019, agile management congress 2019, workshops by ben linders.

Doing it yourself and reflecting, that is the way people learn new practices and develop skills in my workshops. They work in teams to try out things and experiment with practices to learn how agile can really look and feel.

I coach people, answer questions, share my experience, and provide lots of ideas. They learn from me, and also from each other

More information

If you want to know more about this workshop or any other workshops or training sessions, feel free to contact me.

How to run a problem-solving workshop

Apr 30, 2020

Posted by: Charles Burdett

What is a problem-solving workshop?

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

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:

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.

Get the right people in the room (and no one else!)

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!

The piston might have broken, but what caused the piston to break?

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:

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 .

Kick the tyres of your idea to make sure it's robust

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:

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 .

Level up your career with Pip Club

Join 42,576 leaders who get unique advice every week on storytelling, leadership and productivity - plus exclusive how-to guides, first-dibs on upcoming Pip Decks and our very best discounts.

Nearly there...

Check your inbox to confirm your email.

No spam, no email sharing - ever. Privacy Policy

One of the few newsletters I look forward to. — Dave Cunningham, Head of DesignOps @ NHS

You might find these articles useful

Live session: Mindworms

How to check in/check out during meetings

Mind Map masterclass

Why is the problem-solving workshop more effective than traditional lessons-learned documents?

Please enable JavaScript

More About PO PM Certification

PO PM Certification is given by PO and PM and with PO PM Certification you can demonstrate your mastery of Agile Methodology. The PO Certified users will have professionally capable of working in Agile environment. One of the question asked in certification Exam is, Why is the problem-solving workshop more effective than traditional lessons-learned documents? You have to complete all course videos, modules, and assessments and receive a minimum score of 80% on each assessment to receive credit. PO PM Certification will make you expert in PO, through which you can converts into leads and new customers and gain benefit in your business or career .

Answer of Why is the problem-solving workshop more effective than traditional lessons-learned documents?

Perché il problem-solving laboratorio più efficace rispetto ai documenti tradizionali esperienze acquisite? لماذا هو حل المشاكل ورشة عمل أكثر فعالية من الوثائق الدروس المستفادة التقليدية؟ Pourquoi l’atelier de résolution des problèmes plus efficaces que les documents de leçons apprises traditionnels? なぜ問題解決ワークショップでは、伝統的な教訓の文書よりも有効なのでしょうか？ ¿Por qué la resolución de problemas taller más eficaz que los documentos tradicionales lecciones aprendidas? Warum ist die Problemlösungs Werkstatt effektiver als herkömmliche Unterricht gelernt Dokumente? Почему решение проблем семинар более эффективным, чем традиционные уроки-уроки документов? 为什么解决问题的车间比传统的经验教训的文件更有效？ Porque é que a resolução de problemas oficina mais eficaz do que os documentos tradicionais lições aprendidas?

0 Comment on this Article

Add a comment. ## do not spam, your comment will not get approved if it has any promotion link or url ## cancel, search service centre here, create an event.

ONLY UNTIL MARCH 23: ✓ Save up to £340 ✓ Access to devmio ✓ Team discount

Nur bis 30. März: ✓ Bis zu 613 € sparen ✓ JBL Wave gratis ✓ entwickler.de Fullstack-Zugang

UNTIL MARCH 30: ✓ Save up to 613€ ✓ JBL Wave for free ✓ Access to devmio

ONLY UNTIL JUNE 15: ✓ SAVE UP TO $1002 ✓ WORKSHOP DAY FOR FREE ✓ TEAM DISCOUNT

Social Media

Join our community!

Be inspired!

Attend inspiring sessions and in-depth workshops to learn how you can push your DevOps skills to the next level.

Become a Sponsor!

Get DevOpsCon news and updates!

IMAGES

Inspect and Adapt
Problem-solving workshop: Step-by-Step
Workshop Problem Solving with Agile Thinking and Practices
Creative Problem Solving Workshop
Step by step guide for SAFe problem solving workshop
Workshop Problem Solving with Agile Thinking and Practices at Agile Testing Days 2020

VIDEO

Top 12 Agile Processes, Techniques and Practices: You Should Know (1 of 12)
Important Terms in Agile- 29th April
PROBLEM SOLVING & IDEATION WORKSHOP
Fields-China Joint Industrial Problem Solving Workshop in Finance 2017
when you should speak as an Agile coach during solving problem
Problem Solving Workshop #1

COMMENTS

Inspect and Adapt
Problem-Solving Workshop · Agree on the Problem(s) to Solve · Perform Root Cause Analysis · Identify the Biggest Root Cause · Restate the New
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 Sun Never Sets on the Problem-Solving Workshop
The SAFe problem-solving workshop is part of the SAFe Inspect and Adapt event. General guidance for the problem-solving workshop is that it is about a two-hour
SAFe Problem-Solving Workshop
The SAFE© Problem-Solving Workshop is an event from Scaled Agile. Framework© that occurs within the Inspect and Adapt (I&A) event, which.
SAFe in a Nutshell
Problem Solving Workshop · Define a well-formed problem statement · Perform a Root Cause Analysis · Identify the most significant root cause · Restate that original
Workshop Problem Solving with Agile Thinking and Practices
Problem-Solving with Agile Thinking and Practices · Recognizing signals of problems, and creating safety in teams (and beyond) for people to bring up problems
How to run a problem-solving workshop
A problem-solving workshop is a rapid session that helps you understand the root cause of a problem, quickly generate and evaluate ideas to
Why is the problem-solving workshop more effective than traditional
Answers of Question Why is the problem-solving workshop more effective than traditional lessons-learned documents? is It makes improvements actionable through
Agile Workshop: Problem Solving With The Right Mindset and Good
In this workshop, you will learn how to deal effectively and faster with impediments and improve your problem-solving skills.
How can a Scrum Master Support a Problem-Solving Workshop?
In many ways, the Scrum master takes a facilitator role in problem-solving workshops. They encourage and moderate discussions. They help the team find routes to