Kanban

A task board can tell us that something is “in progress” without explaining very much. Is someone actively working on it? Is it awaiting a response? Has an external service become unavailable? Does anyone know which decision would allow it to continue?

We want the shared view to reflect what is actually happening. Its labels should mean something to the people using it, including a client who does not live in the project-management tool.

The Kanban Guide connects an explicit workflow with active management and improvement. It calls for defining work items, start and finish points, workflow states, work-in-progress controls, movement policies and a probabilistic service-level expectation. A board alone is not the complete practice.

That leaves important design questions for each situation. What counts as a piece of work? When have we accepted it into the active workflow? What does completion mean to the person waiting for it? Which information should be visible, and which belongs in a restricted record?

A shared board should not become a place where sensitive customer details are exposed merely to make a task easier to recognize.

People usually already have a way of getting work done. Some of it may be documented; some may depend on a colleague remembering to send a message at the right moment.

We can learn a great deal by following a request through that arrangement before proposing a replacement. Who receives it? What makes it actionable? Where does it wait? Which informal conversation resolves the ambiguity? What happens when the person who usually knows the answer is away?

Kanban University's guide describes improving an existing way of working, with attention to the flow of the whole system rather than simply keeping each individual occupied. That makes it relevant beyond software alone.

At Abstraction, the practical scope includes helping clients organize priorities, limit simultaneous work, recognize blockers and review what needs attention. The arrangement can connect development, design, content, marketing and operational contributions without forcing them to become identical activities.

An image awaiting usage permission and a software change awaiting a test result may both be waiting. They still need different expertise, decisions and records to move forward.

Beginning another task can feel helpful. It can also leave the team with more half-finished work and the client with more things to monitor.

When we discuss limits on simultaneous work, the point is to protect attention and make completion possible. The question becomes: what can we help finish before we introduce another commitment?

That may mean answering a colleague's question, arranging a review or clarifying a requirement. It may mean acknowledging that a specialist is not available yet. Starting a second task does not resolve the dependency on the first.

The appropriate limits and exceptions need to reflect the actual work. A critical customer-facing failure may justify interrupting a planned improvement. We still need to know who can make that call and what happens to the work displaced by it. An “urgent” label cannot create additional capacity by itself.

We would rather make those tradeoffs visible than ask people to quietly absorb them. A delivery relationship becomes easier to trust when its limits are understandable.

For an organization running creative workshops, we can look across website requests that seem unrelated and uncover what they are waiting on. Booking changes, preparation information and campaign pages may share a decision-maker as well as a deadline.

Several pieces of work are underway. A booking change needs a decision about the cancellation policy. Revised preparation instructions need the workshop lead's review. A campaign page is waiting for confirmation of the next event's capacity.

To the client, these may look like unrelated delays. To the team, they may appear as three active assignments. Looking more closely could reveal that all three depend on the same person, who is also delivering workshops throughout the week.

Adding another page to production would do little to address that constraint. A more useful response might be to gather the decisions into a short, prepared review and determine which can be delegated. The client would decide the authority; we could help explain what each decision affects.

We can agree a limit on work entering production that reflects actual review capacity. The point is to make an intentional working agreement with the team, not impose a universal task limit.

For the booking change, the record could name the question plainly: what should someone be allowed to change after the preparation deadline? It could identify the decision-maker, the information they need and the next point at which we will revisit the issue. “Blocked” becomes a starting point for action rather than a place to put a forgotten task.

The preparation instructions may be ready to advance sooner because their remaining review can be assigned to another qualified person. The campaign page may appropriately remain paused, with the unfinished work still visible, until event capacity is known. Different treatment reflects different conditions, not favoritism between requests.

Helping work move can require an organizational decision as much as another hour of production.

Working agreements are most useful when people can understand them without having been present at every earlier conversation.

For a particular engagement, we might clarify what information a request needs, who helps prioritize it, what a reviewer is being asked to decide and what evidence accompanies completed work. We can also define how an interruption is handled and when a blocked item needs escalation.

These agreements should be specific enough to guide a decision without pretending to remove judgment. A request can be incomplete because the client needs help defining it. That is different from a request ready for implementation but missing an attachment.

The response should fit the situation. We can give an unresolved question a discovery step instead of repeatedly returning it to someone who cannot answer it alone.

Design Facilitation supports this work when people need to compare perspectives or agree on responsibility. Clear rules are easier to sustain when those affected have helped make sense of them.

The Kanban Guide identifies four flow measures: work in progress counts started but unfinished items; throughput counts items finished in a period; work-item age measures elapsed time for unfinished work; cycle time measures elapsed time from start to finish. Its service-level expectation combines a duration and probability. These describe workflow behavior, not a guaranteed completion date for every request. Kanban Guide: flow measures and workflow

Those measures need context. A language correction and a complex integration are not interchangeable achievements simply because each occupies one card. Comparing how many cards two people finish can obscure the work rather than explain it.

For the workshop example, the useful question might be how much time requests spend waiting for a decision and whether the new review arrangement changes that pattern. We would still need enough representative observations to draw a conclusion. One quickly finished request would not establish a dependable future turnaround.

Any measurement arrangement should have a reason: support a decision, expose a recurring difficulty or improve a forecast. We do not presume every engagement already uses the complete formal measurement system, and a forecast is not a substitute for a separately agreed service commitment.

Work does not stop being connected because it crosses a department boundary.

Content Operations considers how content is created, approved, maintained and governed. Kanban can make the movement through those responsibilities more understandable. Workflow Automation can route information or trigger an agreed action; it cannot decide whether the underlying policy is sensible.

Automating a reminder might help a reviewer remember. It will not resolve the fact that nobody has authority to approve the content. Understanding the distinction helps us choose where to intervene.

Kanban can also complement Scrum, bringing attention to flow within an existing framework. It need not become a choice between a board and Sprints. Agile Development provides broader context for how learning and changing priorities can inform delivery.

The useful connection is between the method and the situation, not the number of methods a team can name.

Abstraction's wider cycle remains:

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

We can discover how requests actually move, define a difficulty, explore a different arrangement and try it within the work. Learning then asks whether the change helped the people involved and the outcomes they depend on. Advance may mean keeping it, adjusting it or trying something else.

Continuous Improvement keeps that inquiry purposeful. The goal is not to endlessly reorganize the board. It is to help useful work reach people with fewer avoidable obstacles.

Shared records and living workbooks can preserve the current agreements, decision responsibilities and instructions. If the system changes, those explanations may need to change too. Ongoing support for that care should have a defined scope; a queue does not imply unlimited capacity or immediate response.

If your team has plenty underway but too little feels finished, we can start by understanding where the work waits and why. You do not need to arrive with a new management system in mind. Bring the requests, the frustrations and the knowledge of how things really happen. That is enough to begin making the next step clearer together.

Contact Us