KSD common mistakes
KSD · Understand the traps and how to avoid them.
When asked what a service is for, the candidate answers with the team's activities ("we build and run the payment platform") or with an org chart, rather than stating the customer, the need served, and the outcome the service exists to produce.
Candidates memorise tool vocabulary (Kanban, WIP, STATIK) and treat the 'purpose' question as an easy warm-up, so they answer from inside the team's perspective. Internal-facing language feels safe and concrete, while customer-outcome language feels vague and risky to commit to.
What to do instead
Before answering, force the sentence 'This service exists so that can , and we would know it worked if .' Practise writing purpose statements for three services you know and check each against the test: does it name who is served, what changes for them, and how you would tell? If any of the three is missing, rewrite it until it is present.
The candidate treats policies as universal rules applied to all work items equally (one WIP limit for everything, one expedite path anyone can invoke), instead of defining explicit policies per class of service and stating who may change them.
Real teams often have implicit, uniform habits, and candidates generalise from that experience. They also confuse 'having a policy' with 'having a policy that is explicit, visible, and differentiated by risk and cost of delay'.
What to do instead
For each class of service you mention (standard, fixed date, expedite, intangible), write the four policy lines: entry criteria, WIP limit or capacity allocation, pull/selection rule, and exit/replenishment rule. Then state who authorises expedites and what the cap is. In exam answers, name the class before you name the rule.
When asked to improve a workflow, the candidate proposes a change without first identifying the feedback loop or flow signal that motivated it, and without stating what evidence would show the change worked.
Improvement questions invite solution-shaped answers, and candidates rush to the intervention (add a WIP limit, split the team, add a review step) because it sounds decisive. The habit of naming the signal and the expected effect is the part that gets skipped under time pressure.
What to do instead
Use a fixed four-part answer: observed signal (with the metric and the time window), hypothesis about the cause, the single experiment, and the signal you will watch to decide keep/adapt/revert. Practise saying 'the cycle time scatterplot widened at the 85th percentile over the last six weeks' rather than 'cycle time is bad'.
The candidate optimises a visible local step (a busy specialist, a full design queue, high utilisation in one column) while ignoring upstream arrival patterns and downstream consumption, and presents the local improvement as a system improvement.
Local efficiency is intuitive and easy to measure, and candidates are usually rewarded at work for keeping their own area busy. Seeing the whole system requires deliberately reasoning about queues, variability, and the bottleneck's position, which is harder to do out loud.
What to do instead
Before recommending anything, draw the end-to-end flow with arrival rate, WIP, and throughput at each stage, then locate the constraint. State explicitly what happens upstream and downstream if the local change is made. If you cannot say which stage constrains throughput, say so and describe how you would find out rather than guessing.
The candidate describes STATIK as a sequence of steps to recite (nine steps, in order) but cannot explain why the order matters or what each step produces as an artefact, and cannot adapt it when the class of service or the system boundary changes.
STATIK is easy to memorise as a list and easy to fail as a method. Candidates learn the labels without the dependencies between them, so they cannot answer 'what would you do if the demand analysis contradicted the purpose statement?'
What to do instead
Learn STATIK as a chain of artefacts: purpose, sources of dissatisfaction, demand, capability of the system, work-in-progress, classes of service, policies, commitment point, delivery point, and the resulting model. For each, be able to say what it feeds and what would make you revisit it. Practise running it for a service with mixed demand and one with a single dominant class.
The candidate draws a board with columns and WIP limits but never states the commitment point and the delivery point, so the board cannot answer 'how much work is in progress' or 'when did the clock start'.
Board design gets attention as a visual layout exercise, and the two markers that make a board meaningful are invisible in most screenshots candidates have seen. Without them, cycle time has no defined start and finish and the WIP numbers are ambiguous.
What to do instead
On every board you describe, mark the commitment point (where a work item enters the counted system) and the delivery point (where the customer receives value), and say what is counted between them. Check that the WIP limit applies to the counted region, not to the whole board, and that items before the commitment point are treated as options, not commitments.
The candidate says 'use pull' as a slogan and then describes a push system in practice: assigning work to people at a stand-up, pre-filling queues to keep everyone busy, or setting WIP limits so high that they never bind.
Pull is conceptually simple but operationally demanding, and many candidates work in organisations where assignment is normal. They reproduce the language of pull while describing the mechanics of push, and they do not test whether their WIP limit actually constrains anything.
What to do instead
Describe the pull trigger explicitly: who signals capacity, what they signal, and what they are allowed to pull. Then stress-test your own answer: if the limit is never reached, it is not a limit; if a manager assigns the next item, it is not pull. Say what happens when the limit is hit, including who waits and for how long.
The candidate treats capacity as a headcount calculation (people times hours) and ignores variability, unplanned work, and the cost of context switching, so the capacity policy is not credible against observed throughput.
Effort-based capacity is the default mental model from project planning, and it produces a tidy number that feels defensible. Candidates rarely reconcile that number with historical throughput, so the mismatch with real delivery is never surfaced.
What to do instead
Derive capacity from observed throughput over a recent window and state the variability, then subtract a declared allocation for unplanned and expedite work. Present capacity as a range with a confidence statement, and say how you would revise it when the mix of classes of service changes.
The candidate answers a 'what would you do next' question with a list of several simultaneous initiatives, rather than one experiment with a clear expected effect and a decision rule.
Candidates want to show breadth of knowledge and fear that a single experiment looks thin. The result is an unfalsifiable bundle in which no individual change can be evaluated, which is the opposite of the improve discipline being tested.
What to do instead
Commit to one change, state the hypothesis and the metric, and give the decision rule in advance (for example, if the 85th percentile cycle time does not fall within three weeks, revert). Mention the other ideas only as a backlog that waits for the first result.
The candidate defines classes of service by work type or department (marketing requests, engineering requests) instead of by the risk and cost of delay that determine how the item should be treated.
Organisational categories are familiar and easy to list, while cost of delay requires judgement about consequences. Candidates default to the taxonomy they see at work rather than the one the method requires.
What to do instead
For each proposed class, state the cost-of-delay profile and the policy consequence: how it enters, what WIP allocation it gets, and what rule selects it. If two classes would receive identical policies, merge them; if a department label hides two different cost-of-delay profiles, split it.