Audit-Proof Kanban at MedAxis
MedAxis develops infusion-pump firmware under IEC 62304 and FDA design controls. Six firmware teams tried Kanban 14 months ago and abandoned it after an audit: the auditor could not trace how a board card satisfied design inputs, review records lived in a separate document system, and phase sign-offs were recorded in a spreadsheet outside the board. Management concluded that Kanban does not fit regulated work.
The quality team now requires phase-gate approvals at requirements, design, implementation, and verification. Each gate has mandatory artifacts and two named approvers. Average gate wait is nine days, and there are 40 open review requests. Teams want to restart Kanban; QA is willing to talk but fears losing audit evidence. The VP of Engineering has asked you to help make Kanban audit-proof in one product line before the next surveillance audit in five months.
1. How do you frame the problem using the Kanban Maturity Model, and what does fit for purpose mean here?
Read the worked answer
The previous failure was not a conflict between Kanban and regulation; it was a failure of explicit policy and enterprise fit. At ML3 the test is whether the workflow, policies, and feedback loops reflect the real work and its risks. For MedAxis, design controls are part of the work, and a phase gate is a policy with entry criteria, exit criteria, approvers, and a queue.
KMM reasoning: the teams had boards but not explicit policies - the gate existed outside the board, so the board could not be a control system. Review records lived elsewhere without a defined relationship to the card, and the nine-day gate wait was invisible as a flow problem. That is a lower-level fitness gap showing up as an audit finding. Installing a more elaborate board without fixing policy would repeat the failure.
Fit for purpose here means the board shows the regulatory path: requirements, design, implementation, verification, with the required artifacts, approvers, and evidence links at each boundary. The 40 open review requests and nine-day wait become a service delivery problem owned jointly by QA and engineering, with WIP limits and SLEs, rather than an unavoidable cost. I would present this to the VP as a redesign of the control system, not a repackaging of Kanban. The audit is a stakeholder with legitimate requirements.
2. What would you co-design with QA so that the board produces acceptable audit evidence?
Read the worked answer
Co-design, not consultation after the fact. I would convene a working group with QA, one team's engineers and lead, the document control owner, and someone who has prepared for an FDA audit. The output is a policy set that both QA and the teams sign.
Sequence: first, map every column boundary to the required artifact and approver - for example, the exit from requirements must have a reviewed, approved requirement set with traceability identifiers. Second, define what constitutes a record: who acted, when, on which version, with what approval, and where it is retained. The board can visualize and link to the record without being the system of record, unless the tool has a validated audit trail. Third, define the queue policies: review WIP limits, named reviewers, SLE for gate decisions, and an escalation path when the SLE is breached. Fourth, define classes of service for different change types - safety-critical, documentation-only, defect - with proportionate paths, so not every card carries the same weight.
Then pilot on one product line: run a dry audit against the board and the linked records, with QA acting as auditor. Fix the gaps before the surveillance audit. Throughout, coach QA as a co-designer with legitimate risk concerns, and coach the team to see the gate as a service with a policy rather than an obstacle. The policy must be visible, version-controlled, and reviewed when it fails.
3. The VP wants the board to also serve as the audit record, replacing the spreadsheet. What are the risks and what do you advise?
Read the worked answer
The instinct is understandable and risky. Replacing the spreadsheet with the board is a tooling decision presented as a simplification, but the spreadsheet likely exists because approvals need named identities, dates, and retention that the board does not natively provide. If the board becomes the claimed system of record without those properties, the next audit finding will be worse than the first, because the organization will have removed its evidence.
I would advise separating two questions: what does the regulation require as evidence, and what is the best way to produce and retain it? The board's job is to make the work and its queues visible and to link to evidence. The validated system of record keeps the approvals unless the board tool can demonstrate audit trail, access control, electronic signatures where required, and retention.
Sequencing matters: policy and evidence mapping first, tooling second. If the VP wants a single view, propose a linked view - card shows status, gate, approver, date, and a link to the record - and validate it with QA before the surveillance audit. I would also flag scope creep: customizing the board for compliance before flow is stable risks another abandoned attempt. Put the recommendation in writing with the regulatory rationale, so the decision is documented and owned by the VP rather than inferred later.