The Status-Meeting Board

The first step is to make the current workflow and policies visible and explicit. The board has only three columns, is updated at a weekly meeting, and lacks agreed definitions of ready, done and blocked; without that, any maturity score or dashboard measures an unreliable picture. The team should map the real work-item types, such as incident, change, security patch and project, define the states each type passes through, write explicit policies for entry and exit, and update cards when work actually moves. Then add WIP limits at the constrained states and use the board in the daily standup. A maturity assessment can be useful later, but starting with it risks producing a label rather than a change. A full metrics dashboard before basic visualisation invites vanity metrics and disputes about data quality. Early metrics should be simple and flow-focused: WIP by state, cycle time, throughput and blockers. The quick relief the team wants comes from limiting WIP and exposing incidents that wait behind project work, not from a dashboard. The consultant's sequence is backwards.

The standup should become a flow review around the board, not a status report to the manager. Cards should be updated when work changes state, not once a day at the meeting; otherwise the board is a historical report. The team should walk the board from right to left, starting at Done and moving upstream, asking what is blocking completion, what is aging, and whether any WIP limit is breached. Each item is discussed, not each person. The manager's role is to ask about flow, blockers and policies, and to help remove impediments, not to collect individual updates. Keep the meeting to about 15 minutes and take detailed problem-solving offline. Add explicit policies for what blocked means, who updates a blocked card, and when an item is escalated. Use the standup to decide whether to swarm on an aging item or pull new work. This change also supports making policies explicit and implementing feedback loops. If the manager needs a status report, it should be generated from the board, not from a meeting.

Do not begin with arbitrary numbers. Use board data to find current WIP at each state and set initial limits slightly below it, then adjust. Separate the two work types with swimlanes or explicit classes of service, because incidents and projects have different flow risks. Give incidents an expedite lane with a small cap, for example one or two items in the system, and a policy that an incident pre-empts project work only under defined severity criteria. For projects, set WIP limits at the constrained states, such as design or review, and require a project to be pulled only when a slot is free. Avoid starving projects by reserving capacity, for example a stated percentage of each week or a cap on incident WIP, rather than letting incidents consume all capacity. Avoid starving incidents by keeping a small reserve or a fast-track policy. Publish the allocation policy and review it at an operations review. Track incident lead time, project cycle time and the frequency of pre-emption; if incidents regularly exceed the cap, address the source of demand or add capacity, not just raise limits.