scaled agile six steps in the problem solving workshop

• Skip to content

Problem-solving workshop: Step-by-Step

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

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

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

Problem-solving workshop consists of 6 steps

Step 1: agree on the problem to solve.

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

Step 2: Apply root-cause analysis and 5 whys

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

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

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

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

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

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

Step 5: Brainstorm solutions

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

Step 6: Identify improvement backlog items (NRFs)

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

You may also like

Mastering SAFe: What Every Business Professional Should Know

Anti-Patterns in SAFe Implementation

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

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

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

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

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

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

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

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

What is Inspect and Adapt in SAFe?

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

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

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

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

How does this Work?

Inspect & Adapt consists of 3 parts

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

The PI System Demo

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

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

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

Quantitative & Qualitative Measurements

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

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

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

Retrospective 

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

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

Problem-Solving Workshop

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

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

• Agree on the problem to solve

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

• Apply root-cause analysis

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

• Identify the biggest root cause

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

• Restate the new problem

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

• Brainstorm solutions

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

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

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

Why is Inspect &Adapt an Important Event?

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

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

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

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

You May Also Like

Does SAFe Focus On Predictability Over Empiricism?

Understanding Business Agility Metrics – Outcomes, Flow, and Competency

Top 20 SAFe Interview Questions with Answers

How to become a SAFe Agilist?

Understanding the Role of Features in Agile Release Trains (ARTs)

Building and Maintaining a Continuous Delivery Pipeline in SAFe

Components of an Effective I&A Event

4 SAFe Core Values: Fundamental Pillars of SAFe’s Success

The Importance of Solution Vision for Organizational Alignment

Drop Your Query

Lean Agile Guru

Lean Agile Ideas Worth Spreading For The SAFe Enterprise

• SAFe 6.0 Is Like … 2nd Edition
• Coach’s Handbook Released!
• Merchandise
• SAFe Classes
• Meet The Guru
• Testimonials
• Free Members Only
• Platinum Members Only
• Elite Circle Members Only
• Login/Logout
• Your Partner
• Take Action

Drive Relentless Improvement via ‘Inspect and Adapt’

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

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

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

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

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

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

Share this:

By Clarence Galapon

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

Related Posts

Start With The End In Mind

The Snowball Effect

When is Inspect and Adapt?

Remember me

Forgot Password?

Discover more from Lean Agile Guru

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

Type your email…

Continue reading

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

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

Emma Ropski

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

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

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

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

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

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

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

You don’t need to use an Ishikawa diagram!

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

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

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

Problems don’t actually get solved in the workshop

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

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

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

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

Some people can’t participate

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

         • dominating the conversation and others not feeling safe to share

         • Groups getting off topic due to confusion or boredom

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

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

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

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

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

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

Retrospective

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

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

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

Related Posts

The power of developer feedback.

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

Why Quarterly Retrospectives Guarantee Nothing Ever Changes in Agile Release Trains

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

John Samuelson

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

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

Act On Feedback Faster

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

ScatterSpoke helps you eliminate waste in your dev process.

© XXXX ScatterSpoke. All Rights Reserved.

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

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

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

Six SAFe Practices for S-Sized Teams

by Juha-Markus Aalto, Director Product Development, Qentinel Group

SAFe has been designed to tackle the challenges of ‘M to XXL (medium to extra, extra large)-sized’ programs. Such programs consist of several Agile teams with approximately 50 – 100 people, or even up to hundreds or thousands of practitioners.

Are Scrum and Kanban Enough?

But what about ‘S (small)-sized’ development organizations with just one or a few teams. Is there anything in SAFe for them? Or are Scrum and Kanban just enough?  The answer, of course, is it depends. Please read on to find out what those things are.

If a pure software team mainly works on short programs, Scrum or Kanban would seem to be the way to go. However, while a full-scale use of SAFe practices, roles, and events wouldn’t make sense for an S-sized project, a small team can certainly benefit from selected SAFe practices, at least under one of the following situations:

• A strategic software product with a long lifespan – The longer the lifespan of the software product, the more important it is to link software development explicitly to the strategy of the enterprise. Scrum provides little support for linking such development to the longer-than-sprint time span of strategic goals.
• Dependencies with multiple non-software development teams – It’s common for a company that has a relatively small software team to develop solutions for other teams for integration. For example, software teams face this situation in a hardware or services company which has a decent portfolio of products but has just a moderate amount of software assets. Software companies whose product is heavily tailored for each customer, through delivery, have this multi-project challenge, too; all the dependent teams need to sync and agree on priorities and plans.
• The necessity to invest in long-term capabilities like DevOps – Intense focus on delivering the next set of user stories, sprint by sprint, may result in great products, but it’s all too easy to forget about investments in the team’s capabilities. We can all probably agree that investing in DevOps capabilities is worthwhile to achieve higher quality and faster time-to-market. However, becoming a true DevOps team doesn’t happen overnight. It requires planning and executing, as you would do for any project. Changing the development technologies or modernizing the software architecture are other examples of long-term capability investments that are, in fact, true projects.
• Expectation to scale from S to M size – If a startup (a new business or internal business unit) has a strong projection for growth, it makes sense to prepare for it up-front and use Agile approaches that scale when needed. But, unless the foundational capabilities have been built from the ground up, scaling can be painfully slow, difficult, and challenging.

Applying Six SAFe Practices for S-Sized Teams

There are ways to handle these four cases with pure Scrum or Kanban, but experience suggests that it’s better to apply the following six practices of SAFe to deal with them more effectively.

Strategic Themes

Companies big and small need a strategy to be successful. It’s crucial to understand how a company’s products create value—how they affect processes and the concrete benefits that customers gain. Product quality and user experience are equally important for long-term success. In additi­on to product strategy, a software development team needs to have an idea of how to continuously improve its engineering capabilities to increase productivity and competitiveness.

While SAFe does not offer explicit tools to identify and build the strategy, it does have  Strategic Themes —these are the business objectives that connect the team’s portfolio to the strategy of the enterprise.

I’ve successfully used strategic themes during sprint (Iteration) planning to help ensure that the team works on strategically relevant items. Some tools, such as Visual Studio Team Services (VSTS), allow the tagging of work items with theme keywords, which further helps analyze backlog items against the strategy. If a strategy exists, the extra step to identify the strategic themes requires minimal effort.

Program Epics

Scrum teams typically interpret epics just as really big user stories that don’t fit in one sprint. SAFe defines epics as “initiatives significant enough to require analysis, using a lightweight business case and financial approval before implementation.” The requirement to prepare a business case is not the point here. Rather, it’s to ensure that an epic is something that creates significant value and is feasible.

SAFe contains a rich hierarchy of epics to ensure sufficient scaling:  Portfolio Epics, Large Solution Epics, and Program Epics . Portfolio and large solution epics are not relevant for small-scale development, but program epics are. Moreover, when a team works on a program epic linked to a strategic theme, the team’s efforts contribute to something valuable and are aligned with the strategy of the company.

Epics are useful for an S-sized team. They describe the ongoing key initiatives, those proposed by its stakeholders, or those invented by the team itself. Software teams should also have some enabler epics in their backlog, in addition to business epics, to improve architecture or DevOps capabilities.

As ‘significant-enough’ initiatives tend to require significant investments of people, a lightweight business case is recommended for each epic before determining its approval for implementation or rejection. This process is particularly useful when the team has several stakeholders, and each initiative’s priority and capacity needs to be understood to make trade-off discussions meaningful.

Program Kanban

SAFe uses Kanban systems to manage initiatives at the portfolio, value stream, and program levels. The program level is sufficient for an S-sized team, and it’s particularly useful if the team has several stakeholders offering their epic proposals for implementation.

SAFe Program Kanban  provides a simple and transparent process for capturing, analyzing, approving, and tracking epics. Completed epics will have passed through the following states: funnel, review, analysis, backlog, implementing, and finally, done. For an S-sized team, the process to study epics can be extremely lightweight. But these logical steps should be present anyway, so the Product Owner will know that the team can create the most value for the next time. Managing the key initiatives, like epics, in the program Kanban requires only moderate effort but offers transparency to the team’s priorities at the program and portfolio levels.

A  Feature  is not really a part of the core definition of Scrum; there are just product backlog items. Many Scrum teams borrow ‘user stories’ from Extreme Programming (XP) and label big stories as ‘epics’ and bunch related stories together as themes.

SAFe defines a feature as “a service provided by the system that addresses one or more user needs.” Features elaborate epics and are defined by their benefits and acceptance criteria. Features are exactly what they sound like—the main functional characteristics of the proposed product. It can be difficult to explain the team’s plan and progress to customers, dependent projects, or to management through user stories alone. But features, as defined in SAFe, serve that purpose well. Their size is suitable and understandable, versus user stories, which tend to become too small and numerous.

What makes features particularly useful is that they’re sized to fit in one Program Increment (PI). That makes them concrete deliverables, facilitating clear communication with stakeholders.

PI Planning

Traditional Scrum teams work in a sprint cycle, which is where the planning and execution of work occurs, with two weeks being the most popular duration. More often than not, Scrum teams provide true visibility into their plan for just the next sprint, along with the backlog, which hints at the order in which the user stories might be implemented. Different variations of PowerPoint and Excel roadmaps are typically used to address the need for longer-than-the-next-sprint visibility. Backlog tools can help plan stories for future sprints, and some provide forecasts based on the team’s velocity and the order of the backlog items.

A program increment in SAFe is “a cadence-based interval for building and validating a full system increment, demonstrating value, and getting fast feedback.”  The duration of a PI is typically 8 – 12 weeks or four to six sprints of two weeks. The last sprint of the PI is the Innovation and Planning (IP) Iteration, which will be discussed in the next section.

Just as there is sprint planning in Scrum, SAFe provides a planning practice for these super-sized iterations, known as  PI Planning . I have facilitated SAFe PI planning, more or less by the book, for S-sized teams. The planning horizon of 8 – 12 weeks is short enough for useful planning and long enough for a team to achieve something really valuable: a set of potentially releasable features. The PI planning event is a good use of time for all participants. The team gets an update of the bigger picture from the business, which includes the vision and priorities, and develops an Agile plan. The stakeholders can contribute directly to planning. They will also get an overview of all the work that the teams will do during the PI. For an S-sized team, the PI planning event can be condensed into one long day, so that the investment of time is commensurate with the benefits.

Innovation and Planning Iteration

Thomas Edison described his innovative approach as “one percent inspiration and 99 percent perspiration.” In other words, innovations require time and hard work, not just a creative mind. In ‘never-ending’ continuous product development, there’s a risk that a team just executes sprint after sprint without taking a break and becomes exhausted. Sprints tend to be hectic, and for an S-sized team, it’s likely to be harder to find time to work on some more risky, seemingly lower priority, yet innovative ideas.

SAFe doesn’t have any silver-bullet solutions to magically release lots of time for developers to innovate like Edison. But its  IP iteration , at the end of each PI, is something that teams should appreciate. No stories are planned for this sprint. However, it’s an opportunity to do some final system integration and testing activities, such as performance or security testing. It’s also where the program level retrospective, known as the Inspect and Adapt (I&A) is held. During the I&A, the achievements of the PI will be demoed to stakeholders, followed by a retrospective and problem-solving workshop. The IP iteration is also where we plan our next PI. But as the name suggests, the IP iteration is the time for innovation. This is where some teams do a hackathon or work on innovations or improvements in infrastructure, refactor code, or improve the architecture. And last but not least, the team can have a break from the hectic pace of software deliveries. Part of the break can be used for competence development, as an example.

Scrum and Kanban by themselves can be just enough for S-sized teams. However, there are at least four circumstances that I’ve found that using select SAFe practices, along with Scrum or Kanban, is more effective:

• Strategic software product with a long lifespan
• Dependencies with multiple non-software development teams
• Necessity to invest in long-term capabilities like DevOps
• Expectation to scale from S to M size

There are ways to handle these four cases with pure Scrum or Kanban, but experience suggests that it’s better to apply the following six practices of SAFe to deal with them more effectively:

• Strategic themes shortlist the portfolio’s strategic priorities and help the team align with them.
• Program epics define the valuable key initiatives that the team needs to focus on so that they can meaningfully prioritize their backlog.
• The program Kanban shows the priorities and status of epics for the stakeholders.
• Features elaborate epics, thus providing a common language for the team and its stakeholders. And features are sized so that each fits in a single PI.
• PI planning happens on a cadence, building a shared understanding of priorities and goals for the next 8 – 12 weeks (depending on the chosen cadence).
• The innovation and planning iteration held at the end of each PI gives the team a well-deserved break from the urgent and allows it to spend some time on innovating and developing its capabilities.

About the Author

Juha-Markus Aalto  leads product development of digital services at Qentinel. He’s made several contributions to the Lean and scalable requirements model of SAFe and has implemented an XXL-sized Lean-Agile transformation program when he worked at Nokia Corporation.

Last update: 2 October 2018

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.

Members-only Content

• Monthly Member Events
• Event Session Videos
• Experience Reports
• Research Papers
• Share a Community Event
• Submit an Article to the Blog
• Submit a Member Initiative
• Promote a Training Event

Become an Agile Alliance member!

Your membership enables us to offer a wealth of resources, present renowned international events, support global community groups, and so much more! And, while you’re supporting our non-profit mission, you’ll also gain access to a range of valuable member benefits. Learn more

• Join Us Today
• Member Portal
• Membership FAQs
• Terms and Conditions
• Corporate Members

Agile Conferences

• All Agile Alliance Events
• Past Conferences
• Become an Event Sponsor

Virtual Events

• Member Events Calendar
• BYOC Lean Coffee
• Agile Tech Talks
• Member Meet & Greet
• Agile Coaching Network
• Full Events Calendar
• Community Events
• Community Events Calendar
• Agile Training Calendar
• Sponsored Meetup Groups
• Submit a Non-profit Event
• Submit a For-profit Training
• Event Funding Request
• Global Events Calendars

Deliver Better Results: How to Level up Your Value Delivery

• Events Calendar
• BYOC – Lean Coffee
• Member Meet & Greet
• Agile Training
• View All Events
• Submit an Event
• Meetup Groups
• Past Conferences & Events

Agile Essentials is designed to bring you up to speed on the basic concepts and principles of Agile with articles, videos, glossary terms, and more.

Agile Essentials

Download the Agile Manifesto

To download a free PDF copy of the Agile Manifesto and 12 Principles of Agile, simply sign-up for our newsletter. Agile Alliance members can download it for free.

• Agile Essentials Overview
• Agile Manifesto
• 12 Principles Behind the Manifesto
• A Short History of Agile
• Subway Map to Agile Practices
• Agile Glossary
• Introductory Videos

Recent Blog Posts

Research shows DevOps plays a vital role in workplace efficiency

Agile’s true potential: A call for unity and collaboration

Highlights from Agile2024 & The European Experience

View all blog posts

Agile Resources

The new agile resource guide.

Find Agile services and products from our member companies in our new Agile Resource Guide . Many listings in the guide feature exclusive offers just for Agile Alliance members. View the guide 

• Remote Working Guide
• Event Sessions
• Content Library

Sustainability Manifesto

The  Agile Sustainability Initiative has created the Agile Sustainability Manifesto in an effort to grow awareness about sustainability within the Agile community and inspire a more sustainable way of working. Read and sign now

MEMBER INITIATIVES

• Agile Sustainability Initiative
• Principle 12 Initiative
• Agile in Color Initiative
• Agile Coach Camp Worldwide
• Agile Coaching Ethics

View all initiatives

Your Community

Global development.

• LATAM Community
• India Community

Global Affiliates

• Community Groups
• Community Services
• Member Initiatives
• LATAM Community Development
• India Community Development
• Volunteer Signup

OUR POLICIES

Become a sponsor.

Being an Agile Alliance sponsor is a great way to introduce your company to our members to build awareness around your products and services. The Call for Agile2024 Sponsorships is now open, and there are great options and opportunities still available! Learn more >

• About Agile Alliance
• Code of Conduct
• Board of Directors
• Agile Alliance Brazil
• Agile Alliance New Zealand
• Policies, Reports & Bylaws
• Logo and Media Files
• Become a Sponsor

Experience Report

The sun never sets on the problem-solving workshop, about this publication, agile alliance members-only content.

To read the full content, and gain access to many more valuable resources, conference discounts, and invitations to exclusive networking and learning events, please consider becoming an Agile Alliance member .

If you’re already a member, please log in now. 

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

• Rochelle Tan
• Steve Adolph
• Report Source
• Download Report

You must be an Agile Alliance member to download the report. Please log in to your account now, or join us to take advantage of all our members-only events and resources.

Have a comment? Join the conversation

Related agile experience reports, connecting the dots of knowledge in agile software development, keeping schedule while negotiating content on a scale, navigating performance testing in a semi-agile landscape: an experience report on air travel information system, agile in the wild: sustainability by adopting xp values in wildlife conservation, discover the many benefits of membership, thank you to our valued agile alliance annual partners.

Our new Annual Partner Program offers a new and exciting level of engagement beyond event sponsorship.

Our Cornerstone Corporate Supporting Members

Our Corporate Supporting Members are vital to the mission of Agile Alliance.  Click here to view all corporate members.

©2024 Agile Alliance  |  All Rights Reserved  |  Privacy Policy

©2024 Agile Alliance All Rights Reserved  |  Privacy Policy

Privacy Preference Center

Consent management.

• Welcome back!

Not yet a member? Sign up now

• Renew Membership
• Agile Alliance Events
• Agile en Español
• Agile en Chile
• Resources Overview
• Agile Books
• Content Library by Category
• Content Standards
• Privacy Policy
• Cookie Policy

Help support our mission!

Agile Alliance is a global non-profit membership organization founded on the Agile Manifesto and the 12 Principles behind the Manifesto. If you’d like to make a contribution to help us in our mission and to continue our work, you can make a donation today .

Privacy Overview

Cookie	Duration	Description
_fbp	3 months	This cookie is set by Facebook to deliver advertisement when they are on Facebook or a digital platform powered by Facebook advertising after visiting this website.
AnalyticsSyncHistory	1 month	Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
bscookie	2 years	This cookie is a browser ID cookie set by Linked share Buttons and ad tags.
euds	session	These cookies are from Rocket Fuel (rfihub.com) and are used to deliver targeted advertising across their network sites ensuring users see relevant advertising.
fr	3 months	The cookie is set by Facebook to show relevant advertisments to the users and measure and improve the advertisements. The cookie also tracks the behavior of the user across the web on sites that have Facebook pixel or Facebook social plugin.
IDE	1 year 24 days	Used by Google DoubleClick and stores information about how the user uses the website and any other advertisement before visiting the website. This is used to present users with ads that are relevant to them according to the user profile.
loc	1 year 1 month	This cookie is set by Addthis. This is a geolocation cookie to understand where the users sharing the information are located.
NID	6 months	This cookie is used to a profile based on user's interest and display personalized ads to the users.
pxrc	2 months	The purpose of the cookie is to identify a visitor to serve relevant advertisement.
rlas3	1 year	The cookie is set by rlcdn.com. The cookie is used to serve relevant ads to the visitor as well as limit the time the visitor sees an and also measure the effectiveness of the campaign.
rud	1 year 24 days	The domain of this cookie is owned by Rocketfuel. The main purpose of this cookie is advertising. This cookie is used to identify an user by an alphanumeric ID. It register the user data like IP, location, visited website, ads clicked etc with this it optimize the ads display based on user behaviour.
ruds	session	The domain of this cookie is owned by Rocketfuel. This cookie is a session cookie version of the 'rud' cookie. It contain the user ID information. It is used to deliver targeted advertising across the networks.
sd-session-id	1 year 24 days	Registers data on visitors from multiple visits and on multiple websites. This information is used to measure the efficiency of advertisement on websites. Cookie Duration Description CP5XKN6QLDFWUC This cookie is provided by the Calculated Fields form. This cookie is used by the online calculators on the website. Without the Calculated Fields cookie the instant quotation may not work. 319 COMMENTS Inspect and Adapt 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. For an ART, this includes: The Agile teams. Release Train Engineer (RTE) Problem-solving workshop: Step-by-Step 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. Inspect and Adapt 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. Figure 3. Problem-solving workshop format What Is Inspect And Adapt In SAFe ? How Does It Work? In Scaled Agile, Inspect & Adapt is the way to look back and take feedback on product, process, people etc. ... Problem-Solving Workshop. ART comes together and conducts this workshop to identify 1-2 key problems, find root causes and find solutions for the root causes. This is a six-step process. Problem-Solving Workshop Problem-Solving Workshop. The Problem Solving Workshop is an Inspect and Adapt (I&A) event that provides a structured approach to identifying the root cause and actions to address systemic problems. ... Scaled Agile, Inc Contact Us. 5400 Airport Blvd., Suite 300 Boulder, CO 80301 USA. Business Hours. Weekdays: 9am to 5pm Weekends: CLOSED ... Why "program" is still used in one place in SAFe 6.0 However, with regard to the fishbone diagram used in the problem-solving workshop, the 'program' label for one of the 'bones' of the diagram has always referred to the general use of the term program, not SAFe's adapted use of the term to refer to ART practices and the PI. Therefore, the term remains valid for this exercise even in ... PDF Inspect and Adapt Workshop Problem Solving Workshop 2 3 Scaled Agile Advisory Services Three main elements of the Inspect and Adapt workshop In this hands-on workshop, your ART teams will be guided through a rigorous approach to problem-solving that will result in improvement actions for the next PI. PDF SAFe Problem-Solving Workshop 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 is held at the end of each Program Increment (PI). A PI is timebox during which an ART (a team of teams) delivers incremental value in the form of working, tested solution. Drive Relentless Improvement via 'Inspect and Adapt' At the program Level of SAFe, there is a program event called 'Inspect and Adapt (I&A)'. No surprise there. The purpose of which is exactly that, to pursue relentless and continuous improvement. It comes in three parts: 1) the system demo; 2) the quantitative measurement; 3) retrospective and problem solving workshop. Five Things You May Not Know About the SAFe Inspect and ... The Scaled Agile Frame work (SAFe) incorporates methods, events, principles, and roles that agilists are already familiar with from Scrum, Lean, and XP. But SAFe is also novel, with its own unique concepts, roles, and events like the Inspect and Adapt (I&A), a reflective all hands event that happens every quarter featuring a problem solving workshop. Scrum Master Scrum Master. SAFe Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, Extreme Programming (XP), Kanban, and SAFe, ensuring that the agreed Agile process is followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless ... Scaled Agile Scaled Agile online learning platform course catalog Resources & Media Library Explore a collection of self-paced learning modules, videos, podcasts, Framework articles, and other resources to learn about and enhance your practice of SAFe. ... Problem-Solving Workshop (3) Retrospective (1) System Demo (11) Team Events (51) Team Sync (11) SAFe ... Continuous Learning Culture Problem Solving Culture. In Lean, problem-solving is the driver for continuous improvement. It recognizes that a gap exists between the current and desired states, requiring an iterative process to achieve the target state. The steps of problem-solving are both fractal and scalable. Steps to Follow Step 3: Prepare the workshop facilitators. A successful Value Stream and ART identification workshop will have the main facilitator, ideally someone with experience running this workshop. Additionally, you'll need a facilitator, typically an SPC, per every group of six to eight attendees. Prior to the workshop date, schedule several ... Six SAFe Practices for S-Sized Teams Applying Six SAFe Practices for S-Sized Teams. There are ways to handle these four cases with pure Scrum or Kanban, but experience suggests that it's better to apply the following six practices of SAFe to deal with them more effectively. Figure 1. Scaled Agile Framework with six practices for S-sized teams. The Sun Never Sets on the Problem-Solving Workshop Agile Alliance is a global non-profit membership organization founded on the Agile Manifesto and the 12 Principles behind the Manifesto. If you'd like to make a contribution to help us in our mission and to continue our work, you can make a donation today . Iterations Additionally, everyone in the ART collaborates to identify and address systemic problems in the problem-solving workshop portion of the I&A. The following sections describe the ART and Agile Team activities within each iteration in the PI. Agile Release Train Activities. Getting feedback is critical to an ART's high development velocity. SAFe in a Nutshell 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 ... Enterprise Architecture Evolution Specifically, the problem solving workshop? What is the best way to measure the performance of an Agile Release Train and its impact on the organization; Hosted by: Melissa Reeve. Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing ... Six years ago, Mercedes Benz launched one or two ... Implementation In addition, SPCs and coaches can lead the first real corrective action and problem-solving workshop. This workshop gives teams the tools they need to improve their performance independently. It also allows them to work together with their management stakeholders to address the more significant impediments they face collaboratively. Moving Forward DoD uses AI and SAFe In this podcast episode learn how the Department of Defense is using artificial intelligence and SAFe to reduce queue lengths for background checks, and how a government agency is using SAFe and has transformed itself from lagging to a leading organization. We'll also be addressing how to run remote problem-solving workshops, along with how ... Presentations and Videos Presentations and Videos We offer the following Presentations and Videos to help start or enhance your SAFe learning journey. You may also be interested in these additional resources: SAFe Books, Extended SAFe Guidance , and Scaled Agile Resource Library. SAFe in Five Minutes Ideal for people just getting acquainted with the Framework, this 5-minute video provides a high-level overview of SAFe ... assignment essay homework paper phd report resume review thesis