Foundations OF Lean practice questions

Change the reporting structure of the external stakeholders.

Why it fails: Organizational restructuring is rarely the fastest way to resolve a process handoff delay.

Ask the team to work on other tasks while waiting.

Why it fails: Context switching adds complexity and reduces efficiency.

Increase the frequency of status reporting emails.

Why it fails: Reporting is non-value-add activity (waste).

Increase the number of testers on the team to match the arrival rate of work items.

Why it fails: Adding testers may temporarily reduce the queue, but it does not address why work waits. Lean seeks to eliminate the cause of delay, not just add capacity. Without changing the process, the queue will likely reappear as demand fluctuates. The team should first understand why testing is a bottleneck before adding resources.

Implement a pull system where testers pull work only when they are ready.

Why it fails: A pull system can prevent overburdening testers, but it does not resolve the fundamental capacity mismatch or the handoff delay. The work will still wait if testers are the only ones who can test. The team needs to broaden the skill set so testing is not a single-person bottleneck.

Reduce the batch size of work items so that each item is smaller and faster to test.

Why it fails: Smaller batches can help, but the primary cause here is the handoff to a specialist tester. Reducing batch size alone will not eliminate the wait if the specialist remains a bottleneck. The team should first address the skill dependency that creates the queue, not just the size of items.

Andon cord

Why it fails: An andon cord stops the line to signal a problem, which improves quality but not queue time. Here the bottleneck is waiting for a specialist, so pulling the cord would not reduce the 18 days of queue; a flow metric is required first.

Standard work

Why it fails: Standard work documents the current best sequence, yet the scenario shows most time is waiting, not variation in task steps. Documenting standard work would not by itself remove the 18-day queue; the team must first quantify and limit WIP.

Poka-yoke

Why it fails: Poka-yoke is mistake-proofing that prevents defects at the source. While valuable, it does not address the dominant queue time in this scenario; the team needs a flow measure, not an error-prevention device, to reduce the 18 days of waiting.

To increase the total number of specialized team members.

Why it fails: Adding specialists enlarges the team rather than removing the transfer points between them; headcount growth does not reduce handoffs. This would fit a scenario where capacity, not flow, is the constraint and additional throughput is genuinely required.

To improve organizational visibility.

Why it fails: Visibility is a by-product, not the goal: fewer handoffs shrink queue and wait time between steps, which is what Lean targets. Visibility tools such as value-stream mapping would be chosen when the aim is exposing flow problems, not when the aim is removing the handoff itself.

To reduce the cost of payroll.

Why it fails: Payroll reduction is a cost outcome, not the flow objective; handoffs cause delay and rework, and Lean removes them to shorten lead time. Cost-cutting would be the aim where labour spend, rather than process flow, is the stated problem.

Performing automated unit tests.

Why it fails: Automated unit tests provide fast feedback that prevents defects reaching later stages, so they reduce rework rather than consume value. It is tempting because running tests takes time and compute, and would be waste only if the tests were redundant, never failing, or duplicating coverage already given elsewhere.

Conducting a sprint demo.

Why it fails: A sprint demo transfers working-increment knowledge to stakeholders and gathers feedback, which is value-generating communication, not Muda. It is tempting because demos occupy team time each sprint, and would count as waste only if it were an unnecessary ceremony with no feedback loop or decision value.

Collaborating on design documents.

Why it fails: Collaborating on design documents builds shared understanding and reduces downstream rework, so it produces value rather than waste. It is tempting because documentation consumes effort, and would be waste only if the documents were never read, duplicated existing material, or were produced for approval theatre rather than decisions.

It has no impact on total cycle time.

Why it fails: A large PMO adds approval queues and wait states between value-adding steps, directly lengthening total cycle time. Lean flow measures the whole value stream, so sequential gate reviews accumulate delay. A PMO suits governance-heavy programmes where compliance outweighs speed.

It improves flow by ensuring high-quality decisions.

Why it fails: Approval gates create batch-and-queue delays rather than continuous flow; quality can be assured through automated checks and smaller batches instead. Lean treats such handoffs as waste. A PMO suits regulated environments where mandatory segregation of duties outweighs cycle-time gains.

It increases technical debt.

Why it fails: Technical debt is a code-quality and maintainability concern, not a flow metric; a PMO approval gate lengthens lead time and queues work, which is what Lean measures. It is tempting because heavyweight governance does often correlate with deferred rework, but that is a separate axis from flow.

Outsource the Testing phase to a third party.

Why it fails: Outsourcing relocates the Testing work without adding capacity at the constraint, so the bottleneck simply shifts to handover and review. It tempts because external teams can absorb overflow, but outsourcing suits capability gaps or cost reduction, not relieving an internal capacity constraint.

Increase the speed of the development phase to clear the backlog faster.

Why it fails: Speeding up development feeds more work into the stalled Testing stage, worsening the queue rather than relieving it. It is tempting because accelerating upstream delivery helps when the constraint lies there, but here the bottleneck sits downstream, so the correct approach targets Testing capacity itself.

Remove the Testing phase from the workflow.

Why it fails: Deleting Testing removes the quality gate entirely, so defects reach production unchecked; the stall disappears only because verification no longer happens. It appeals as a quick way to eliminate the queue, yet removing a stage is valid only when that stage delivers no value, which testing plainly does.

Respect People.

Why it fails: Respect People concerns culture, empowerment and treating colleagues as professionals, not defect prevention in delivered code. It is tempting because rework frustrates teams and erodes morale, but the 30% defect-fixing time directly violates Build Quality In, which demands defects be caught before delivery.

Optimize the Whole.

Why it fails: Optimize the Whole addresses subordinating local optimisations to end-to-end value stream flow, not defect rework itself. It is tempting because rework consumes capacity across the whole delivery system, but the specific violation is Build Quality In, since defects escaped into delivered code instead of being prevented.

Deliver Fast.

Why it fails: Deliver Fast concerns shortening lead time from request to release, not defect rework in delivered code. It is tempting because slow delivery and accumulated defects often co-occur, but the 30% rework directly violates Build Quality In, which requires preventing defects rather than fixing them after delivery.

Host more frequent brainstorming meetings.

Why it fails: Brainstorming meetings add calendar load and context switches rather than reducing them, and generate ideas instead of constraining concurrent work. It tempts teams that treat waste discovery as a discussion exercise. Limiting work in progress caps simultaneous tasks, which is the mechanism that eliminates switching.

Assign a dedicated task-manager to monitor progress.

Why it fails: A dedicated task-manager adds a coordination role and reporting overhead without removing the interruptions that cause task switching; monitoring progress does not limit work in progress. It appeals where visibility is genuinely lacking. Limiting work in progress is the Lean practice that directly curbs switching.

Rotate team members daily to ensure skill diversity.

Why it fails: Daily rotation deliberately forces each person to change context every day, multiplying the switching the team is trying to remove, and it fragments ownership. It appeals where cross-training is a genuine goal. Limiting work in progress keeps people on fewer tasks at once, which is what reduces switching.

Require developers to work overtime to clear the backlog.

Why it fails: Overtime adds capacity to push work through, which masks the congestion's cause and typically raises defect rates and WIP further. The stem asks for a technique to identify the primary cause, such as value-stream mapping or root-cause analysis. Overtime is tempting as a quick relief valve, but it treats the symptom.

Increase the team size to handle the overflow.

Why it fails: Adding people increases WIP and coordination overhead, worsening the congestion rather than revealing its cause. The stem asks for a technique to identify the primary cause, such as value-stream mapping or a root-cause analysis. Larger teams are tempting because capacity feels like the fix, but Brooks's law and queueing effects apply.

Implement a mandatory daily stand-up meeting extension.

Why it fails: Extending stand-ups adds reporting time without exposing where work queues or blocks; it changes no flow mechanism. Identifying the primary cause of high WIP requires value-stream mapping or root-cause analysis to locate the constraint. The extension is tempting because stand-ups surface blockers, but discussion alone does not diagnose the system.

Identifying bottlenecks in the production pipeline.

Why it fails: Identifying bottlenecks supports Optimize the Whole by revealing where flow is constrained across the system. The principle warns against optimising individual silos at the expense of end-to-end throughput. Bottleneck analysis is the correct technique when deciding which constraint to relieve first to raise overall delivery capacity.

Aligning team goals with organizational objectives.

Why it fails: Aligning team goals with organisational objectives is central to Optimize the Whole, because it prevents sub-optimisation where one team's local gains harm overall value delivery. Avoid instead metrics that reward a single function in isolation. Goal alignment is correct when multiple teams must pull toward a shared outcome.

Analyzing the end-to-end value stream.

Why it fails: Analyzing the end-to-end value stream is precisely what Optimize the Whole requires, since it exposes cross-team delays and handoff waste. Avoid instead local optimisations that improve one stage while degrading overall flow. Value-stream mapping would be the right choice when diagnosing where value is lost across the full delivery pipeline.

The specific team member assigned to each ticket.

Why it fails: A CFD plots work items in each workflow state over time, so it carries no assignee data at all; ticket ownership sits in the board or issue tracker. It is tempting because CFDs do expose per-column ageing, which teams sometimes read as individual workload, but the diagram aggregates counts by state, not by person.

The total budget remaining for the project.

Why it fails: A CFD tracks the quantity of work items in each workflow state across time, exposing flow, WIP and cycle time; it holds no financial data. It is tempting because cumulative lines resemble burn-up charts used for scope and budget tracking, but those are separate artefacts with cost axes.

Individual team member performance.

Why it fails: A CFD aggregates counts of items per workflow state over time, so it cannot attribute throughput or cycle time to named individuals. It is tempting because column ageing hints at where work stalls, which managers misread as personal productivity; per-person metrics belong in dedicated reports, not the CFD.

More time to attend meetings.

Why it fails: Small batches shorten feedback cycles and reduce work in progress, not meeting attendance; meetings are unaffected by batch size. It is tempting because reduced batch size can free calendar time, but that is a side effect, not the primary benefit, which is faster validated learning and lower risk per release.

Lower total cost of labor.

Why it fails: Small batches do not lower total labour cost; they often increase transaction overhead per unit of work. It is tempting because less work in progress appears cheaper, but the primary benefit is faster feedback and reduced risk, not cost reduction, which typically comes from eliminating rework rather than batch sizing.

Less documentation required.

Why it fails: Small batch sizes reduce the scope of each change, so documentation volume is unaffected — a small release still needs the same design records, test evidence and release notes as a large one. It tempts because lighter governance is genuinely achievable under continuous delivery, where automated pipelines replace manual approval artefacts, not because batches shrank.

Eliminating all meetings.

Why it fails: Meetings are not the mechanism that releases work in a pull system; the prerequisite is a defined downstream demand signal that authorises upstream production. Eliminating meetings tempts because it sounds like removing overhead, and it would be correct if the goal were reducing coordination waste rather than establishing pull.

Moving to a cloud-based development environment.

Why it fails: Cloud-based development changes where code is built, not how work is released or pulled. It tempts because cloud tooling often accompanies DevOps, but Pull requires a decoupled deployment pipeline with automated testing and on-demand releases, achievable on-premises.

Hiring more experienced team members.

Why it fails: Experienced staff do not create the pull signal; a pull system is triggered by downstream consumption, so headcount is irrelevant to the prerequisite. It tempts because skilled people help teams adopt new workflows, and hiring would be a valid response if the constraint were capability rather than the absence of a defined demand trigger.

Having a very small backlog.

Why it fails: A small backlog smooths flow and exposes problems; it does not create the wait states, rework or uneven arrival rates that drive cycle-time variance. It is tempting because limiting work in progress is a core Lean practise, and a deliberately small backlog is correct when you want to shorten lead time and surface bottlenecks.

The use of an electronic board.

Why it fails: An electronic board is a tool for visualising flow; it does not itself create variability, and physical or digital boards can both support stable cycle time. It is tempting when teams blame tooling for process problems, but Lean attributes variable cycle time to uneven flow, such as varying work item sizes or batch sizes.

Too many team members.

Why it fails: Team size alone does not cause variable cycle time; Lean attributes variability to uneven flow, such as inconsistent work item sizes, unplanned work or bottlenecks. It is tempting because large teams can feel chaotic, but a well-managed larger team can still deliver predictable cycle time.

It reduces lead time by keeping developers productive.

Why it fails: Gold plating lengthens lead time by adding unrequested work, rework and review cycles to the value stream, so it cannot reduce it. It is tempting because developers appear busy and productive, but that activity is queue and defect waste rather than flow, which is why it is the correct choice only when measuring utilisation, not delivery.

It has no impact on the value stream.

Why it fails: Gold plating injects unrequested features, expanding scope and adding review, test and rework steps that lengthen the value stream. It is tempting because the extra work can appear invisible to flow metrics, but it demonstrably increases lead time and defect rates, so no impact is factually wrong.

It improves the overall quality of the product.

Why it fails: Gold plating adds unrequested functionality that increases defect surface, test burden and rework, so it lowers delivered quality rather than improving it. It is tempting because extra features can look like added value, but quality here means fitness for purpose and freedom from defects, not feature count.

To allow stakeholders to change their minds frequently.

Why it fails: Deferring commitment keeps options open so decisions rest on the best available information, not to license arbitrary stakeholder flip-flopping. It is tempting because late decisions do accommodate change, but the motivation is preserving flexibility, not encouraging indecision.

To keep the team busy with administrative work.

Why it fails: Deferring commitment preserves optionality so decisions are made with maximum knowledge, not to occupy the team with administrative tasks. It is tempting because Lean values flow and utilisation, but the mechanism is delaying irreversible choices, not generating busywork.

To save money on project overhead.

Why it fails: Deferring commitment preserves the ability to incorporate new information and avoid rework, not to reduce overhead spending. It is tempting because Lean does eliminate waste, but the mechanism is keeping options open, not cutting project costs.

Remove the blocked items from the board.

Why it fails: Deleting blocked items hides the impediment rather than resolving it, so the underlying dependency or defect persists and the work is lost from tracking. Removing items suits genuine scope cancellation or duplicate entries, where the work is no longer required at all.

Wait until the next daily stand-up to discuss the blocks.

Why it fails: Blocked items stall flow immediately, so escalation should happen as soon as the block is raised, not deferred to a scheduled ceremony. Daily stand-ups suit coordination and progress sync, but waiting leaves the impediment unresolved for hours, inflating cycle time and WIP ageing.

Start new work to keep the developers busy.

Why it fails: Pulling new work increases WIP while blocked items remain unresolved, worsening flow and delaying the original commitments. Starting new work suits a pull system with spare capacity and no blocked items, where the board shows genuine availability rather than hidden impediments.

The team's office lighting.

Why it fails: Lighting does not affect cycle time, which measures elapsed flow duration from work start to completion. Investigating the environment would be relevant for defect or wellbeing concerns, but rising cycle time with constant workload points to queueing, work-in-progress limits, blockers, or handoff delays in the workflow.

The number of coffee breaks taken.

Why it fails: Coffee breaks do not alter the elapsed time a work item spends in the workflow; cycle time rises from queueing, work-in-progress limits or blockers, not rest patterns. It is tempting because morale and fatigue can affect throughput, so break policy would be worth examining when investigating productivity or capacity, not cycle time.

The team's motivation level.

Why it fails: Motivation does not change the elapsed time a work item takes from start to finish; cycle time increases come from queueing, WIP limits, handoffs or blockers. Motivation is tempting because it plausibly influences throughput and quality, making it relevant when diagnosing declining delivery rate or team performance rather than cycle time itself.

The number of tasks completed in a sprint.

Why it fails: Tasks completed measure throughput, not value; Lean defines value from the customer's perspective, and completing tasks can produce waste. It is tempting because sprint metrics are visible and familiar, and would be correct for measuring team velocity or predictability.

The total effort hours spent by the team.

Why it fails: Effort hours measure cost and capacity, not what a customer would pay for; Lean defines value as what the customer wants, delivered right first time. It is tempting because tracking effort feels like measuring worth, and would be correct for capacity planning or cost-of-delay calculations.

The number of lines of code written.

Why it fails: Lines of code measure output volume, not customer value; Lean treats code as inventory and waste until it delivers something the customer needs. It is tempting because output is easy to count, and would be correct for tracking development throughput rather than value.