A productive workflow makes current work visible, limits what gets started and defines what finished means. AI can speed up an individual task. It cannot remove a review queue or decide for the team what deserves attention first.
The Monday when everything seems urgent
Imagine a team arriving on Monday to a full board. Some items are in development, others await a reply, and several are considered finished even though nobody has reviewed them. An AI tool arrives and generates more proposals, code and documents. The board moves. The result does not necessarily arrive sooner.
This is a hypothetical situation, not an anecdote from a particular project. It captures a common confusion: producing more pieces is not the same as delivering more value. If each new piece needs the same scarce approval, speeding up the input simply changes where work accumulates.
My advice would not be to buy another tool or introduce another ceremony first. I would start by seeing where work waits. Then I would make seven changes. They do not promise a percentage improvement. They do make it possible to discuss delivery constraints using evidence.
Change 1: map a productive workflow, not an ideal process
I would write down the actual stages from accepting work to completion for its recipient. If it waits for business approval, technical review or publication, that waiting must be visible. Three columns may be enough. Twelve can still hide what matters.
The May 2025 Kanban Guide requires a definition of work items, start and finish, states, control of work in progress and explicit policies, along with a service level expectation. This is not about decorating a tool. The team needs to agree what each state means and what permits an item to move on.
I would pay particular attention to the final column. A fix may need deployment and verification to count as finished. A document may need acceptance. I would not treat different kinds of work as if they all had the same size or path. The goal is that nobody needs to ask what finished really means.
Change 2: spare hands are not a reason to start more
Controlling work in progress, WIP, means deciding how many items the system can hold between start and finish. It is not a punishment or an invitation to sit idle. It prevents opening another task from becoming the automatic response to waiting.
I would not prescribe a universal limit of one task per person. Capacity, dependencies and the nature of work differ. I would start with an explicit control the team can sustain and observe the result. When review is full, the first conversation should be about helping finish work, not finding something new for everyone to start.
I would also write down exceptions. An urgent incident may enter, but who decides, what pauses and when that priority is reviewed should be clear. If everything is an exception, the limit does not exist. If blocked items vanish from the board, we have only improved the picture.
Change 3: a productive workflow includes review
Review takes attention and capacity. I would give it time, an owner and acceptance criteria rather than hope somebody finds a gap. The definition of finished needs to include the necessary checks, not leave them as invisible work after closure.
AI makes this decision more important. Generating alternatives is easy; somebody still needs to assess them. The 2025 DORA report describes AI as an amplifier of organisational strengths and weaknesses. I read that as a warning against accelerating one part and assuming the whole system has improved. That is my practical interpretation of the report, not a promise of results.
For a small change I would ask for a proportional review: objective, tests, risks and rollback if production is affected. Not the same paperwork for everything. The reviewer should find what they need without reconstructing several days of conversation.
Change 4: give AI clear inputs and outputs
I would choose a bounded task first: summarising information, suggesting test cases or preparing a first version. We would agree which data the tool can use and which it cannot. Then we would define what a person must check before relying on its output.
A polished tone does not validate content, and compilation does not validate a change. We still need to check what matters to the objective: facts, permissions, behaviour and effects. For consequential automation, I would separate preparation from execution. A draft should not become a sent message just because the next step seems obvious.
My test for introducing AI would compare the complete journey: preparation, corrections, review and usable result. If it saves the author time by transferring work to the reviewer, that should be visible. It may still be worthwhile, but the decision needs to account for that cost.
Change 5: measure a productive workflow
The Kanban Guide defines four minimum flow metrics: WIP, throughput, work item age and cycle time. WIP counts items started but not finished. Throughput counts finished items per unit of time. Age runs from the start to the present; cycle time runs from start to finish.
I would begin with ageing items. Work that waits too long may need a decision, a smaller scope or cancellation. The number does not accuse its assignee. It identifies a conversation that needs to happen. I would then look at cycle-time variation and the relationship between incoming and completed work.
I would not use throughput to rank individuals or compare teams doing very different work. Nor would I turn a service level expectation into a guaranteed date. The guide describes a forecast with both time and probability, based on historical data where available. Without that history, a starting estimate must be acknowledged as provisional.
Change 6: replace status reporting with decisions
I would not remove meetings on principle. I would remove those that repeat information the board should already show. A short conversation is useful if it clears a blockage, changes a priority or clarifies a dependency. Half an hour of updates with no decision can leave the work exactly where it was.
I would prepare each meeting around one question: what needs to come out of it? Afterwards, I would record the decision, owner and next step. Context can be shared beforehand. When information is missing, we should say what is missing. That supports asynchronous work without treating silence as approval.
A productive workflow needs communication agreements: what counts as urgent, which route to use and when a reply is expected. I would not put everything in one channel or assume permanent availability. Concentration is also part of the system's capacity.
Change 7: improve the productive workflow and look again
Before changing five rules at once, I would select the most visible problem. If review is building up, I would try reserving capacity and controlling incoming work. If tasks return because context is missing, I would improve the starting information. If everything waits for permission, I would clarify who can decide what.
My suggested starting point would be to observe a week without hiding waiting time, agree one small change and review it afterwards with the team. That period is a practical suggestion, not a Kanban rule. Some constraints need longer to reveal results; others require immediate action.
The review would ask two questions: are we completing work with less waiting, and are we maintaining quality and a sustainable pace? If one metric improves at the cost of errors or invisible work, I would not count that as success. I would change the rule and continue observing.
A tidier board is not the proof
For me, a productive workflow reduces the need to chase information. People know what is open, what needs help and what counts as finished. Priorities can change, but not secretly. AI helps with specific tasks without replacing judgement about what should reach the recipient.
I am not looking for a team that is busy all the time. I want it to finish important work without living in a permanent exception. Starting less is not a lack of ambition. It may be the decision that stops everything being left half done.
Common questions
How do cycle time and work item age differ? Cycle time belongs to a finished item. Age continues to increase while an item remains open. Both depend on where the team defines the start.
Do we need a different tool? Not necessarily. First, I would check whether the existing tool can show actual states, owners, blockages and agreed controls.
Does AI guarantee higher productivity? No. We need to observe the whole system, including review, rather than infer business improvement from generating more pieces.
Sources
A productive workflow connects with my approach to product and digital consulting: define the need, prioritise and check the result.
