KCP common mistakes
KCP · Understand the traps and how to avoid them.
Treating the Kanban Maturity Model's seven levels as a simple ladder where a team must fully complete each level before touching anything from the next one, and answering scenario questions with a single rigid level number instead of describing the practices the situation actually shows.
Candidates memorize the level names (ML0–ML6) and their headline labels from a summary table, then apply them as a checklist. The model is diagnostic: organizations show a mix of practices, and maturity is about fitness for purpose and the depth of practices in use, not a staircase with locked gates.
What to do instead
For each level, learn the defining practices and the typical problems it solves (for example, ML1 focuses on making work visible and limiting work in progress at the team level, while higher levels address service delivery, portfolio, and enterprise concerns). Practice classifying short case descriptions by citing the specific practices present and absent, and state the level as a range with justification rather than a single number.
Confusing the KMM's maturity levels with the Kanban Method's change-management stages (the STATIK or 'get started, then improve' progression) and giving a level number when the question asks about a change approach, or vice versa.
Both frameworks use staged language and are often taught together, so candidates blur 'where the organization is' with 'how we are rolling out change'. Exam questions frequently probe exactly this distinction.
What to do instead
Build a two-column comparison: one column for KMM levels (what practices and behaviors exist in the organization) and one for change stages (how the coach sequences introduction and evolution of practices). For every practice question, first ask 'is this asking about current state or about the intervention?' before choosing an answer.
Assuming higher maturity is always the right answer, and recommending ML4–ML6 practices such as enterprise-level portfolio management or advanced metrics to a team that has not yet made its work visible or established flow.
Candidates equate 'mature' with 'good' and pick the most sophisticated-sounding option. The KMM explicitly warns against introducing practices the organization is not ready for; unfitness causes regression and disengagement.
What to do instead
Learn to match the intervention to the current level: stabilize visibility and WIP limits first, then flow and service delivery, then enterprise concerns. On scenario questions, identify the organization's actual symptoms and choose the practice that addresses the next constraint, not the most advanced one. Be ready to explain why jumping levels fails.
Memorizing the seven kanban practices as a list but failing to connect each practice to the maturity level and context where it becomes meaningful, so answers about 'which practice is missing' are guesses.
The practices (visualize, limit WIP, manage flow, make policies explicit, implement feedback loops, manage risk, improve collaboratively) are learned as a flat list, and the exam tests whether the candidate knows how they deepen across levels.
What to do instead
Create a matrix of practice against level and write, for each cell, one concrete observable behavior (for example, what 'make policies explicit' looks like at an early team level versus at a service-delivery level). Test yourself by reading a scenario and naming the practice and the depth expected at that level.
Answering questions about the KMM's assessment and fitness-for-purpose concepts with generic agile language ('inspect and adapt', 'continuous improvement') instead of the model's specific vocabulary about customer satisfaction, business outcomes, and organizational agility.
Candidates fall back on familiar agile slogans when they are unsure, and those options are usually present as distractors because they sound plausible.
What to do instead
Study the KMM's stated goals and the dimensions it assesses, and practice writing one-sentence definitions in your own words for each. When an answer option is a generic slogan, treat it as suspect unless it is tied to a specific KMM concept or observable practice.
Giving coaching advice as instructions ('tell the team to add a WIP limit') rather than as questions and experiments that help the team discover the need, and selecting those directive answers on scenario questions.
Candidates know the 'right' kanban practice and want to prescribe it. Kanban coaching emphasizes pull-based change, respect for current roles, and helping people see their system; directive answers often violate the coaching stance the exam is testing.
What to do instead
Practice rewriting every recommendation as a coaching move: a question, a data request, an experiment with a hypothesis and review date. Learn the distinction between teaching, mentoring, facilitating, and coaching, and match the intervention to the coachee's readiness rather than to your own expertise.
Ignoring the change-management and stakeholder side of coaching-sponsorship, resistance, middle management-and answering purely with technical kanban mechanics when the scenario is about adoption failing.
Technical candidates over-index on boards, metrics, and policies, and under-weight the political and social system. Exam scenarios often describe resistance or lack of sponsorship and expect a coaching response that addresses it.
What to do instead
For each scenario, explicitly identify the stakeholders, their interests, and the sponsor. Learn to design a change approach that starts with what people already do, invites volunteers, and makes the case through evidence rather than mandate. Practice answering 'who needs to be involved and what would convince them?' before 'what practice do we add?'
Treating metrics as reporting tools for management and recommending velocity-style or individual-performance measures, rather than flow metrics used by the team to improve its own system.
Candidates carry habits from other frameworks and from management pressure, and the exam tests whether the coach understands metrics as a feedback mechanism owned by the team.
What to do instead
Learn the flow metrics (lead time, cycle time, throughput, work item age, WIP) and what decision each supports. Practice distinguishing diagnostic use from judgmental use, and be able to explain how to introduce metrics so they are not experienced as surveillance-for example, starting with data the team itself wants.
Confusing the coach's role with the service manager's or the team's manager's role, and choosing answers where the coach makes decisions, assigns work, or owns the board.
In real organizations coaches are often given authority, and candidates project that experience onto the exam. Coaching answers should build capability in others and keep ownership with the team and its existing management structure.
What to do instead
Study the coaching contract: who owns what, what the coach is accountable for, and how the coach exits. For each answer option, ask 'does this build the team's capability or create dependence on the coach?' Prefer options that transfer ownership and make the team's own decisions visible.
Skipping the feedback-loop and cadence design questions-meeting structures, review points, and how cadences connect across teams-and answering with a single generic 'retrospective' response.
Candidates treat feedback loops as a soft topic and underestimate how specifically the exam tests cadence design, including how team, service, and business cadences align and what each meeting's purpose is.
What to do instead
Map each feedback loop to its purpose, participants, inputs, and outputs, and practice designing a cadence for a described organization, including where loops are missing or misaligned. Be able to explain the consequence of a missing loop (for example, decisions made without flow data) rather than just naming the meeting.