CASM common mistakes
CASM · Understand the traps and how to avoid them.
Treating 'agile' and 'Lean' as interchangeable labels and answering questions about muda, value, and flow with Scrum ceremony vocabulary (sprints, backlog grooming, retrospectives).
Candidates prepare from Scrum-heavy material and never separate the Lean lineage (value, waste, flow, pull, kaizen) from the agile-manifesto lineage, so they pattern-match on the word 'agile' in the stem rather than on the concept being tested.
What to do instead
Build a two-column glossary before studying anything else: Lean terms (value, value stream, waste/muda, flow, pull, takt, kaizen) versus agile service terms (iterative delivery, cross-functional teams, customer collaboration). For each practice, write one sentence naming which lineage it comes from and what problem it solves.
Answering 'the team decides' or 'the team self-organizes' for any question involving governance, risk acceptance, or compliance sign-off.
Candidates over-learn the self-organization principle and apply it as a universal answer, missing that accountability for risk appetite and regulatory obligation stays with the organization even when delivery authority is delegated.
What to do instead
Learn the delegation boundary explicitly: teams own how work is done; the organization owns what risk is acceptable and which obligations are non-negotiable. Practice classifying scenarios as 'team decision', 'shared decision', or 'organizational accountability' and justify each with the consequence of getting it wrong.
Describing a value stream map as a process flowchart with steps and owners, omitting lead time, process time, percent complete and accurate, and queue/wait time between steps.
Candidates have drawn swimlane process maps in operations work and reuse that habit; they also skip the data boxes because collecting timestamps feels like extra effort in a written exam scenario.
What to do instead
Memorize the minimum viable value stream map: for each step record process time, lead time (including wait), percent complete and accurate, and the resource. Then compute flow efficiency as process time divided by total lead time. Practice on a five-step scenario until the numbers, not the boxes, are what you instinctively look for.
Choosing 'add more people' or 'work overtime' as the remedy for a flow problem, or treating a full kanban board as evidence of high productivity.
Throughput intuition from traditional project management says more capacity equals more output; candidates miss that queues, batch size, and variability - not headcount - usually govern cycle time, and that a board full of work in progress hides delay.
What to do instead
Learn Little's Law (average cycle time equals work in progress divided by throughput) and use it to test answer options numerically. Drill the levers in order: limit WIP, reduce batch size, manage variability, then add capacity. Reject any option that raises WIP without a stated constraint change.
Confusing a service level objective with a service level agreement, or answering that SLAs should simply be abolished in agile delivery.
The three terms (SLI, SLO, SLA) are used loosely in vendor material, and candidates swing to an ideological 'agreements are anti-agile' position instead of the operational one: measure internally, target internally, then commit externally only where the customer needs it.
What to do instead
Fix the chain in memory: indicator is what you measure, objective is the internal target, agreement is the external commitment with consequence. For any scenario, first ask 'who is the audience and is there a consequence for breach?' - that determines which of the three is being asked about.
Treating change enablement as change approval, and answering that a change advisory board must review every change to satisfy control requirements.
Candidates carry ITIL-era mental models where a CAB is the control point, and they assume auditors require pre-approval of each change rather than evidence that risk was assessed and authorized at the right level.
What to do instead
Reframe change enablement as risk-proportionate authorization: standard/pre-authorized, normal with tiered approval by risk, and emergency with retrospective review. Learn to justify automated pipelines as control evidence (tests, peer review, deployment logs). For each scenario, ask what could go wrong and who must accept that risk - not who must attend a meeting.
Giving a generic 'culture eats strategy' answer to DevOps culture questions instead of naming concrete behaviours such as blameless post-incident review, shared ownership of production, and psychological safety to raise problems.
Culture questions feel unanswerable, so candidates retreat to slogans; they also underweight that exam stems usually describe a specific behaviour and ask what it produces or replaces.
What to do instead
Prepare five named culture mechanisms with their anti-patterns: blameless postmortems versus blame; shared on-call versus throw-it-over-the-wall; small batch integration versus long-lived branches; error budget conversations versus fear of change; leaders modelling transparency versus metrics used as weapons. Match the mechanism in the stem to its outcome.
Designing a metrics answer around individual utilization, velocity comparisons between teams, or story points per developer.
These numbers are easy to collect and appear in tooling dashboards, so candidates default to them; they miss that such measures reward local optimization and are explicitly counterproductive for flow and collaboration.
What to do instead
Adopt a three-tier metric frame: delivery outcomes (lead time, deployment frequency, change failure rate, time to restore), flow health (WIP, cycle time distribution, blocked time), and system capability (escaped defects, reliability against objectives). For any proposed metric, ask 'what behaviour does this incentivize if it becomes a target?' and discard those that reward individual output.
Jumping to a target-state operating model in an organizational readiness scenario, skipping the current-state assessment, stakeholder mapping, and pilot scoping.
Candidates want to demonstrate knowledge of the destination and treat the journey as filler; they also underestimate resistance and assume a mandate is sufficient to create change.
What to do instead
Learn a repeatable sequence and apply it to every transformation scenario: establish why and baseline the current state, map stakeholders and their interests, choose a thin slice with visible value, run it as a pilot with explicit measures, then expand with the lessons. If an answer option starts at 'restructure the organization', it is almost always premature.
Writing requirements as solution specifications ('the portal shall have a dropdown of regions') rather than as outcomes with acceptance criteria, and then failing questions that test the difference.
Decades of specification-writing habits and template-driven templates push candidates toward prescriptive language; they also conflate a user story with its acceptance criteria and omit the conversation that resolves ambiguity.
What to do instead
Practice rewriting specifications into the form: role, goal, reason, plus testable acceptance criteria and explicit out-of-scope notes. For each rewritten item, verify it states a need and not a mechanism, and that a tester could pass or fail it. Do ten rewrites; the pattern becomes automatic.