Hard Difficulty Questions

Increase the team size to handle the influx of work.

Why it fails: Increasing team size often introduces communication overhead and Brooks’s Law effects, which actually decrease individual productivity. Instead of adding more people, the team should focus on limiting the amount of active work in progress to ensure that existing resources are focused on completing current tasks before starting new ones.

Prioritize work by effort rather than business value.

Why it fails: Prioritizing by effort ignores the economic impact of the work. SAFe emphasizes economic prioritization to ensure that the most valuable features are delivered first. Regardless of effort, the team must focus on delivering the highest business value to the customer to ensure the long-term viability of the solution.

Shift to a Waterfall model to better track progress.

Why it fails: Moving to Waterfall increases batch sizes and creates longer feedback loops, which is contrary to Lean-Agile values. The goal is to reduce batch sizes to increase flow, not to adopt a methodology that relies on large, monolithic releases that hide issues until the end of the development phase.

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.

Performing manual integration testing in a dedicated hardening iteration prior to release.

Why it fails: Built-in Quality requires integration and testing continuously within each iteration, not deferred to a separate hardening phase, which reintroduces phase-gated verification. It tempts because hardening iterations exist in some traditional lifecycles, and would be correct where quality is inspected in after development rather than built in.

Submitting all completed code to an independent quality assurance department for final verification.

Why it fails: Built-in Quality places verification with the team itself through automated tests and collective ownership, not a separate QA department gating code after completion. It tempts because independent QA is standard in waterfall, and would be correct where a distinct assurance function owns release sign-off.

Deferring refactoring tasks to dedicated technical debt sprints scheduled every six months.

Why it fails: Built-in Quality demands continuous refactoring as part of daily work, not batching technical debt into periodic sprints that let design decay between them. It tempts because debt sprints appear to address accumulated issues, and would be correct in a plan-driven model where refactoring is scheduled separately.

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.

Using a strict 'command and control' management style to ensure compliance.

Why it fails: Command and control suppresses the creative potential of knowledge workers. By removing their ability to make decisions, management destroys their intrinsic motivation. This leads to disengagement, lower innovation, and a lack of ownership, which is exactly the opposite of what is needed in a modern, agile organization.

Offering competitive financial bonuses based on individual performance.

Why it fails: While extrinsic rewards like bonuses are common, research shows they often fail to motivate knowledge workers in the long term, and can even decrease performance. Intrinsic motivation comes from autonomy, mastery, and purpose, not from purely financial incentives which are often perceived as transactional rather than empowering.

Assigning specific tasks daily to ensure high utilization.

Why it fails: High utilization of individuals does not equate to high value for the business. Assigning tasks daily is a micro-management approach that treats individuals as resources, not experts. This reduces the autonomy of the workers and prevents them from self-organizing around the most important work, lowering overall team morale.

Training all developers on Scrum methodology.

Why it fails: While training is important, training all developers on Scrum is not the primary focus of the 'Leading the Change' phase. This step is about executive alignment and preparing the leadership team. Scrum training typically happens during the 'Train Lean-Agile Change Agents' or 'Train Teams' phases later in the roadmap.

Appointing a single Chief Transformation Officer to dictate all process changes.

Why it fails: SAFe discourages centralized, dictatorial approaches to transformation. While a transformation lead or office is helpful, the process must involve collaborative decision-making. Dictating changes from the top down ignores the specific needs of individual value streams and undermines the principle of decentralized decision-making inherent in the Lean-Agile mindset.

Replacing all existing middle management with Agile coaches.

Why it fails: Replacing middle management is not a recommended practice. Instead, SAFe advocates for training middle managers to become Lean-Agile leaders. By shifting their focus from command-and-control to servant leadership, these managers become vital assets in the transition, providing the stability and guidance needed to support teams through the shift.

Improved quality due to specialized oversight

Why it fails: Specialized oversight often leads to silos where quality is seen as the responsibility of 'testers' rather than the whole team. True quality is achieved when the entire cross-functional team takes ownership of the work, from design through to deployment, rather than relying on external silos for review.

Increased speed of delivery

Why it fails: Functional silos inherently introduce hand-offs, which are a major source of delay in any development process. Each hand-off requires context switching, communication, and waiting for the next team to pick up the work, which slows down the overall cycle time significantly compared to cross-functional teams.

Better alignment with the Agile Release Train

Why it fails: The Agile Release Train is specifically designed to break down these silos by creating cross-functional teams that work together. Maintaining functional silos contradicts the very essence of the ART, which requires people from different disciplines to work together as a single, cohesive unit to deliver value.

Immediately move the epic to Implementing so its Cost of Delay is captured before market conditions change.

Why it fails: Moving an epic straight to Implementing bypasses the ART's own planning and capacity commitment. Portfolio Backlog items are prioritized candidates, not scheduled work; the ART decides during PI Planning whether and when it can pull them. Forcing the epic into Implementing ignores the ART's WIP limits and would overload the teams, likely delaying both the epic and existing commitments.

Split the epic into smaller features and assign each feature directly to individual Agile Teams without ART planning.

Why it fails: Decomposing an epic is a legitimate technique, but assigning features directly to teams bypasses the ART's PI Planning, where dependencies are identified and capacity is negotiated. Direct assignment also violates the principle that teams pull work rather than having it pushed. The epic-level decision belongs with the LPM team, while feature-level execution belongs with the ART and its teams.

Reject the epic and return it to the Funnel so the ART is not pressured to accept work it cannot deliver.

Why it fails: Rejection is reserved for epics that fail the Lean business case or no longer align with strategy. This epic has a strong Cost of Delay and a positive business case, so sending it back to Funnel discards a validated opportunity simply because of timing. The Portfolio Backlog exists precisely to hold approved-but-not-yet-started work while ARTs plan capacity.

Implement strict command-and-control governance to ensure teams adhere to standardized processes.

Why it fails: Command-and-control governance contradicts SAFe's principles of decentralized decision-making and empowerment. It stifles innovation and slows response to change. SAFe promotes lean-agile leadership, where teams are trusted to make decisions within guardrails. Strict governance would hinder the cultural shift toward adaptability and could lead to disengagement and reduced flow of value.

Focus exclusively on individual team performance metrics to drive accountability.

Why it fails: Focusing solely on individual team metrics can create silos and suboptimization. SAFe emphasizes measuring flow and value delivery across the ART and portfolio, not just team-level outputs. While team metrics are useful, an overemphasis on them can lead to local optimizations that harm overall adaptability. A balanced set of metrics, including business outcomes and flow efficiency, is needed to support a thriving culture.

Mandate that all teams use the same tools and processes without exception to ensure consistency.

Why it fails: Mandating identical tools and processes across all teams ignores the diversity of contexts and can reduce motivation and innovation. SAFe allows for flexibility within guardrails, recognizing that teams may need different approaches to optimize flow. While some standardization can help, a rigid mandate can hinder adaptation and create resistance. The focus should be on aligning on principles and outcomes, not enforcing uniformity.

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.

Rewarding teams for maintaining the status quo.

Why it fails: Rewarding the status quo is the antithesis of relentless improvement. It discourages innovation and risk-taking, leading to stagnation. SAFe organizations should reward learning, experimentation, and the pursuit of better processes, even if those experiments do not always lead to immediate success in the short term.

Focusing exclusively on technical debt removal.

Why it fails: While technical debt reduction is important for quality, it is only one part of the picture. Relentless improvement must also address process, team collaboration, business practices, and value stream efficiency. Focusing only on one area ignores the need for holistic improvement across all aspects of the organization.

Escalate the dependency issues to the Lean Portfolio Management group for resolution.

Why it fails: Escalating to LPM may be necessary for cross-portfolio issues, but this is an ART-level problem that the RTE and teams should address first. LPM is focused on portfolio strategy and funding, not on day-to-day dependency management within an ART. Escalating too early bypasses the ART's own problem-solving mechanisms and can delay resolution, so it is not the best first action.

Cancel the current PI and start a new PI Planning session to reset dependencies.

Why it fails: Canceling the PI is a drastic overreaction that would disrupt delivery and undermine trust. The issues described—outdated dependencies and misalignment—are common challenges that can be addressed through inspection and adaptation within the PI. A new PI Planning session might help, but it is not the first or most proportionate action; the RTE should instead coach the ART to improve its current execution.

Ask the Scrum Masters to update the Program Board on behalf of their teams.

Why it fails: Having Scrum Masters update the board removes ownership from the teams and does not solve the underlying issue of teams not collaborating or communicating. The Program Board is a team-level tool that should be updated collaboratively during ART sync events. This action may make the board look better but will not improve actual dependency management or alignment with PI objectives.

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.

Principle 3: Assume variability.

Why it fails: Variability is expected, but the issue is the lack of integration, which is a systemic problem. While variability might make integration difficult, the core failure is the lack of a systems-level view that prioritizes the health of the entire train over the individual team's isolated focus on their own tasks.

Principle 1: Take an economic view.

Why it fails: The economic view is important for prioritization, but it doesn't directly address the behavioral issue of teams working in isolation. While the lack of integration is economically harmful, the solution to this specific problem is to change the mindset of the teams to one of collective responsibility for the system.

Principle 5: Base milestones on objective evaluation.

Why it fails: Milestones help track progress, but they don't fix the lack of collaboration between teams. The problem is a lack of integration-oriented culture. Implementing milestones without first applying systems thinking will only lead to more formal tracking of a broken process, rather than solving the underlying issue of silos.

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.

Reduce the scope of every active project equally to save money.

Why it fails: Reducing all projects equally is a 'peanut butter' approach that treats all work as equally important, which is rarely true. This often results in none of the projects reaching the 'done' state. It is far better to fully fund the most valuable initiatives and pause others to ensure actual value delivery.

Ask the Agile Release Trains to work overtime to finish all planned epics.

Why it fails: Overtime is a short-term, unsustainable tactic that leads to burnout and quality issues. It does not address the underlying problem of having too much work for the available budget. The portfolio must align its commitments with its capacity rather than relying on unsustainable human effort to cover strategic planning gaps.

Request a budget increase from the enterprise to avoid cutting any work.

Why it fails: While sometimes necessary, simply requesting more money does not teach the organization to prioritize effectively. Lean Portfolio Management is about optimizing the use of existing resources. A good manager must first demonstrate that the existing budget is being used for the highest-value work before seeking additional funds from the enterprise.

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.

Mandate that all testing be done by a separate QA team at the end of the PI

Why it fails: Mandating separate QA at the end of the PI increases batch sizes and delays feedback, which violates the principle of assuming variability and preserving options. It also creates a bottleneck and prevents early learning. The principle encourages keeping options open and using fast feedback to make decisions, not centralizing testing late. This approach would worsen the ART's problem rather than solve it.

Lock down the requirements early so testers can create detailed test plans in advance

Why it fails: Locking down requirements early contradicts the principle of assuming variability and preserving options. It reduces flexibility and delays feedback because test plans are based on assumptions that may change. The principle encourages keeping design and requirements options open as long as possible. This approach would increase rework and reduce the team's ability to respond to change, making it a poor fit for the scenario.

Assign testers to work only on a single feature at a time to increase specialization

Why it fails: Assigning testers to a single feature at a time may reduce context switching, but it reinforces specialization and does not address the root cause of late defect detection. It also does not preserve options or assume variability; it simply narrows focus. The principle calls for cross-functional collaboration and fast feedback, not further siloing. This option fails to improve flow or quality systematically.

Approving every individual feature request generated by the Agile Release Trains.

Why it fails: Approving individual features is a tactical activity that leads to micromanagement and bottlenecks. LPM focuses on higher-level strategic funding and portfolio-level epics. ARTs should be empowered to manage their own backlogs and feature sets to maintain flow and autonomy, provided they stay within their assigned value stream budget.

Ensuring that the budget for each team remains fixed for the entire fiscal year.

Why it fails: Fixed annual budgets prevent the agility required in modern markets. SAFe promotes dynamic budgeting, where funds are allocated based on the strategic importance of the value stream. This allows the organization to reallocate resources to higher-priority areas as needed, rather than being locked into outdated plans from previous months.

Replacing the Lean Budgeting process with detailed task-level time tracking.

Why it fails: Task-level time tracking is a legacy practice that adds significant administrative waste without providing strategic value. Lean Portfolio Management replaces such bureaucratic overhead with objective metrics and outcomes-based measures. It emphasizes value delivery over labor hours, fostering a culture of transparency and accountability based on actual business results.

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.