Building a Foundation with Mindset, Values and Principles practice questions

Principle 4: Build incrementally with fast, integrated learning cycles.

Why it fails: Refactoring is a key part of the learning and refinement cycle. It keeps the system clean enough to support future increments. By removing it, the management breaks the rhythm of quality that allows for sustainable development. This creates a cycle of decline that hurts the team's overall productivity long-term.

Principle 6: Visualize and limit WIP, reduce batch sizes.

Why it fails: While limiting WIP is a key part of flow, the issue here is the quality of the product, not the volume of work in process. The management's desire for consistent velocity is a misunderstanding of what drives velocity, which is high-quality code and a clean architecture, not just WIP limits.

Principle 10: Organize around value.

Why it fails: Organizing around value refers to the structural alignment of the organization, not the iteration-to-iteration technical tasks. The team is already working; the management error is about the content and nature of that work within the iteration, making this principle irrelevant to the specific complaint about velocity and refactoring.

Principle 5: Base milestones on objective evaluation of working systems.

Why it fails: This principle focuses on measuring progress through objective evidence rather than status reports. While finalizing requirements early might prevent working systems from being tested, the specific act of locking down scope primarily contradicts the need to keep options open for as long as possible during the development lifecycle.

Principle 7: Apply cadence, synchronize with cross-domain planning.

Why it fails: Cadence and synchronization provide a heartbeat for the organization to manage variability. While locking down requirements might disrupt the natural rhythm of planning, the primary issue is the loss of design flexibility, which is specifically addressed by the principle of preserving options for as long as possible.

Principle 9: Decentralize decision-making.

Why it fails: Decentralization involves pushing decisions to those with the local context and competence. While a Product Manager might be centralizing control, the specific violation of freezing requirements is a direct conflict with the need to keep options open. Decision authority is secondary to the architectural strategy of delaying commitment.

To ensure they can micromanage the teams more effectively.

Why it fails: Micromanagement is the opposite of Lean leadership. The goal is to empower teams, not to control them. Training leaders is about helping them shift away from micromanagement toward a servant-leadership model that supports teams and removes obstacles, allowing them to deliver their best work without unnecessary intervention or interference.

To reduce the cost of organizational training.

Why it fails: The cost of training is not the primary concern; the effectiveness of the leadership is. A leader who has attended training but hasn't changed their behavior is an investment that provides no return. The goal is to develop leaders who can drive change, regardless of the direct costs associated with their development.

To provide them with a path to a higher management level.

Why it fails: Leadership development in SAFe is about becoming a better servant leader, not about climbing the corporate ladder. It focuses on how to better serve the teams and the organization, not on individual advancement. A focus on titles and levels is often a sign of a traditional, non-Lean organization.

Principle 1: Take an economic view

Why it fails: This principle focuses on sequencing jobs for maximum benefit and understanding the cost of delay. While poor planning affects economics, the specific act of locking down requirements early primarily conflicts with the need to handle variability, which is the foundational focus of Principle 3 in the Scaled Agile Framework.

Principle 2: Apply systems thinking

Why it fails: Systems thinking encourages optimizing the whole rather than individual silos. While requirements management is part of the system, the specific practice of freezing specifications contradicts the flexibility required to adapt to change. Principle 3 is the more precise match for the avoidance of early commitment to specific product designs.

Principle 9: Decentralize decision-making

Why it fails: Decentralization refers to shifting decision-making authority to those with the local context and expertise. While the Product Manager might be centralizing authority, the core violation here is the rejection of variability. Preserving options is a distinct conceptual requirement that overrides the general preference for decentralized organizational structure in this scenario.

Alignment

Why it fails: Alignment ensures that everyone is working toward the same mission and vision. While important for general coordination, alignment does not directly address the technical practice of managing debt. Teams can be perfectly aligned on a failing, low-quality product strategy if the core value of quality remains ignored by the leadership.

Transparency

Why it fails: Transparency provides visibility into the work and the process. While making technical debt visible is a good first step, it does not inherently solve the trade-off between features and maintenance. Without the commitment to quality, teams may remain transparent about their bad code while continuing to produce even more debt.

Program Execution

Why it fails: Program Execution focuses on achieving the objectives of the Agile Release Train. While a well-executed program relies on quality, focusing solely on execution metrics can often lead to the exact behavior seen here: sacrificing long-term health for short-term completion of backlog items. It is not the specific value that mitigates debt.

Principle 1: Take an economic view

Why it fails: While bottlenecking decisions does have economic consequences like increased cost of delay, the primary failure here is organizational governance. The policy creates a centralized control structure that prevents rapid local decision-making, which is a specific violation of the principle regarding how and where decisions should be made in organizations.

Principle 5: Base milestones on objective evaluation

Why it fails: The policy mentions PI planning, which is a milestone, but the error is not about the evaluation of progress. The issue is the restriction of authority and technical flow. While poor architecture hampers evaluation, the root cause is the centralized control model that denies teams the authority to make technical trade-offs.

Principle 2: Apply systems thinking

Why it fails: Systems thinking focuses on the flow of value through the whole system. While this policy creates a bottleneck, it is specifically a failure of decision-making authority. Decentralizing decision-making is the specific tool SAFe uses to ensure that systems thinking can be applied effectively by the people actually doing the work.

Mandating strict adherence to standard operating procedures without deviation.

Why it fails: Mandating strict adherence ignores the need for innovation and adaptation. True respect involves trusting employees to find better ways to work rather than enforcing rigid, potentially outdated processes. Rigid control systems suppress individual initiative and demonstrate a lack of trust in the team's professional expertise and capability.

Focusing exclusively on individual performance metrics to drive productivity.

Why it fails: Individual metrics often create internal competition and undermine team collaboration. Respect for people and culture emphasizes the collective success of the team over individual achievement. Focusing on individual metrics can damage trust and create a toxic work environment that discourages the collaborative behavior required for successful Agile delivery.

Prioritizing the immediate needs of shareholders over team development.

Why it fails: Prioritizing short-term shareholder gain at the expense of team development is a transactional approach that ignores the value of people. Sustainable success in SAFe requires balancing the needs of all stakeholders, and treating employees as disposable resources leads to burnout and high turnover, which destroys long-term organizational value.

To minimize the number of developers required to finish a project.

Why it fails: Minimizing headcount is not the objective of the economic view. The economic view focuses on value delivery and throughput. Often, increasing investment in the right team can accelerate value delivery, making the total project cost-effective despite higher immediate labor costs. Efficiency is measured by value, not just headcount.

To ensure that all projects are completed exactly on budget.

Why it fails: Strict budget adherence is often a legacy 'waterfall' mindset. SAFe advocates for flow and value-based delivery. If a project requires more investment to capture significant market share, the economic view dictates that the extra spend may be justified. The goal is return on investment, not just budget compliance.

To standardize reporting across all departments for better oversight.

Why it fails: While standardization can be helpful, it is not the goal of an economic approach. The goal is informed decision-making based on financial reality. Reporting is a tool, but the principle is about the underlying logic of prioritization and investment to maximize the long-term viability of the product portfolio.

Milestones are inherently expensive to track and maintain.

Why it fails: The cost of tracking is not the primary issue; the lack of veracity is. Milestones are problematic because they mask the difference between 'completed documentation' and 'working software.' Even if tracking is cheap, if it provides misleading data, it creates a dangerous sense of security that ruins development efforts.

Milestones are only used in large-scale government projects.

Why it fails: This is factually incorrect. Milestones are widely used across all industries, including commercial software development. The rejection of milestones in SAFe is not based on who uses them, but on the fact that they are not a reliable way to gauge progress in an iterative and complex development environment.

Objective evaluation is the only way to satisfy regulatory compliance.

Why it fails: Regulatory compliance can often be handled through traditional documentation. However, SAFe principles advocate for evaluation based on actual system performance to ensure quality. While compliance is important, the core reason for objective evaluation is the need for empirical evidence of progress to make informed business decisions during development.

Strict Change Control

Why it fails: Strict change control is a traditional project management concept that often acts as a barrier to agility. SAFe promotes a culture of managing change through quality and automated feedback loops rather than bureaucratic gatekeeping. It is not, and has never been, a pillar of the SAFe House of Lean.

Standardized Documentation

Why it fails: Documentation is a means to an end, not a pillar of Lean. SAFe prioritizes working software over comprehensive documentation. While documentation serves a purpose in compliance, elevating it to a pillar would contradict the Lean-Agile values that focus on the actual delivery of value and the empowerment of teams.

Optimizing the performance of individual teams for maximum velocity.

Why it fails: Local optimization is a trap. If one team is fast but the downstream team is blocked, the total system throughput does not improve. Systems thinking explicitly warns against this, urging leaders to look at the whole rather than just the productivity of a specific subset of the organization.

Standardizing all development tools across the entire enterprise.

Why it fails: While tool consolidation can have benefits, it is not the primary goal of systems thinking. Systems thinking is about the relationships and processes that create value. Standardizing tools without addressing the underlying workflow and organizational bottlenecks will not significantly improve the ability to deliver value to the customer.

Prioritizing the highest-earning product line at all times.

Why it fails: This is an economic decision, not a systems thinking approach. Systems thinking is about the architecture of the organization and the flow of work. A narrow focus on earnings without considering the health and efficiency of the overall delivery system can lead to technical debt and long-term instability.

To force all teams to use the exact same development tools.

Why it fails: SAFe encourages team autonomy, and forcing identical tools is not the purpose of synchronization. While common tools can help, the synchronization is about the rhythm and the heartbeat of the release train. Teams can use different local tools as long as their output integrates into the system correctly.

To ensure that all teams are working on the same features simultaneously.

Why it fails: Teams work on different features that contribute to the same Program Increments. They are synchronized by the cadence, not by working on identical tasks. This ensures that everyone moves forward together, enabling periodic alignment of architectural and business goals without requiring everyone to perform the same daily work.

To make it easier for management to measure individual performance.

Why it fails: SAFe focuses on team-level performance, not individual metrics. Synchronization is intended to facilitate the flow of value through the train, not to provide management with a tool for micromanagement. Measuring individuals often creates perverse incentives that hurt the overall collaboration required for the release train to succeed.

To allow the team to take a break from all work for two weeks.

Why it fails: The IP iteration is not a vacation. It is a period for high-value activities that don't fit into normal development, such as innovation sprints, training, and planning for the next PI. It is a productive time meant to prepare the team and the system for future success.

To finalize any features that were not completed in the previous iterations.

Why it fails: If a team regularly uses the IP iteration to finish features, they have failed to manage their work correctly during the PI. Using the IP iteration as a 'catch-up' period defeats its purpose of innovation and planning, eventually leading to a breakdown in the planning process itself.

To conduct performance reviews for all team members.

Why it fails: Performance reviews are HR activities and are not the primary purpose of the IP iteration. The IP iteration is focused on the system and the product, not individual career management. While teams might use this time to reflect, it is not an official venue for standard individual performance evaluations.

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.

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.

It slows down development and should be discouraged.

Why it fails: Test-first development actually accelerates development by reducing rework and debugging time. Discouraging it would be a major mistake. The mindset of 'speed through quality' means that investing time in testing early yields significant benefits in the overall throughput and reliability of the software delivery process.

It is an individual practice and not relevant to SAFe principles.

Why it fails: SAFe emphasizes technical practices that improve the entire system, and testing is fundamental to the stability of the program increment. Everything that impacts the quality of the final solution is relevant to SAFe principles. Viewing it as 'just' an individual practice ignores the systemic impact of software quality.

It is only necessary for safety-critical systems.

Why it fails: While critical for safety, test-first development is highly beneficial for all software projects. It reduces debt and increases the team's ability to evolve the system. Limiting such practices to specific industries is a mistake, as all software benefits from the increased clarity and reliability it provides to the team.

Increased team capacity to handle concurrent, unrelated requests.

Why it fails: Limiting WIP does not increase raw capacity; it increases *effective* throughput. Handling too many unrelated requests actually decreases capacity due to context switching. The benefit of limiting WIP is focusing on the most important work, not increasing the number of active tasks the team can handle at once.

A more accurate representation of the team's total workload.

Why it fails: Limiting WIP doesn't change the size of the backlog; it changes the amount of active work. While it makes the team's throughput more predictable, it is not primarily a tracking tool for total backlog volume. The primary benefit is improved flow, not the ability to measure total workload volume.

Elimination of the need for an Agile Release Train.

Why it fails: Limiting WIP is a practice *within* the Agile Release Train; it does not replace the need for it. The train provides the structure for scaling and synchronization, while WIP limits are a tool used to optimize the flow of work within that structure. The two concepts are complementary, not alternatives.

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.

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.

To remove the need for leadership altogether.

Why it fails: Decentralization does not eliminate leadership; it shifts their role from command-and-control to servant leadership. Leaders remain necessary for setting the strategic direction, providing resources, and fostering the environment where decentralized decision-making can thrive. They act as enablers rather than obstacles, supporting the teams in their daily operations.

To ensure all decisions are made by the architect.

Why it fails: Decentralizing decision-making is the opposite of centralizing it under an architect. While an architect provides guidance and vision, specific tactical and technical choices are better handled by the teams themselves. This ensures that the solutions are technically sound and practical, leveraging the specific expertise of the development members.

To prevent teams from making mistakes.

Why it fails: Mistakes are a natural byproduct of learning and innovation. Decentralization does not aim to prevent all mistakes, but rather to ensure that the impact of any mistake is localized. The goal is to enable fast learning through a process of rapid experimentation, failing fast, and adapting accordingly.