Running a visual planning workshop for new teams

A new team rarely begins with a shared picture of how work moves. People may know their own tasks while the sequence between sales, engineering, operations and delivery remains fuzzy. A visual planning workshop for new teams closes that gap by making the current workflow visible, exposing dependencies and giving the group a practical way to coordinate from day one.

The session should not be a lecture about lean. It is a working session in which participants reconstruct a real workflow, agree on rules for managing work in progress and leave with a board that can guide immediate action. Good facilitation balances structure with enough space for frontline experience and technical constraints to shape the result.

Set a shared purpose before drawing anything

Define the purpose in operational terms: identify dependencies, agree where work waits, clarify ownership and create a shared planning rhythm. Explain which decisions the workshop can make and which need escalation. This prevents the session from becoming an abstract discussion of Kanban and gives participants a clear test for a useful outcome.

Bring together the people who supply, accept and support the work, including team leads, specialists and an operational decision-maker. Many Australian teams favour direct, practical discussion, but it still needs psychological safety so that new members can challenge an unclear process without feeling exposed. Ask participants to distinguish a known constraint from a personal preference.

The process may draw on lessons from industries beyond the immediate team. Project Visit, the Chalmers Electronic Lean Research Team known as Celean, publishes Swedish project examples that show visual planning and lean research travelling between industrial settings, including collaborations involving Volvo. The Australian context adds remote sites, rostered shifts and a mixed workforce of employees, contractors and labour-hire crews. Use international examples as prompts, then adapt them to the local team rather than copying another organisation's board.

Build the visual workflow together

Map the current state on paper before choosing software. Select one recent, representative piece of work and follow it from request to delivery, noting where it waited, who touched it and which handoffs caused rework. Draw each meaningful stage as a separate step. A useful value-stream view is simple enough for the team to redraw from memory; visual clarity matters more than polished diagrams.

Translate stages into a pull workflow with clearly defined starting and completion points. Use swimlanes only when work genuinely crosses functional or organisational boundaries, and label them in language the team uses every day. Cards should carry enough context to be understood without a meeting: a unique identifier, title, accountable owner, acceptance criteria, priority, target date and the reason when an item is blocked.

Set service expectations alongside the visual order. Some items may need a fast response, while others can enter a standard flow, and complex work may need a separate review lane. Agree what “ready” means before a card starts and what “done” means after acceptance. This shared vocabulary reduces the common Kanban failure in which every item is urgent and every column becomes a queue.

Run a collaborative planning session

Prepare a physical simulation with cards, sticky notes, markers, tape and a large board. Arrange the space so participants can move items and gather around the workflow. A timer and a visible parking area for unresolved questions prevent discussion from drifting. Bring red and blue markers for the current and desired states, but ask the group to explain every distinction in plain language.

Use a timeboxed sequence: agree on purpose, reconstruct the current flow, design the future flow, populate the board, test the Kanban policy and assign ownership. Work from a real example rather than an idealised process, then ask which changes depend on another team. Keep a decision log beside the board so that assumptions, disputed choices and follow-up owners remain visible to people who join later.

Facilitate by asking precise questions: What starts this item? Who can approve it? What evidence shows it is finished? Where does it wait longest? Let participants move the cards before the facilitator offers an explanation. Record unresolved issues without turning them into a debate, and reserve the final part of the session for confirming the board policy, the first review date and the people responsible for keeping information current.

Use a practical Kanban facilitation checklist

Use a small set of realistic pieces of work. Avoid filling the board with hypothetical tasks or inventing urgent work; the board should reveal how the team will manage its first fortnight. Include a normal item, one waiting on another function and one with an uncertain completion date, because each exposes a different risk in the flow.

• Limit each active column to a number the team can finish, then adjust the limit after two weeks of evidence rather than during the first surge of pressure.
• Give every card one accountable owner, even when several people contribute, and record the next action in language that begins with a verb.
• Mark blocked work visibly and include the blocking dependency, the person who can help and the date the block was identified.
• Define ready and done on the board, including who accepts the result, so status is based on evidence rather than a general sense of progress.
• Keep a visible policy area for service classes, work-in-progress limits and the escalation path for aged or blocked cards.

After the group drafts limits, test them against current capacity and a known deadline. WIP limits should reveal an overload that can be discussed, not conceal it by encouraging staff to rush several items at once. If a limit is repeatedly breached, the team may need a skill adjustment, clearer acceptance criteria or a dependency removed rather than a stricter target.

Support teams spread across Australia

Australia's geography makes visual access a practical design issue. A team can include colleagues in Sydney, Melbourne, Brisbane and a remote operation in Perth, across different clock times and often different working arrangements. A single board photograph does not work for a rostered shift that ends before the central team logs on. Remote participants need a live view, a way to contribute asynchronously and a record of which decisions remain open.

Mobile access can help when the work happens away from a workstation. Project Visit's account of a mobile Kanban prototype offers a useful reference for capturing status where the team is already conducting a visual review. The important features are quick updates, visible timestamps, low-friction attachments and clear permissions. Staff should be able to state what changed and where it is blocked without waiting for a formal status report.

Build for the mixed Australian workforce found in many projects: permanent staff, contractors, labour-hire workers and teams working around FIFO rosters. Plain language matters when colleagues have different technical backgrounds or first languages. A remote “arvo huddle”, for example, can reproduce the short face-to-face exchange of a shift handover, but it still needs a written snapshot for people who were offline. The term “workback plan” is widely understood in Australian project settings, yet its dates must connect to the team's actual capacity.

Test digital updates against real work

A digital board should support the physical conversation rather than replace it. Let the team decide which fields, alerts and reports are genuinely useful, then test those features with real scenarios. Fresh data is especially important when a visual signal triggers action. As smart-grid edge computing demonstrates, shortening the path between a field measurement and an operational response can change the quality of a decision; a planning board has the same need for timely, trusted updates.

Run prototype sessions with people who will use the tool, not only with project champions. Ask a shop-floor specialist to update a card from a phone, a remote team member to find the current decision and a manager to identify aged work. Test weak network conditions, name changes, permission errors and the handover between shifts. Write down where the prototype creates extra administration; if updating the board takes longer than discussing the problem elsewhere, the workflow needs revision.

Measure whether visibility improves the flow. Useful indicators include cycle time, throughput, blocked age, forecast reliability and adherence to agreed limits. Review a small number consistently, and explain changes in the process when a metric moves. Australian suppliers may have limited access to digital specialists, while large enterprise buyers often expect integrations and audit trails, so the prototype should distinguish essential functionality from features that can wait.

Keep the visual system working after the workshop

Assign ownership for board accuracy. The team leader can own the policy, while a nominated coordinator checks that cards reflect reality and blocked items receive attention. Set a simple update time that follows the team's rhythm. Personal names and photographs can help people connect with an owner, but the work-in-progress limit and accountable owner should remain legible without them.

Use the board in recurring reviews. A short daily stand-up can focus on changes, blockers and policy adherence; a weekly service review can examine aged work, flow and future capacity. Remove completed cards only when the information has fed a decision or retrospective. Occasional policy changes should be tested with the team and recorded with a reason and effective date, so the board remains a learning system rather than a display of preferences.

The lasting result is a small, visible operating system for the team: the current state is understood, the next action is clear, constraints are visible and changes can improve the flow. A useful test is whether a new member can read the board, explain what is moving and identify where help is needed without relying on private knowledge.