Refer to the Exhibit Practice Questions

Increase the WIP limit of the Analysis state to 5 to accommodate the current volume.

Why it fails: Simply increasing the WIP limit to match the current overflow is a 'vanity' fix that ignores the underlying process failure. It allows the systemic inefficiency to continue unabated, as it does not address why the team is struggling to process the existing items within the defined constraints.

Immediately move two items from Analysis to the Portfolio Backlog to adhere to the limit.

Why it fails: Moving items back to the backlog without addressing why they are stuck in analysis is ineffective. The team needs to collaborate to finish the work currently in the state or re-evaluate the priorities. Arbitrarily moving items just to satisfy a metric without progress does not improve value flow.

Report the policy violation to the Portfolio Steering Committee for executive intervention.

Why it fails: Involving executive committees for local process deviations creates unnecessary bureaucracy and delays. The Lean Portfolio Management team is empowered to manage their own flow and process. Escalation should only occur if the team cannot resolve the bottleneck through their own collaborative efforts and standard Lean-Agile problem-solving techniques.

Start a new task from the backlog to stay busy.

Why it fails: Starting a new task when the team is blocked violates the principle of finishing work before starting new work. It increases total WIP and adds to the context-switching burden, which ultimately slows down the entire delivery process instead of helping to resolve the immediate blocker at hand.

Wait for the manager to assign new work.

Why it fails: Waiting for external assignment is contrary to the self-organizing nature of Agile teams. In a Lean environment, the team is responsible for managing its own flow. Relying on management for tasking creates a dependency that introduces delay and fails to utilize the collective problem-solving capabilities of the team.

Report the blocker to the PM and return to the office.

Why it fails: Reporting a blocker is a communication step, but passive waiting is unproductive. The team should take proactive measures to resolve the issue themselves. SAFe encourages teams to manage their own flow; simply escalating without attempting to swarm or assist elsewhere ignores the team's responsibility to maintain system flow.

High team velocity.

Why it fails: A velocity of 40 points is a measure of capacity and is neither good nor bad on its own. The problem is not how fast the team works, but rather that the queue is too long, meaning they are likely working on too many things simultaneously.

Average feature duration of 2 weeks.

Why it fails: A 2-week duration might be appropriate for the feature size. The issue is not necessarily the speed at which a feature is completed, but the time spent sitting in the queue before development even begins, which is driven by the total number of items currently in the system.

The iteration length is too short.

Why it fails: Iteration length is a standard SAFe construct and is not the cause of flow inefficiency. The problem lies in the work management and queueing behavior, not the structural cadence of the PI, which is designed to support, not hinder, the delivery of features to the customer.

Allocate 90% of the budget to Horizon 3 to secure future market dominance.

Why it fails: Allocating excessive budget to research initiatives (Horizon 3) leaves the organization vulnerable to current competitive threats. A balanced portfolio must prioritize immediate revenue generation (Horizon 1) to fund the long-term exploration efforts, otherwise, the enterprise risks running out of capital before the research projects can mature.

Focus all funding on Horizon 1 projects to maximize immediate quarterly profits.

Why it fails: Ignoring Horizon 2 and 3 leads to technical debt and loss of market relevance. While Horizon 1 is necessary for cash flow, a lack of investment in future growth eventually results in a declining market share as the current solutions become obsolete compared to newer, more innovative offerings.

Require Horizon 3 projects to demonstrate profitability within the next two quarters.

Why it fails: Horizon 3 is inherently exploratory and carries a high risk of failure or long time-to-market. Imposing short-term profitability metrics on long-term research stifles innovation and forces teams to focus on 'safe' bets rather than the breakthrough developments needed for future growth and competitive advantage in the market.

Principle 5: Base milestones on objective evaluation.

Why it fails: This configuration setting has nothing to do with milestones or evaluation processes. While milestones are important for progress tracking, they are unrelated to the authority level of decision-making. Objective evaluation requires data and metrics, whereas decentralization is about the governance model of the organization and team empowerment.

Principle 6: Visualize and limit WIP.

Why it fails: While the config mentions WIP limits, that is a separate configuration key. Decentralized decision-making is a distinct principle that focuses on governance and authority, whereas WIP limits are a flow control mechanism. They are both parts of the same configuration but represent fundamentally different Lean-Agile concepts and goals.

Principle 7: Apply cadence and synchronization.

Why it fails: Cadence and synchronization are related to the rhythm and scheduling of work. Decentralized decision-making is about the authority over that work. While they both contribute to the overall SAFe framework, they address different aspects of organizational performance and team management, ensuring that work is both planned and executed correctly.

Increase developer hours to improve processing time.

Why it fails: Processing time is only six days out of twenty-eight. Even a significant reduction in processing time would yield minimal impact on the total lead time. The bottleneck is clearly the wait time, suggesting that work is sitting idle rather than being hampered by slow manual effort.

Increase the throughput target for the next iteration.

Why it fails: Increasing throughput targets without addressing the current wait time will likely increase the work-in-process (WIP). Higher WIP leads to even longer queues, which would further inflate the already high wait time, potentially causing a feedback loop that degrades the overall system's stability and predictability.

Focus on automating the testing phase.

Why it fails: While automation is beneficial, the current metrics show that wait time is the dominant factor in the lead time. Unless the testing phase is identified specifically as the primary queue, focusing exclusively on automation may not address the systemic issues causing the high wait time.

Bypass the policy, as it is outdated and hinders speed.

Why it fails: Bypassing security and architectural policies exposes the organization to significant risks. Agile does not grant permission to ignore governance. The correct path is to collaborate with the responsible bodies to update or automate the policy, not to unilaterally ignore it, which would compromise the integrity and safety of the system.

Manually email the approvers every time the team is ready to deploy.

Why it fails: Manual processes create bottlenecks that prevent continuous delivery. While it might get the feature out, it does not solve the underlying issue of why the deployment process is not automated. The team should focus on process improvement rather than relying on manual workarounds that do not scale effectively.

Ask the Product Owner to approve the deployments instead.

Why it fails: The Product Owner lacks the authority to override security and architecture policies. Their role is to define business value, not to sign off on technical or security compliance. Seeking their approval would be an incorrect escalation that fails to address the specific requirements set by the Security and Architecture leads.

Analysis

Why it fails: While Analysis is over its limit of 5, the overflow of 7 units is less critical than the overflow in Development. Focusing on the primary constraint first ensures that the most impactful bottleneck is resolved, which typically yields the greatest improvement in overall system cycle time and throughput.

Testing

Why it fails: Testing is under-utilized, as the current WIP of 2 is well below the limit of 6. This suggests that the stage is starved for work due to the upstream bottlenecks in Analysis and Development. Increasing capacity here would not improve system performance until the upstream constraints are addressed.

Done

Why it fails: The 'Done' stage represents completed value, not a bottleneck in the current development process. While total throughput is tracked here, it does not exert pressure on the system's active WIP limits. Focusing on this stage does not help in identifying or mitigating the current flow constraints within the system.

Ignore the dependencies and encourage the teams to work harder to overcome them during the PI.

Why it fails: Ignoring systemic risks is a recipe for failure. Relying on 'working harder' (heroics) is not sustainable and ignores the root cause—the architectural or organizational structure that creates the dependency. Proactive management of dependencies is required to ensure that the ART can deliver value predictably throughout the PI.

Force the teams to consolidate into a single, larger team for the duration of the PI.

Why it fails: Combining teams into a larger unit often leads to increased communication overhead and reduced individual team velocity. It does not address the underlying dependency issue. SAFe favors small, cross-functional teams that are organized around value, not arbitrary consolidation that disrupts team dynamics and individual accountability.

Cancel the PI and delay all work until the dependencies are resolved by management.

Why it fails: Canceling the PI is a drastic, unnecessary measure that halts the flow of value. SAFe is designed to handle complexity and dependencies through active management and transparency, not by stopping. The goal is to learn to operate within the existing constraints while systematically working to remove them over time.

Replace the database entirely with a NoSQL solution in a single release.

Why it fails: A 'big bang' migration is highly risky and often fails in complex enterprise environments. SAFe promotes incremental change through Enabler Features. Replacing the entire database at once ignores the risks of data integrity loss and system downtime, failing to adhere to the principle of managing risk through small increments.

Increase the number of developers assigned to the integration team to resolve conflicts.

Why it fails: Adding more people to a bottleneck often exacerbates the problem rather than solving it, according to Brooks' Law. Increasing the size of an integration team does not address the underlying architectural issue of tight coupling; it merely adds communication overhead and delays the realization of actual business value.

Direct the ART to prioritize non-functional requirements (NFRs) over user stories for the next three PIs.

Why it fails: Ignoring user stories for three PIs would halt the delivery of business value, which is unsustainable for the business. SAFe requires a balance between business features and enablers. A sustainable approach involves integrating NFRs into the continuous flow of work rather than stopping feature development entirely for extended periods.

Principle 2: Apply systems thinking.

Why it fails: Systems thinking encourages understanding the entire value stream rather than optimizing local components. While the delay is an issue, it is specifically a queue management problem. Focusing on Principle 6 is more direct, as it specifically addresses the management of wait times and queues within the flow of work.

Principle 1: Take an economic view.

Why it fails: While the delay certainly has negative economic consequences, the root cause is the operational structure of waiting for approval. The immediate action to fix this is to address the queue, which is the focus of Principle 6. An economic view justifies the change but doesn't define the process.

Principle 8: Unlock the intrinsic motivation of knowledge workers.

Why it fails: Waiting for bureaucracy likely demotivates the team, but the primary failure is a process-related bottleneck. The team's motivation is impacted because they are unable to progress, but the core issue is the structure of the workflow rather than an explicit failure to motivate the team members directly.

Principle 1: Take an economic view

Why it fails: While the policy has negative economic impacts due to increased lead times and bottlenecks, the primary violation is the governance model used. The policy is a direct attempt to force centralized decision-making, which is the specific focus of Principle 9, making it a better fit for this scenario.

Principle 5: Base milestones on objective evaluation

Why it fails: The policy describes how design is managed, not how the project's progress is measured. While the design choices might affect objective evaluation, the policy itself is not about how the team evaluates their milestones. The error is the centralization of authority, not the measurement of progress.

Principle 2: Apply systems thinking

Why it fails: Systems thinking is about the whole value stream. While this policy creates a bottleneck that hurts the system, it is a specific symptom of a centralized governance structure. Principle 9 is the specific guidance SAFe provides to fix this type of management error, making it the most direct violation.

Maintain a central Quality Assurance department to review all pipeline results.

Why it fails: Having a central QA department review automated results defeats the purpose of the automation. It keeps the human bottleneck in place. The culture should shift to having the team act on the automated results immediately, eliminating the need for a separate, disconnected group to review the work.

Accept that quality will initially decline during the transition to automation.

Why it fails: Quality should not decline; it should be baked into the pipeline. Accepting a decline in quality is an admission of failure. The goal is to incrementally replace manual checks with automated ones so that at any point in time, the system remains in a releasable state, upholding standards.

Implement a 'two-person rule' where every commit must be reviewed by a lead developer.

Why it fails: Mandatory manual reviews for every commit can create a significant bottleneck, contradicting the speed intended by a Continuous Delivery policy. While pair programming is a great practice, making it a rigid policy for every commit can slow down the flow of work, particularly in larger ARTs.

Allow the initiative to proceed to the 'Analyze' state, provided it is small in size.

Why it fails: Allowing the initiative to bypass the business case requirement violates the established portfolio policy. Size does not exempt an initiative from governance. Exceptions undermine the integrity of the Portfolio Kanban and can lead to unvetted work consuming capacity that should be reserved for strategic, well-justified enterprise initiatives.

Update the policy to remove the requirement for a business case to speed up flow.

Why it fails: Arbitrarily removing policy requirements to expedite work is a reactive measure that compromises governance. While speed is important, it must be balanced with the need for informed investment decisions. Removing the requirement for a business case effectively hides the economic rationale for the initiative, increasing financial risk.

Ignore the missing document because the Strategic Theme Alignment is clearly visible.

Why it fails: Strategic alignment alone is insufficient; a business case is necessary to justify the cost and effort. Ignoring the policy makes the governing framework meaningless. Lean Portfolio Management relies on both strategic alignment and economic justification to ensure that the organization is not only doing the right things but doing them affordably.

Approve the epic immediately because the ROI is high.

Why it fails: High ROI is not the only factor for success. If the epic does not align with the portfolio's strategic themes, it represents a deviation from the organization's goals. Funding it would mean using resources on work that does not advance the enterprise, representing a strategic failure in management.

Approve the epic but require a higher risk management plan.

Why it fails: The issue is not the risk level; the issue is the lack of strategic alignment. A risk management plan does nothing to fix the misalignment. The epic would still be a distraction, and adding risk mitigation processes would only increase the overhead of a project that shouldn't be happening.

Request the team to rename the epic to make it appear more aligned.

Why it fails: Renaming an epic is a cosmetic change that does not address the fundamental issue of strategic misalignment. It is a dishonest practice that creates a false sense of alignment and risks wasting resources on work that does not contribute to the organization's core business objectives and strategic goals.