Select Two (Multi-Select) Questions

Encourage teams to work on as many features as possible in parallel to increase throughput.

Why it fails: Working on many features in parallel increases WIP, which contradicts the principle. Higher WIP leads to context switching, longer lead times, and reduced throughput. The principle explicitly advises limiting WIP to improve flow, so this action would worsen the problem rather than solve it.

Increase the number of features in the program backlog to ensure teams always have work.

Why it fails: Increasing the number of features in the backlog does not address WIP or batch sizes; it may increase pressure to start more work, raising WIP. The principle focuses on limiting WIP and reducing batch sizes, not on expanding the backlog. This action would likely exacerbate the delays by encouraging multitasking.

Schedule a weekly status meeting to track progress on all in-progress features.

Why it fails: Status meetings do not directly limit WIP or reduce batch sizes. While tracking progress can be useful, it does not address the root cause of long lead times, which is excessive WIP and large batches. The principle calls for systemic changes to flow, such as WIP limits and smaller batches, not additional meetings.

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.

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.

The team tracks individual velocity and uses it as the primary input for performance reviews and compensation decisions.

Why it fails: Using individual velocity for performance reviews destroys the psychological safety and collaboration that technical agility requires. Velocity is a team-level planning metric with significant variance, not a measure of individual productivity. SAFe explicitly cautions against using velocity for comparison or evaluation, so this attribute would actively work against building the competency rather than support it.

The team delegates all testing and quality decisions to a separate quality assurance department to preserve developer focus.

Why it fails: Outsourcing testing and quality decisions to a separate department contradicts Built-in Quality and collective ownership. When developers do not own quality, defects flow downstream and feedback loops lengthen, which is the opposite of what Team and Technical Agility requires. Cross-functional teams in SAFe own testing, automation, and quality outcomes as part of delivering each Increment.

The team maintains a detailed three-year technology roadmap that the System Architect approves before each Iteration.

Why it fails: Long-range technology roadmaps approved by the System Architect are not an attribute of Team and Technical Agility. SAFe plans at the Program Increment cadence precisely because detailed multi-year roadmaps cannot absorb change. Requiring architect approval before each Iteration would also undermine the team's self-management and slow its ability to respond to feedback.

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.

Focus exclusively on tooling and automation to improve efficiency.

Why it fails: While tooling and automation can support efficiency, focusing exclusively on them ignores the people and culture aspects of change. Sustaining a transformation requires attention to mindset, behaviors, and leadership. Tools alone will not embed new ways of working. This action is too narrow and misses the holistic nature of Lean-Agile change.

Reduce the frequency of PI Planning to give teams more time for development.

Why it fails: PI Planning is a cornerstone of SAFe and should not be reduced; it aligns teams and provides cadence. Reducing its frequency would undermine alignment and flow. Sustaining change requires maintaining the cadence of key events, not cutting them. This action would weaken the transformation and is contrary to SAFe guidance.

Centralize decision-making to ensure consistency across all Agile Release Trains.

Why it fails: Centralizing decision-making contradicts SAFe's principle of decentralized decision-making. It can slow down response times and disempower teams. Sustaining change requires pushing decisions to the lowest level possible while maintaining alignment. Centralization would erode the autonomy and engagement that are critical for long-term success.

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.

Team Velocity

Why it fails: Team velocity is a measure of output capacity, not a component of the WSJF prioritization formula. While velocity is important for planning how much work can be accomplished, it is not used to determine the relative economic value of a specific feature or story.

Total number of stakeholders

Why it fails: The number of stakeholders is not part of the WSJF calculation. Prioritization should be based on economic value and urgency, not on how many people are asking for a feature. Relying on stakeholder count leads to 'whoever shouts loudest' prioritization, which is detrimental to overall system flow.

Funding is tied to individual projects with defined start and end dates, and teams are disbanded after each project.

Why it fails: Lean Portfolio Management moves away from project-based funding with temporary teams. Instead, it funds persistent value streams that endure over time, allowing teams to develop deep domain knowledge and maintain flow. Tying funding to projects with start and end dates creates churn, reduces predictability, and inhibits the formation of stable teams, which contradicts Lean-Agile principles.

The LPM team approves every team's individual user stories to ensure alignment with strategy.

Why it fails: Lean Portfolio Management does not involve approving individual user stories; that level of detail is handled by teams and Agile Release Trains. The LPM team focuses on strategic alignment and funding at the portfolio level. Approving user stories would be micromanagement, stifle team autonomy, and create unnecessary delays, contrary to Lean-Agile principles of decentralized decision-making.

Funding decisions are made centrally by the LPM team for every epic, regardless of size.

Why it fails: Lean Portfolio Management decentralizes funding decisions to value streams within their allocated budgets, rather than having the LPM team approve every epic. Central approval for all epics would create bottlenecks and undermine the autonomy that Lean funding aims to provide. The LPM team sets the budget and guardrails, but value streams decide which epics to fund within that budget.

Technical Excellence

Why it fails: While technical excellence is a goal and a component of the Agile Manifesto, it is not explicitly listed as one of the four pillars of the SAFe House of Lean. The four pillars are Respect for People and Culture, Flow, Innovation, and Relentless Improvement, which support the overarching goal of Value.

Customer Centricity

Why it fails: Customer centricity is a mindset and a foundational element of SAFe, but it is not one of the four pillars of the House of Lean. The pillars are Respect for People and Culture, Flow, Innovation, and Relentless Improvement, which work together to deliver the highest possible customer value.

Management by Objectives

Why it fails: Management by Objectives is a traditional management practice that is often seen as being in conflict with the Lean-Agile mindset. SAFe advocates for outcome-based planning rather than rigid management by objectives, focusing on the value stream and the delivery of working systems that provide actual business benefits.

Tie individual compensation directly to velocity metrics to motivate teams to increase their output.

Why it fails: Tying compensation to velocity distorts metrics, encourages gaming of the system, and destroys psychological safety by introducing fear. Teams will inflate estimates and hide impediments to protect their bonuses, severely compromising transparency and long-term delivery predictability.

Enforce strict adherence to standardized work templates to ensure maximum uniformity across all departments.

Why it fails: Enforcing rigid uniformity stifles local autonomy and creativity, forcing teams to follow processes that may not fit their unique context. Psychological safety thrives when teams have the autonomy to adapt their working agreements to solve specific local challenges.

Mandate overtime during every Program Increment to demonstrate high commitment to executive stakeholders.

Why it fails: Mandatory overtime leads to burnout, high employee turnover, and degraded code or solution quality, ultimately destroying team morale. Sustainable pace is a core Lean-Agile principle that prioritizes long-term health and consistent delivery over exploitative crunch periods.

They should be written as highly detailed technical requirements for developers.

Why it fails: Strategic Themes are strategic, not tactical. Writing them as technical requirements turns them into low-level tasks, which obscures the 'why' behind the work. This forces leadership to focus on 'how' instead of 'what', limiting the creativity of the teams and preventing them from finding the best technical solutions to achieve the goals.

They should be updated on a daily basis to reflect current market trends.

Why it fails: Strategic Themes provide a stable, long-term direction for the portfolio. Updating them daily would cause massive instability, making it impossible for teams to align their work to anything meaningful. They are designed to be relatively stable, providing a consistent framework for decision-making even as the market evolves over time.

They should focus exclusively on cost-cutting and headcount reduction.

Why it fails: Strategic Themes are about growth, innovation, and value delivery, not just cost-cutting. While financial health is important, an exclusive focus on reduction often stifles innovation and leads to long-term decline. Effective themes balance efficiency with the pursuit of new market opportunities and the enhancement of the customer experience.

Mandating that every team uses the same Jira workflow template.

Why it fails: Mandating specific tool workflows is not a portfolio-level guardrail. SAFe promotes team autonomy, and forcing a single workflow across different domains can hinder team performance. Guardrails should be about outcomes, financial boundaries, and architectural runway, not the specific tools or process steps used at the team level.

Reviewing all individual code commits at the portfolio level.

Why it fails: Reviewing code at the portfolio level is a massive bottleneck and a violation of decentralized decision-making principles. LPM should focus on strategic alignment and high-level outcomes, not the technical minutiae of individual code changes, which are the responsibility of the development teams themselves.

The detailed technical design specification.

Why it fails: Technical design specifications are too granular and premature for an Epic Hypothesis Statement. Including them creates a false sense of certainty and limits the team's ability to innovate or pivot based on what they learn during the initial implementation phases of the epic, which contradicts Agile's iterative approach.

The non-functional requirement list.

Why it fails: While non-functional requirements are important for any system, they are not a core component of the Epic Hypothesis Statement. This document is focused on the 'why' and 'what' of a business value proposition, whereas non-functional requirements are usually captured in the backlog or system architectural documentation as separate constraints.

Greater consistency in decision-making across the entire enterprise.

Why it fails: Decentralization often leads to a variety of local decisions that are optimized for specific contexts. While this is good for agility, it can lead to less consistency than a top-down mandate. The trade-off is higher speed and local optimization, which is generally preferred over rigid, slow consistency.

Elimination of the need for any strategic alignment with the portfolio.

Why it fails: Decentralization is not the same as anarchy. Strategic alignment is still vital. Decentralized teams make decisions within the guardrails and strategic vision set by LPM. Without alignment, decentralized teams might move in different, conflicting directions, which would undermine the overall business objectives of the portfolio and the enterprise.

Reduction in the need for cross-functional communication.

Why it fails: Decentralized decision-making actually requires more, not less, communication. Teams must coordinate with other teams to ensure their local decisions don't create negative system-wide impacts. It replaces top-down bureaucratic communication with peer-to-peer collaboration, which is essential for maintaining systemic integrity in a complex, distributed environment.

Prioritizing the Team Backlog.

Why it fails: Backlog prioritization is the responsibility of the Product Owner, who represents the customer and business value. The Scrum Master must remain neutral regarding content to focus on process and facilitation. Allowing the Scrum Master to dictate priority would conflate team process coaching with product management responsibilities.

Defining the technical architecture for the team.

Why it fails: Architecture is typically the purview of System Architects and the engineering team collectively. The Scrum Master facilitates the environment for technical decisions but does not dictate technical strategy. Encroaching on technical design would distract from their primary mission of improving team processes and individual coaching.

Approving the final product release for the customer.

Why it fails: Product release approval is a business decision made by the Product Management and stakeholders. The Scrum Master focuses on the internal mechanics of the team, not external business approvals. This separation ensures that the team stays focused on execution while business leaders manage the overall product strategy.

The implementation of a strict 'Command and Control' reporting structure.

Why it fails: Command and control is the opposite of the SAFe mindset. SAFe relies on servant leadership and decentralized decision-making. A hierarchy that focuses on control stifles innovation and slows down the feedback loops necessary for adaptation, which is fundamental to the Lean-Agile approach that SAFe promotes.

A focus on output (total features completed) over outcomes (value delivered).

Why it fails: Focusing on output ignores the actual business impact of the features. SAFe emphasizes outcomes—delivering value that helps the business grow. Simply completing a high volume of features does not guarantee success if those features do not meet customer needs or solve meaningful problems for the organization.

Strict adherence to standardized processes to reduce variability.

Why it fails: While standardization is helpful, strict adherence without room for adaptation kills innovation. SAFe emphasizes 'built-in quality' and 'alignment,' but also encourages teams to adapt their processes to suit their specific context. Rigid processes prevent teams from experimenting and improving their workflows, which is the heart of continuous learning.

Centralizing decision-making to ensure total management control.

Why it fails: Centralized decision-making is a hallmark of traditional hierarchy, not SAFe. SAFe promotes decentralized decision-making to push authority to those with the most context. This improves speed and quality, as teams can make decisions without waiting for slow, centralized approval chains that hinder the ability to adapt to changes.

Prioritizing the completion of all planned scope over customer feedback.

Why it fails: Prioritizing scope over feedback is an 'output-focused' mindset. SAFe is 'outcome-focused.' If customer feedback suggests a change is needed, the team must be able to pivot. Ignoring feedback to satisfy a fixed plan leads to delivering products that may not be useful, ultimately wasting time and investment.

Individual team member performance goals.

Why it fails: Individual performance goals are part of the HR management process, not the Portfolio Vision. Including them in the vision confuses the strategic direction of the enterprise with the operational management of individuals, which should remain separate to maintain the integrity of both processes.

Specific Jira ticket IDs.

Why it fails: Jira ticket IDs are granular, tactical data points. The Portfolio Vision is a high-level strategic document. Including ticket IDs would make the vision unmanageable and obsolete almost immediately, failing to communicate the long-term intent and strategic direction the organization needs to follow.

Increased administrative overhead due to granular project-level tracking.

Why it fails: Lean budgeting is explicitly designed to reduce the administrative burden of micro-managing individual project budgets. By moving toward value-stream funding, the organization shifts from granular tracking to broader fiscal governance, which simplifies the budgeting process and reduces the need for constant, detailed financial reconciliations.

More frequent re-budgeting cycles to ensure strict compliance.

Why it fails: Frequent re-budgeting cycles are a symptom of project-based funding that Lean Budgeting seeks to eliminate. Instead of constant revisions, Lean Budgeting uses periodic adjustments, focusing on strategic alignment rather than strict, project-based compliance, which often hinders the ability of teams to adapt to new information.

Reduced focus on the Portfolio Kanban to simplify operations.

Why it fails: The Portfolio Kanban is essential for visualizing and managing the flow of value. Lean Budgeting does not replace the Kanban; it works in tandem with it by providing the financial constraints needed to prioritize Epics effectively, ensuring that the work being done stays within the budget.