architect's primary responsibility during management review and problem solving

Ask a question

Start a discussion.

• Atlassian logo Jira Product Discovery
• Jira Service Desk Jira Service Management
• Confluence Confluence
• Trello Trello
• Atlassian logo Atlassian Guard

Community resources

• Announcements
• Documentation and support

Atlassian Community Events

• Atlassian University
• groups-icon Welcome Center
• groups-icon Featured Groups
• groups-icon Product Groups
• groups-icon Regional Groups
• groups-icon Industry Groups
• groups-icon Community Groups
• Learning Paths
• Certifications
• Courses by Product
• Live learning
• Local meet ups
• Community led conferences

Get product advice from experts

Join a community group

Advance your career with learning paths

Earn badges and rewards

Connect and share ideas at events

Tips for facilitating a virtual management review and problem solving meeting during pi planning.

Was this helpful?

Sam Tsubota

About this author

Senior Product Manager, Enterprise Agility

Los Angeles, CA

30 accepted answers

144 total posts

• +24 more...
• best-practice
• pi-planning
• scaled-agile
• Community Guidelines
• Privacy policy
• Notice at Collection
• Terms of use
• © 2024 Atlassian

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

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

What is the role of the solution architect in SAFe?

SAFe or Scaled Agile Framework has three (3) architect roles:

Enterprise Architect

Solution architect, system architect.

These three (3) roles capture the entire organizational IT architecture.

• Information architecture
• Security architecture
• Application architecture

And so forth.

Everything you can think of in terms of software, hardware, and operational architecture that supports the creation, capture, and delivery of value to customers. All this architecture maps to one of these three (3) primary architect roles in SAFe.

Quick overview of the Architect Roles

The enterprise architect has a broad, but not necessarily deep, knowledge of all the solutions within the portfolio.

The solution architect is responsible for the solution within the SAFe environment. This encompasses all of the Agile Release Trains that are coordinated and aligned with delivering a specific solution to a customer or value stream.

So, the solution architect will have a deeper understanding of the solution architecture than the enterprise architecture , but they won’t have the same breadth of knowledge as the enterprise architect.

They understand how all the dots connect across all the Agile Release Trains committed to building or delivering a solution to the customer.

A system architect has deep knowledge about the solution that the Agile Release Train is building.

So, each Agile Release Train builds a specific solution for a specific customer or value stream, and the system architect has deep knowledge and capability of each solution being developed or delivered.

Architect Capabilities

In the SAFe environment , the knowledge and capability of each architect moves from broad and shallow to narrow and deep, as you move through each role. The enterprise architect would have the greatest breadth of knowledge about the environment, whilst the system architect would have the greatest depth of knowledge and capability within the SAFe environment .

Teams of Architects

In some environments, especially for a small organization, a single architect in each capacity would be fine. In larger, more complex organizations, you would have several system architects, solution architects, and enterprise architects.

It isn’t a single person responsible for all of these elements, the volume of work and depth of complexity makes it almost impossible for a single person to manage, so we do have teams of architects within the SAFe environment to make sure we have capacity and capability to deliver continuous, valuable work to customers.

Active, hands-on service to the teams.

None of the architect roles are ivory tower roles.

They don’t sit in a corner office and distribute plans and blueprints for others to observe, they are instead a hands-on, integrated part of the Agile Release Trains and act in service of the customer, the organization, and the teams of agile teams.

They are an integral part of the agile release train, the solution train, and part of the portfolio.

Each of the architects are continually guiding individuals and teams, gaining a deeper understanding of how the architecture and product road-mapping integrate into a solution, and intervene when there is a mismatch between a product vision and an implementation requirement.

They are actively learning and adapting as they gather more evidence and data.

Nothing is cast in stone in a SAFe environment, and just as the teams adapt and respond based on what they are learning, so too do the architects adapt and respond based on what they are learning.

In the design and planning phase of solution architecture, we may think that X is achievable, however, as the work flows through the value stream, we may notice that X is no longer achievable and we either need to adapt, or we need to amend the architecture to facilitate X being achieved.

So, the architects serve the customers, the organization, and the agile release trains in a hands-on, agile manner that aligns with agile values and principles, as well as SAFe values and principles.

About Value Glide

Value Glide are a SAFe ( Scaled Agile Framework ) consultancy, coaching practice, and training specialist who work with organizations to align business objectives with customer needs and wants.

As deeply experienced agile coaches and practitioners, our team are invested in continuous learning through each client engagement and use the data and evidence we gather from each implementation to inform our training, coaching, and consulting services.

In a nutshell, empirical process control or empiricism.

If you are thinking of adopting agile within your organization and have identified SAFe as a great agile framework to adopt, implement and improve your business agility, visit our SAFe Quickstart ART Launch program page or view our SAFe Consulting Services page.

If you have identified a need for an agile coach and SAFe coach to help your organization adopt and implement SAFe, visit our SAFe Coaching Services page.

If you want to know more about SAFe and how to lead SAFe, visit our SAFE Training page for a host of options, from Leading SAFe to a SAFe Release Train Engineer course.

#SAFe #scaledagileframework #scalingagile #agile #agileframework #agilecoach

Connect with Value Glide!

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

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

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

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

You may also like...

What is Kanban?

Working at Toyota Taiichi Ohno developed kanban to create a just-in-time flow and reduce the inventory. The system takes its name from the signal cards

Release Train Engineer vs SAFe Scrum Master

Which course is right for you? The SAFe Release Train Engineer (RTE) and SAFe Scrum Master (SSM) courses are both designed to teach you the

Why is it important for organisations to consider the transition to agile?

Aye Aye, Captain…

How many times you have been drowned by the burden of change?

What are the primary SAFe values and why are they important?

Under what conditions would SAFe be a great solution for an organization?

Latest Blog Posts

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

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

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

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

Why is the Agile HR course relevant?

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

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

Useful Links

Connect with us.

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

©2024. Value Glide. All Rights Reserved.

Website created & supported by FireWerks Marketing + Design

Click one of our contacts below to chat on WhatsApp

Social Chat is free, download and try it now here!

A Program Increment ( PI ) starts with a time-boxed PI Planning  event in which the Agile Release Train is responsible for planning & delivering incremental value in the form of working, tested software and systems. This is a two-day event where all stakeholders (including Agile/Scrum Teams) on the Agile Release Train (ART) participate in a collocated event. All teams have their own areas set up for their planning together with a Program Area with a Program Board to map Feature delivery and dependencies across teams. PI is usually 8 – 12 weeks long. A well-executed PI Planning session ensures alignment, transparency, and collaboration across teams, setting the stage for a successful Program Increment.

Purpose : The purpose of PI Planning is to create an emergent roadmap to deliver a prioritized and agreed set of outcomes as well as identify both known and potential impediments to progress. The goal is to align business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next release (PI) time-box.

• Aligning Teams: Ensuring that all Agile Release Trains (ARTs) understand the priorities, objectives, and dependencies for the upcoming PI.
• Building Plans: Collaboratively creating plans for the PI, including defining objectives, estimating work, and identifying cross-team dependencies.
• Enhancing Collaboration: Fostering communication and collaboration among teams, stakeholders, and product owners to ensure a shared understanding of goals.

Goals: The primary purpose of release (PI) planning is to gain alignment between business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next release (PI) time-box.

Features : Have clear, simple, well-written business-oriented and valuable features rather than Features describing a technical solution.

PI Planning Inputs (Pre-Work)

• Product backlog features are prioritized & ranked.
• Business review of each feature completed
• Technical analysis done, feasibility established, architecture and solution understood,  enabler  features identified.
• Features ranked (for example using WSJF ) – single common stack for the entire program
• Features sufficiently defined to support release planning and estimation.

PI Planning Process Steps

• Mapping: Features elaborated into user stories
• Sizing: Stories estimated (to +/- 20%) via bulk estimation
• Scheduling: Initial allocation of stories to sprints, taking into account team velocities and dependencies.
• Feature delivery dates determined (to nearest sprint)
• Release scope set based on velocity and target release date.
• Consolidated release plan showing feature completion dates.

PI Planning Outputs

• Release scope defined for next time-box
• The team better comprehends the objectives for the whole PI.
• A shared understanding of what it takes to release
• Program risks reviewed and actions identified to solidify the plan
• Release objectives reviewed and scored by business stakeholders
• Team and program confidence vote on the plan
• Collective ownership of the plan

Day 1: Creating Draft Plans

Business Context : This is an update given by upper management or a business on how the business is doing and how well they are keeping up with the market and consumer needs.

Vision : This is the overall business vision and objectives, but also the vision for the upcoming PI. At the beginning of PI Planning, the vision will be presented by Product Management or a senior business sponsor for the Agile Release Train.

Architectural Runway: Understanding the architectural implications of upcoming Features is important to ensure that the teams have an understanding of the underlying architectural approach and system constraints that they have to work within. Systems Architect or IT department will outline the systems and architecture vision for improvements to the infrastructure that will help to improve the time to market and may impact development during the coming PI.

Planning Context & Lunch : The Release Train Engineer (RTE) outlines how the PI planning process will work and what is expected from the teams and the overall meeting.

Team Breakouts : Teams will gather around the boards to estimate their velocity for each iteration and look over their backlogs and what will need to be brought forward to support the features outlined in the vision.

Draft Plan Review : This is a time-boxed meeting where the teams present their draft plans so that business owners, product owners, stakeholders, and other teams can give feedback.

Management Review and Problem-Solving: In most cases, the draft plans will bring up issues with architecture, scope, and people and resource constraints. These issues can sometimes only be solved by management renegotiating scope and possible features.

The program Backlog should be sufficiently refined to support story writing and sizing. Each team will first create draft plans & these plans include 3 basic things: a feature delivery timeline, a set of PI Objectives, and a risk assessment.

Create Stories from Features: Known as Story Mapping – taking a set of features and breaking each one down into small slices of functionality that can be delivered in a single iteration. At this stage, it is not necessary to refine the story to the extent that it will meet the definition of ready. This refinement can be done as part of the backlog refinement process.

• Capture the end-to-end user process flow.  Consider these as functional steps or ‘features’.
• Start defining potential actions the user will take to accomplish each function. These can be considered the ‘user stories’.
• Create the “ MVP ”.
• The classic INVEST (Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable) , DEEP , and 3C’s (Card, Conversation, and Confirmation) techniques apply as much, if not more, to Features than they do to User Stories.

Story Size Estimates: estimation by linear affinity. This method is good for generating initial estimates for large Product Backlogs, e.g. for PI Planning. Stories not necessarily fully defined ( Ready ). Teams place stories in buckets of relative size: XS, S, M, L …, or Fibonacci: 1,2,3,5,8,13 … (Recommended)

• Planning Poker – Agile Estimation Method
• Bucket System – Agile Estimation Method
• Affinity Estimation – Agile Estimation Method
• Dot Voting – Agile Estimation Method
• White Elephant Sizing – Agile Estimation Method

Story & Feature Scheduling : In this step allocate stories to sprints by taking into account story size (in points) and team velocity (points per iteration).

Identify Risks and Dependencies: Dependencies constitute a risk in that they represent items the team has no direct control.

Align Team Deliverables with Program Objectives : It gives teams the opportunity to validate with stakeholders that they have clearly understood the intent and priorities defined for the PI in terms of business value.

• This step is about assigning overall business value to the PI.
• The intent of this exercise is to summarize the PI in terms of meaningful business objectives and to confirm alignment between teams and stakeholders. Features deliver benefits that are aligned with business goals.
• PI objectives should be SMART : Specific, Measurable, Achievable, Realistic, and Time-Bound.
• Business stakeholders circulate and score the team’s objectives, assigning a ‘business value’ between 0-10, where 10 represents the highest business value. Each team starts with their most valuable PI Objective as a ’10’, then all remaining PI Objectives are scored relative to that first 10. BV can be scored as relative within the team, or relative to the overall train.
• At the next PI planning event, following the PI demos, business stakeholders will rate objectives based on what was actually achieved – this data is the basis of the Program Predictability Metric. (Pass out a printed list of PI objectives with original rankings to the stakeholders with an additional column for actuals).

Leadership review & problem-solving: The leadership team will work on the following questions:

• What have we learned so far?
• Where do we need to adjust: Vision, Scope, People?
• Where are the bottlenecks?
• What features must be de-scoped, or deferred?
• Are decisions needed before tomorrow?

Day 2: Make Adjustments and Finalize Plans

The leadership team will announce any required changes to feature priorities and team changes.

The overall agenda for the day will look like this:

• Program adjustments from leadership review – priorities, scope changes, people movements.
• Teams adjust & finalize plans
• Stretch objectives setting
• Teams identify remaining issues needing help from an outside team
• Business stakeholders circulate to review plans and score PI Objectives
• Team-level confidence votes.
• Program wall-board: Feature delivery timelines by the team.
• The team plans collected to the front of the room, risks ROAM’ed , program confidence vote.
• Event retrospective.

Program Adjustments – The day begins with any adjustments or decisions made by management and stakeholders in the problem-solving meeting.

Team Breakouts 2 – Plan Adjustments to incorporate changes in priorities, scope, and people moves into their plans. This will include any scope changes and feature delivery timelines, updating the team’s list of risks, and potentially revising the team’s list of program objectives. Identify any ‘stretch objectives’ and add them to their list of program objectives.

Scoring PI Objectives – Business value is assigned to each objective (scored 1-10). Formulate objectives by thinking about the problems being solved for the user (Better, Faster, Cheaper, and so on). Think of features as being the solutions to those problems. Features have specific benefits for the user, and these are usually traceable back to an epic ‘value statement’ and from there back to at least one of the strategic themes identified for the business .

ROAM’ing exercise on their list of risks

• R: Resolved . The team has resolved (or knows how to resolve) the risk.
• O: Owned . The teams decide to ‘own’ the risk, that is, they will take responsibility to work to resolve the risk on their own without needing to escalate for help.
• A: Accepted : The team accepts the risk as something that is ‘part of life’, or part of the cost of doing business.
• M: Mitigated : The team believes they can take specific actions to reduce the impact of the risk.

Program Wall Board Update

The Program Wall Board represents the consolidated feature delivery timeline from all teams. It is used to provide a consolidated summary of feature completion dates, enabler items, dependencies, and major program milestones.

Program Confidence Vote

It is a Fist-of-Five vote from all team members. Any vote less than 3 should be explored and commitments potentially reworked until all team members vote at least a 3.

PI Planning Event Retrospective

It can be as simple as a 2-column table drawn on a whiteboard or flip-chart with a column for ‘what went well’ and another for ‘needs improving’. A Dot Voting exercise can be done to identify the issues most important to the gathered teams.

Benefits of PI Planning

• Establishing face-to-face communication among all team members and stakeholders
• Building the social network the ART depends upon
• Aligning development to business goals with the business context, Vision, and  Team and Program PI objectives
• Identifying dependencies and fostering cross-team and cross-ART collaboration
• Providing the opportunity for “just the right amount” of architecture and  Lean User Experience (UX) guidance
• Matching demand to capacity, eliminating excess Work in Process (WIP)
• Fast decision making

Best Practices for PI Planning

Here are some best practices for PI planning:

• Involve the entire team: PI planning should involve the entire agile team, including product owners, scrum masters, developers, testers, and any other stakeholders involved in the development process. This helps to ensure that everyone is on the same page and that all perspectives are taken into account.
• Set clear goals and priorities: It is important to set clear goals and priorities for the upcoming program increment. This helps to ensure that everyone is working towards the same objectives and that the most important work is prioritized.
• Use a visual planning tool: Using a visual planning tool, such as a Kanban board or Gantt chart, can help to make the planning process more efficient and effective. It provides a clear picture of the work to be done and helps to identify dependencies and potential issues.
• Break down work into small, manageable pieces: Breaking down the work into small, manageable pieces, such as user stories, helps to make it more manageable and easier to estimate. It also allows for more frequent feedback and course corrections.
• Estimate effort and capacity realistically: It is important to estimate the effort required to complete each item realistically and to take into account the team’s capacity to complete the work within the timeframe of the program increment.
• Plan for contingencies: It is important to plan for contingencies, such as unforeseen issues or delays, to ensure that the team is able to stay on track and meet its goals.
• Establish clear communication channels: Clear communication channels should be established to keep everyone informed throughout the increment. This includes regular check-ins, progress reports, and open communication channels for addressing issues or concerns.
• Keep the planning session focused: PI planning can be a long process, so it is important to keep the team focused and avoid distractions. This can be achieved by setting clear objectives, managing the agenda, and encouraging active participation from all team members.
• Align with the organization’s strategy: The goals and priorities set during PI planning should align with the organization’s overall strategy and objectives. This helps to ensure that the work being done is driving the organization toward its larger goals.
• Plan for learning and improvement: PI planning should include a focus on learning and improvement. This can be achieved by setting goals for experimentation, incorporating feedback from customers or users, and regularly reflecting on the team’s performance and processes.
• Involve stakeholders: PI planning should involve key stakeholders, such as customers or users, to ensure that their needs are taken into account during the planning process. This can help to improve the quality of the work being done and increase stakeholder satisfaction.
• Continuously refine the plan: The plan created during PI planning should not be set in stone. It should be continuously refined and adjusted based on new information or feedback from the team or stakeholders. This helps to ensure that the team is always working towards the most important objectives and that they are able to adapt to changing circumstances.

Frequently Asked Questions

Who are the participants of pi planning.

All the teams of the Agile Release Train, Scrum Masters, Product Owners, Developers, Stakeholders, Business owners, Suppliers, Users, & Customers.

Who conducts the PI Planning session?

The Release Train Engineer (RTE) is at the front of facilitating the PI Planning session and ensures that a seamless and smooth PI session is done.

What are the Challenges of PI Planning?

PI Planning does have its huge benefits but at the same time, it can have some challenges. Some of them are listed below:

• Complexity: PI Planning involves coordinating multiple teams within an ART, each with its own objectives, dependencies, and priorities. This complexity can make it challenging to develop a cohesive plan that meets everyone’s needs.
• Time Constraints: PI Planning is a time-boxed event, typically lasting two days. This compressed timeframe can make it difficult to discuss and plan for all the work that needs to be done.
• Communication: Effective communication is essential during PI Planning, but it can be challenging to ensure that everyone is on the same page, especially when dealing with a large number of people and complex dependencies.
• Resistance to Change: Some team members may be resistant to change, which can create friction during the planning process and impede progress.
• Lack of Prioritization: Without clear prioritization, teams may struggle to focus on the most critical work during PI Planning, leading to inefficiencies and delays.
• Dependencies: Identifying and managing dependencies between different teams and features can be challenging and time-consuming, especially when there are many interdependencies to consider.

What is the difference between a PI Roadmap and a Solution Roadmap?

A PI Roadmap provides an overview of the Program Increment, which typically lasts for ten weeks. It outlines the objectives, milestones, and deliverables for each team within the ART (Agile Release Train) for the upcoming PI. The PI Roadmap is developed during PI Planning and provides a high-level view of the work that will be completed during the PI.

PI Roadmap is created before your PI Planning event and also reviewed and updated by Product Management after the event is finished. It will usually cover three Program Increments:

• The current increment (work that’s committed)
• The next forecasted increment (planned work based on forecasted objectives)
• The increment after that (further planned work based on forecasted objectives)

On the other hand, a Solution Roadmap provides a long-term view of the solution, typically covering 12-24 months or more. It outlines the overarching goals and objectives for the solution, including the features, enablers, and capabilities that will be delivered over time. The Solution Roadmap is developed during the Solution Management process, which is responsible for defining and managing the solution vision, roadmap, and backlog.

In summary, a PI Roadmap focuses on the upcoming PI and provides a detailed plan for the next 10 weeks, while a Solution Roadmap focuses on the long-term vision of the solution and outlines the features and capabilities that will be delivered over a more extended period.

What is Post PI Planning?

Post-PI Planning takes place subsequent to the completion of PI Planning by all the ARTs for the following increment. During this stage, the teams present their plans, clarify their aims, and communicate important milestones and anticipated schedules. Post-PI Planning session ensures that you have a finalized set of PI Objectives that have to be implemented, and all the expected dates and milestones for delivering the final increment. These are mapped onto a physical or a Digital Solution Board.

The Release Train Engineer explains and discusses the objectives, dependencies, impediments, and risks of the PI. Risks are identified and mitigated, using the ROAM technique. If there are any aspects of the planning session that are left or not clearly understood, then a Rework Session is held to review the plan with the Agile Release Train.

Similar to PI Planning events, Post-PI Planning employs a planning board. However, instead of features, it lists capabilities, dependencies, and milestones for each iteration and ART. Any possible issues and risks are recognized, deliberated, and addressed by either taking ownership, resolving them, accepting them, or minimizing their impact. Plans undergo a first-of-five vote of confidence to ensure they align with the solution’s objectives, much like regular PI Planning events. The plans are reworked until the attendees’ average confidence level is three fingers or more.

Benefits of Post-PI Planning

• Aligns the Team: Post-PI Planning is an opportunity for the entire team to come together and review the progress made in the previous Program Increment, discuss any challenges faced, and align themselves with the upcoming goals and objectives. It ensures that everyone is on the same page and working towards the same goal.
• Identifies Dependencies: During Post PI Planning, teams identify dependencies between different features, systems, and teams. This helps them to coordinate their efforts better and ensures that all the necessary components are developed in time for integration.
• Promotes Transparency : Post-PI Planning promotes transparency and accountability within the team. It encourages open communication and helps to identify any issues or concerns early on, which can then be addressed promptly.
• Enhances Predictability : Post-PI Planning helps to enhance predictability in the project by providing a clear plan of action for the upcoming Program Increment. This allows the team to prioritize their work and focus on delivering the most critical features first.
• Facilitates Continuous Improvement: Post-PI Planning is an opportunity for the team to reflect on the previous Program Increment and identify areas for improvement. This helps them to continuously improve their processes, tools, and techniques and ensures that they are delivering value to the customer.

Executing a successful PI Planning event is pivotal for organizations following the SAFe framework. By following these steps and incorporating the provided tips and tricks, teams can navigate the complexities of PI Planning with confidence. This comprehensive guide aims to equip Agile Release Trains and teams with the knowledge needed to achieve alignment, collaboration, and success in their Program Increments.

•    English

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 Inspect and Adapt (I&A) is a significant event held at the end of each PI, where the current state of the Solution is demonstrated and evaluated. Teams then reflect and identify improvement backlog items via a structured problem-solving workshop.

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 SAFe Core Values as well as a dimension of the Continuous Learning Culture core competency. While opportunities to improve can and should occur continuously throughout the 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 ART Backlog for the next PI Planning event. In this way, every ART improves every PI. A similar I&A event is held by Solution Trains .

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)
• System and Solution Architects
• Product Management ,  Business Owners , and other stakeholders

Additionally, Solution Train stakeholders may also 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 after every iteration. This demo shows all the Features the ART has developed during 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 extra preparation and setup 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.

Before 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 , as illustrated in Figure 1.

The achievement score is calculated by separately totaling the business value for the plan and actual columns. The uncommitted objectives are not included in the total plan. However, they are part of the total actual. Then divide the actual total by the planned total to calculate the achievement score illustrated in Figure 1.

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.

Each team’s planned vs. actual business value is rolled up to create the ART 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 are excluded from the planned commitment. However, they are included in the actual business value achievement, as can also be seen in Figure 1.)

Retrospective

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

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

Key ART stakeholders—including Business Owners, customers, and management—join the retrospective and problem-solving workshop teams. The Business Owners can often unblock the impediments outside the team’s control.

Problem-Solving Workshop

The ART holds a structured, root-cause problem-solving workshop to address systemic problems. Root cause analysis provides a set of problem-solving tools used to identify the actual causes of a problem rather than just fixing the symptoms. The RTE typically facilitates the session 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 saying 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 concisely as possible. 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 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, the main bones often start with the default categories of people, processes, tools, program, and environment. However, these categories should be adapted as appropriate.

Team members then brainstorm causes that they think contribute to solving the problem and group them into these categories. Once a potential cause is identified, its root cause is explored with the 5 Whys technique. By asking ‘why’ five 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 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 beneficial when many possible courses of action compete for attention, which is almost always the case with complex, systemic issues.

Once all the possible causes-of-causes are 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. For example, each person gets five votes to choose one or more 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. Restating it should take only a few minutes, as the teams clearly understand the root cause.

Brainstorm Solutions

At this point, the restated problem will start to imply some potential solutions. The team brainstorms as many possible corrective actions as possible 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 viable solutions. These potential solutions are written as improvement stories and features, planned in the following PI Planning event. During that event, the RTE helps ensure that the relevant work needed to deliver the identified improvements is planned. This approach closes the loop, thus ensuring that action will be taken and that people and resources are dedicated as necessary to improve the current state.

Following this practice, problem-solving becomes routine and systematic, and team members and ART stakeholders can ensure that the train is solidly on its journey of relentless improvement.

Inspect and Adapt for Solution Trains

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 Solution Train. In larger value streams, however, an additional Solution Train 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. This subset of people consists of the Solution Train’s primary stakeholders and representatives from the various ARTs and Suppliers .

Last update: 22 January 2023

Privacy Overview

• All Exams Instant Download
• Order Tracking

• Microsoft Online Training
• Network Appliance Online Training
• IBM Online Training
• VMware Online Training
• Network Appliance

What is an Archtiect’s primary responsibility during management review and problem solving?

• Scrum , SAFe-Architect

What is an Archtiect’s primary responsibility during management review and problem solving? A . Look for opportunities to provide additional capacity for more architectural work B . Assign business value to the architecture objectives C . Create new Enabler stories D . Discuss adjustments that will continue to support the architecture Vision

View Answer

Answer: D Explanation: Discuss adjustments that will continue to support the architecture Vision

Latest SAFe-Architect Dumps Valid Version with 122 Q&As

Latest And Valid Q&A | Instant Download | Once Fail, Full Refund