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
- Quantitative and qualitative measurement
- Retrospective and problem-solving workshop
Participants in the I&A should be, wherever possible, all the people involved in building the solution. These include for an ART:
- The Agile teams
- Release Train Engineer (RTE)
- System and Solution Architects/Engineering
- Product Management , Business Owners , and others on the train
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.)
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 .
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.
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.
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:
- Generate as many ideas as possible
- Do not allow criticism or debate
- Let the imagination soar
- Explore and combine ideas
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
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.
- 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
Definition of Done: Why is it so important?
Implementing change in complacency-filled organizations
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).
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:
- Agree on the problem to solve
- Apply root cause analysis (5 Whys)
- Identify the biggest root cause using Pareto analysis
- Restate the problem for the biggest root-cause
- Brainstorm solutions
- Identify improvement backlog items
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:
- Dec 12th by this date the teams are expected to have conducted a “mini retrospective” identifying what each team sees as the program level issues.
- Dec 13th Publish and collate Issues discovered during the mini retrospectives.
- Dec 13th Vote on the published issue list to select the top 5 issues.
- Dec 14th Schedule the problem-solving workshop published and name the facilitators.
- Dec 17th Conduct problem solving sessions
- Dec 19th Present a summary of the workshop
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:
- There is no visibility for which team owns certain features (e.g. monitoring and alerts). This has led to duplication of work.
- Dependencies between teams are not clear during sprints.
- Lack of team objectives and identity make it hard to understand what a team does.
- Compliance activities take a long time.
- How should support be structured for cloud migrations?
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:
- Establish a regular meeting between business owners and their POs where the business owners can make their goals clear to the PO
- Highlight the team’s objectives and benefits during PI Planning
- Scrum Masters add their team objectives to their team descriptions in MS Teams
- Build and maintain a SAFe program board
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:
- Surprise – a large logistically complex workshop will not happen unless leadership drives it.
- People do not mind losing sleep to solve a problem if the problem is of interest to them and it is their choice to participate or not.
- The problem causing the teams the most pain are often not what management thinks are the problems causing the teams the most pain.
- Managing the logistics of a globally distributed workshop are easily an order of magnitude more time consuming and complex than running a local face-to-face workshop.
- Even primitive collaboration tools can help you run a distributed problem-solving workshop(s).
- People require additional training ahead of time to run an effective distributed problem-solving workshop
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.
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.
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.
- 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
- 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 >
- Digital Transformation Get the right work done faster and move efficiently against your strategic roadmap, enabling progress, innovation, and successful delivery of product and services
- Product Agility Build a product management capability internally and deliver the right thing, to the people, at the right time
- Scaled Agility Derive the benefits of agility by strategically scaling across teams, programs, and lines of business
- Lean Portfolio Management Align strategy to execution to maximize value, increase efficiency, and boost customer satisfaction
- DevOps Build quality, speed, and resilience in your deployment pipeline using proven DevOps tools and principles
- Agile for Hardware Increase quality, fit for purpose, and time to market using agile principles in your hardware workflow
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 >
- Staffing Save time, reduce overhead, and fill necessary skilled positions fast or source entire teams for projects of ongoing support
- Training Enhance your teams’ skills and knowledge and build engaged and effective teams
- Certifications Stay on top of the latest industry knowledge and gain valuable accreditation with expert-led certification courses
- MakeDev Reskill Program Teach existing non-technical talent technical skills — fill the tech talent gap from existing resources, fast
- Dojo Immersive Learning Experience Drive quantifiable results for your organization through an immersive learning- through-doing program
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 >
- Application Development You need a new application to deliver greater value to your customer—-our experienced engineers build and support the custom apps you need
- Custom Software Development Build an optimal tech stack where everything works together smoothly and automation saves your teams time and effort
- DevOps Need a better product deployed faster? Experienced DevOps engineers implement automated deployment pipelines to focus on quality
- Cloud Leverage the speed, security, and flexibility of the cloud while saving valuable time and money
- Application Prototyping From ideation to a working prototype, experienced software engineers deliver a proof-of-concept to support your custom development needs
Business Technology Establish the optimal tool stacks to streamline workflows, data capture, and transparency across the organization, supporting decision making and agility Learn more>
- Atlassian Work with a Platinum Solution Partner to get the most out of your Atlassian investment, optimize the tool stack, and scale your experience
- Business Software Software tools are vital to business agility—-create lean modern tech stacks that align to your business goals across your value streams
- Cloud Securely deploy your mission critical applications in the Cloud for scalability, availability, and cost optimization
- DevOps Deliver faster, higher-quality, more reliable software into production and drive business results across the entire CI/CD toolchain
- IT Service Management (ITSM) Serve internal and external customers faster with a streamlined, predictable, and highly effective IT service desk
- Migrations Our comprehensive suite of proprietary tools and scripts allows us to perform migrations and upgrades cleanly and efficiently
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 >
- View All Courses Join 350k+ learners who have benefitted from our unique training experiences
- Certifications Access real-world, hands-on training certification courses from Cprime Learning
- Private Group Training Optimize your investment in learning with curriculum targeted to your unique team environment
- Build Your Own DevOps Course Apply the principles of DevOps to address your specific business and software delivery workflow
- Dojo Immersive Learning Experience Drive quantifiable results for your organization through an immersive learning-through-doing program
- Business Analysis
- Cloud & IT Services
- Data & Analytics
- Product Management
- Project & Program Management
- Software Development
- Software Testing & QA
- Learning Partner Program
- Ways to Learn
- Courseware Licensing
- Guarantee and Policies
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:
- Tell a story that would be meaningful to the business owners and the business stakeholders in the room. Ideally, the teams would have discussed what “story” the business owners would like to see at this demo during the PI planning session so that the teams could be planning for what to show throughout the PI.
- Allow some time for feedback after the demo. Feedback from stakeholders can include:
- Did this meet expectations?
- Did you see anything that you didn’t expect?
- Or, did you get more than you expected?
Quantitative and Qualitative Metrics
This second part of the I&A is a review of metrics on what was accomplished.
- PI Predictability Measure – This is the key metric we look at during this portion of the I&A. This metric measure the planned business value versus the actual business value that the team has accomplished against their objectives.
- Business owners will collaborate with the team to provide a score on the actual business value that was delivered, in comparison to what the team committed to during the PI Planning session. The score should be based on whether the team accomplished their planned objectives- regardless of whether or not that objective still has the same business value in the current market. It should really be a measure of to what extent the team delivered to the business owners expectation of what they said they would. The graphic below illustrates how the PI predictability measure is calculated and shown.
- Note: During PI Planning, the team may have come up with stretch objectives, in addition to their committed objectives. Stretch objectives do not count as part of the plan, so it is possible for a team or the whole train to achieve over 100% of business value delivered, in the case that they met some or all of their stretch objectives in addition to their committed objectives.
(Fig. 1 – Team PI Objectives )
(Fig. 2 – Team PI Performance Reports and Program Predictability Measure )
- Other measures the team may explore include:
- Velocity that the train achieved
- The number of features and number of stories completed
- Defects found, etc.
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:
- Environmental issues that have impacted the teams
- Teams colliding with each other
- New pieces of technology that failed
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:
- Define a well-formed problem statement
- Perform a Root Cause Analysis
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!
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…
- Welcome at Ben Linders
- Getting Value out of Agile Retrospectives
- What Drives Quality
- New! The Agile Self-assessment Game
- New! Problem? What Problem?
- Quotes from Ben Linders
- Updated! Agile Self-assessment Game
- All Recommended Books
- on Leadership
- for Scrum Masters
- for Product Owners
- for Agile Coaches
- for Managers
- for Software Engineers
- for Agile Teams
- for Project Managers
- written by me
- Updated! Agile Self-assessments
- Updated! Retrospective Exercises Toolbox
- Updated Business Benefits of Agile
- Agile/Scrum Certification
- Business Benefits of Reviews
- Root Cause Analysis Tools
- CMMI V1.3 Process Areas
- Services Ben Linders Consulting
- Upcoming workshops
- Workshop Making Agile Work for You
- Workshop Improving Organizational Agility
- New! Workshop Assessing your Agility
- New! Workshop Problem Solving with Agile Thinking and Practices
- Workshop Valuable Agile Retrospectives for Teams
- Workshop Increasing Agility with Retrospectives
- New! Workshop Continuous Improvement in Remote / Distributed Teams
- New! Assessing your Agility
- Upcoming Conferences
- Free Lifetime Support by Ben Linders
- Book: Getting Value out of Agile Retrospectives
- New! Book: What Drives Quality
- New! Book: The Agile Self-assessment Game
- Diensten Ben Linders Advies
- All Workshops by Ben Linders
- Workshop Waardevolle Agile Retrospectives
- Introductietraining Verandermanagement
- Workshop Continu Verbeteren met Agile
- Workshop Software Kwaliteitsverbetering
- Open Inschrijving Workshops
- Advies en Consultancy
- Webshop – Nederlandstalige edities
- Games en Boeken
- Lezingen en presentaties (wereldwijd)
- Boek: Waardevolle Agile Retrospectives
- Partners / Samenwerkingen
- Nieuwsbrief Ben Linders
- Aanbevolen Boeken
- About BenLinders.com
- Contact me!
- Guest/Sponsored Posts
- Subscribe to BenLinders.com
- Conference & Workshop Calendar
- Member Login
- Donations for benlinders.com
- Feedback Benlinders.com
- Agile Games by Ben Linders
- Workshops and Coaching by Ben Linders
- Books on Agile by Ben Linders
- All Products and Services
- Delivery Information / FAQ
- Games and Books in English
- Games en boeken in het Nederlands
- Libros y Juegos de Ben Linders en español
- Jeux et livres en français
- Knihy a hry Bena Linderse v češtině
- Free Lifetime Support
- Membership Information
- Your account
- All editions / shops
- Paperback Edition (Amazon)
- Kindle Edition (Amazon)
- eBook (Leanpub)
- Retrospective Exercises Toolbox
- Ask your Agile Retrospective Question!
- Waardevolle Agile Retrospectives
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:
- Recognizing signals of problems, and creating safety in teams (and beyond) for people to bring up problems
- Analyzing problems, for example by using causal analysis, Cynefin, serious games, blameless post-mortems, retrospectives, swarming, or blocker analysis
- Managing impediments using techniques from Lean & Kanban; decide how to solve them and who should be involved
- Preventing problems using quality techniques like code walkthrough/reviews, pairing, CI/CD
- Using coaching and games to improve collaboration and develop problem-solving skills
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:
- Agile Teams.
- Technical (team) leaders and Scrum masters
- Product Owners and Project/Line Managers
- Stakeholders working with agile teams
- Agile and Lean Coaches
- Anybody who is supporting teams in agile transformations
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:
- Become able to create a blameless culture where signals are spotted more easily and problems are brought up sooner
- Develop your skills for analyzing problems to get a deep understanding and decide to take action
- Learn how to collaboratively deal with impediments in your team and organization and find ways to prevent problems from happening
This workshop can be tailored to the specific situation and needs of your organization. Contact me !
Duration: 1 day.
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
If you want to know more about this workshop or any other workshops or training sessions, feel free to contact me.
Leave a Reply Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed .
Get a free paperback copy of my Agile Retrospectives book, see "Agile Coaching Tools" Dismiss
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:
- 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 .
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.
Check your inbox to confirm your email.
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?
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 .
Other Important Exam Links – Must visit
You should visit our few findings below for success in exam 1. PO PM Certification Official Link 2. Completed PO PM Certification Exam Answers 3. Completed PO Certification Exam Details 3. Other Best Free Certification Exam Details
It involves more participants
It makes improvements actionable through backlog items for the next Program Increment
Workshops are more engaging than document writing
Collaboration over documentation is a key recommendation of the Agile Manifesto
Check All Question and Answers of PO PM Certification Exam Here.
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.
- Hybrid concept
- Business & Company Culture
- Cloud Platforms & Serverless
- Kubernetes Ecosystem
- Continuous Delivery & Automation
- Microservices & Software Architecture
- Observability & Monitoring
- DevOps Transformation Day
- Developer Experience Day
- Full Program
- Power Workshops
- Advisory Board Munich
- The Online Conference
- Archive DevOpsCon
- Hybrid Conference
- DevOps Metrics & Measurement Day
- Advisory Board
- On-site Tickets
- Remote Tickets
- Call For Papers
- Tickets On-site
- Tickets Remote
- Program New York
- Program Singapore
- Program Munich
- Become a Sponsor
- Sponsors & Exhibitors
- Hotel Booking
- Join our Newsletter Community
- Code of Conduct
- Register Now
- Register now
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
Join our community!
Attend inspiring sessions and in-depth workshops to learn how you can push your DevOps skills to the next level.
Become a Sponsor!
© Copyright 2023 S&S Media, All Rights Reserved
Problem-Solving Workshop · Agree on the Problem(s) to Solve · Perform Root Cause Analysis · Identify the Biggest Root Cause · Restate the New
A problem-solving workshop is held by the Agile Release Train and its purpose is to address systematic problems.
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
The SAFE© Problem-Solving Workshop is an event from Scaled Agile. Framework© that occurs within the Inspect and Adapt (I&A) event, which.
Problem Solving Workshop · Define a well-formed problem statement · Perform a Root Cause Analysis · Identify the most significant root cause · Restate that original
Problem-Solving with Agile Thinking and Practices · Recognizing signals of problems, and creating safety in teams (and beyond) for people to bring up problems
A problem-solving workshop is a rapid session that helps you understand the root cause of a problem, quickly generate and evaluate ideas to
Answers of Question Why is the problem-solving workshop more effective than traditional lessons-learned documents? is It makes improvements actionable through
In this workshop, you will learn how to deal effectively and faster with impediments and improve your problem-solving skills.
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