| Aspects | Description | L1 STARTING | L2 PRACTICING | L3 SYSTEMATIC | L4 MEASURING | L5 INNOVATING | Evidence Type | Evidence | Scoring Results |
|---|---|---|---|---|---|---|---|---|---|
| Visualize |
- Visualization of workflow or policies does not exist. - Visualization of work is limited to basic work item information on the tickets. |
- The work carried out is visualized on a Kanban board. - Basic team policies are immediately visible to people who use the Kanban Board |
- Defined workflow is visualized using a Kanban board - Blocked work items, defects and rework are visualized on the Kanban board - Work item aging is visualized |
L1-L5 |
- L1 - L2 - L3 - L4 - L5 - Skipped |
||||
| Limit Work in Progress | - No Work In Progress (WIP) limits are defined OR Some WIP limits are defined, but are not always followed. |
- Work In Progress (WIP) limits are established for at least one activity. - WIP limits are adhered most of the time. |
- Work In Progress (WIP) limits are established for At least 80% of activities. - WIP limits are adhered to all the time. |
Activity-based Work In Progress (WIP) limits are defined for all, 100% of activities on the board. |
L1-L5 |
- L1 - L2 - L3 - L4 - L5 - Skipped |
|||
| Manage Flow |
- Work Item categorization in place but not necessarily follows a process. - Upstream & downstream flows are not mapped - Flow-related data (Lead Time) is not collected |
- Work Item categorization in place based on the nature of the work, urgency, importance, and/or impact - Upstream & downstream flows are identified and documented - Flow-related data (Lead Time) is collected |
- Defects and other rework items are managed: they are tracked, reasons for them are recorded, rework item's state is tracked - Actions to reduce defects and rework items are defined, documented and executed |
- For defects and other rework items related, data is analyzed and documented according to defined explicit policies to identify root causes and best action items to reduce impact of such items on the flow of work |
L1-L5 |
- L1 - L2 - L3 - L4 - L5 - Skipped |
|||
| Make Policies Explicit |
- There are no explicit policies defined - There are no written rules that define the process execution and govern the behavior of individuals and teams |
- Flow-related metrics are defined and a process to collect it is documented |
- The basic service policies are defined and documented (service description, criteria to determine the urgency of a work item, requirements to the service delivery, cadence for the service replenishment meeting) - Basic policies for dependency management are defined (the points of hand-offs between service teams are identified, basic policies for hand-offs are agreed to) - Policies for managing defects & rework items are established, i.e. it is defined how rework is visualized and handled |
- Policies for managing defects and other rework items include definitions on what data about such items is collected, what analysis must be done and by whom |
L1-L5 |
- L1 - L2 - L3 - L4 - L5 - Skipped |
|||
| Establish Feedback Loop |
- Team Kanban Meeting is not held on a regular daily basis - Team Kanban Meeting is held, but status of work, impediments in the workflow and problems in the process are not discussed and appropriate action items are not defined |
- Team Kanban meeting is held on daily basis with the board - The board is walked from right to left - Each work item is present on the board and the status of each ticket is reported - Possible delays, blockers, tech. problems, lack of information, etc. are discussed - Appropriate action items are defined |
- Team Replenishment meetings are conducted on regular basis - Work items are selected and moved to "Next-to-Start" column, so that the squad does not run out of work before the next Replenishment meeting - Workflow Kanban meeting is conducted on regular basis using Kanban board |
L1-L5 |
- L1 - L2 - L3 - L4 - L5 - Skipped |
||||
| Improve Collaboratively, Evolve Experimentally |
- Continuous improvement activities are not observed - Improvements actions are not suggested by the squad members |
- Squad identifies internal sources of dissatisfaction, i.e. what prevents the team and individuals from delivering professional results and meeting customers expectations - Squad defines appropriate actions for addressing sources of dissatisfaction |
- Explicit policies are revised on regular basis, updated and documented based on outcomes of Squad Retrospectives, identified sources of dissatisfaction, analysis of causes for delays |
- Squad identifies sources of delay by listing all work items, services, or projects that were delayed for a meaningful period of time defined by the squad in the respective policy, causes for blockades are identified and clustered - Squad decides and documents which causes of delay are addressed and how |
L1-L5 |
- L1 - L2 - L3 - L4 - L5 - Skipped |
- The first iteration of KCMM is designed for application at the squad level. Although some aspects might be capable of being applicable at the Tribe level and higher.
- Kanban CMM Diagnostic is based on the Kanban Maturity Model (KMM- Kanban Maturity Model). Kanban CMM Diagnostic does not cover all aspects of the Kanban Maturity Model.