The Kanban Board: Improving Coordination and Focus

Introduction

In 2024, the success of IT projects is still the exception and not the rule. This holds true besides the presence of many solutions such as Scrum, XP, Kanban, SAFe etc. I would argue that the sole focus on solutions rather than the problem(s) and the underlying “forces” does not have the desired effect. So, what is going on “underneath the hood”?

During the past 25 years, I have observed striking performance differences in eight fundamental (method-agnostic) components (dimensions, factors, capabilities) that determined project success or failure. The components are the foundation of the EAgLe (Evolutionary Agile & Lean) Continuous Improvement System.

Of those eight components, two – namely “Coordinate” and “Focus” – are of particular importance as they make the difference between “stressful frenzy” and “stressfree productivity” – the latter being a term coined by David Allen, inventor of the GTD (Getting Things Done) method. Without these two components being implemented at a moderate to high level, improvements in other areas will be hard to attain due to too high workload and too little focus.

The two components are explained in brief.

The two components can be further split into eight subcomponents each which allows to drive improvement efforts quite systematically.

Kanban (plus a bit of extra “spice”) does a good job in bring about improvements in Coordination and Focus. So, let’s take a detailed look at subcomponents addressed by Kanban board features and practices.

Kanban Board

The discussion assumes a Kanban board having the basic design of a development process with columns Inbox, Analyse, Analysis Done, Implement, Implementation Done, Test, Test Done. Since many teams use JIRA as a digital ticket tracking system, a few special cases for JIRA users are included.

We’ll provide a tabular overview in an attempt to deepen the understanding and appreciation of the “rhyme and reason” behind the Kanban board’s features.

The Kanban board in itself does not bring about actions or change. It provides visual feedback that needs to be dealt with. The daily standups for instance drive the actions that result from the Kanban board’s feedback.

The most important subcomponents are marked with light blue letters. They are the game changers.

Component	Subcomponent	Kanban Board Feature (Usage)	Explanation
Coordinate	Go Cross-Functional	Workflow for analysis, development and test activities completely visualized	Kanban promotes system thinking and as such strives to improve the performance of the whole system and not just developer performance. Without a detailed visualization of analysis and test activities, we would not be able to detect and quantify bottlenecks and address them.
	Pull Work	Buffer Columns	The board has active columns (e.g. “Analyse”) and buffer (passive) columns (e.g. “Analysis Done”). If the tickets in the buffer columns are not assigned to team members that allows for work to be pulled. The fact that the board has buffer columns cannot guarantee that work is actually being pulled. This needs to be a team practice. Note: Buffer columns serve two additional purposes. For one, they buffer variability in the throughput of upstream (preceding) workstations and ensure that downstream workstations have a lower risk of running out of work. For the second purpose, please turn to the subcomponent “Identify & Resolve Bottlenecks”.
	Limit Parallel Work	WIP Limits	The WIP limits effectively reduce the amount of parallel work. For teams that have been in an overload situation (prior to the implemenation of the WIP limits) this will reduce the amount and cost of task switching, reduce average processing times and result in tighter feedback loops. In sum, throughput will be increased.
	Test Very Early	Low WIP limit on “Implementation Done” and clear signal on testable user stories	A low WIP limit on “Implementation Done” forces early tests since this would otherwise result in (heavily) broken WIP limits. Since JIRA does not allow for WIP limits to span multiple columns such as Kanban would mandate, we will have to specify separate WIP limits for “Implementation” and “Implementation Done”. A clear identification of testable stories aims at reduced waiting times.
	Identify & Resolve Bottlenecks	Broken WIP Limit in Buffer Column	Buffer columns assist in detecting bottlenecks. A broken WIP limit in a buffer column is a warning signal of a potential bottleneck in the workstation following the buffer.
	Identify & Resolve Blocked Tickets	Flag blocked tickets	It is important to have a team agreement to flag blocked tickets along with a comment stating the reason for being blocked. Blocked tickets should have e.g. a colored background and are thus easily identifiable.
	Identify & Resolve Stale Tickets	Quick Filter “Stale Tickets”	In order to establish flow and to have tight feedback loops, stale tickets need to be identified and discussed on a regular basis, e.g. once or twice per week.
Focus	Focus on Releases	Release Swim Lanes	In legacy industries changes are deployed to production often in major releases. The release ticket is assigned to is the primary driver of priority when compared with other tickets. This needs be reflected by the board design. Kanban boards are SLA (Service Level Agreement) boards and tickets with a shared SLA should share a swimlane. Tickets assigned to the same release share the SLA of being deployed in good (high) qualilty at the time of go-live. Remarks: Jira (digital Kanban Board) for example offers also a swimlane-by-epics feature but that results in tickets of various releases sharing a swimlane and tickets of the same release being spread out across the board. Such a board is ill-suited to focus a team on release goals. It should not be used in the team’s daily standup. That notwithstanding, a swimlane- by-epics board can be created in addition to the team board and can serve other purposes such as multi-release planning of epics. To ensure that both boards show the same tickets, they should use the same Jira filter.
	Control Input	Separate Kanban “Inbox” Column. Backlog not being part of the Kanban board.	Input of new tickets to the board needs to be controlled so that the board does not get “flooded”, e.g. Kanban board’s column “Inbox” serves as a mediary between the product backlog and the board. Moving tickets from the backlog to “Inbox” should not be the result of individual decisions but rather needs to be governed by a “committee” such as business and tech product owners.
	Prioritize	Use priorities	JIRA users can use the four standard priorities and show them on each ticket on the board.
	Respect Priorities	Sort swim lanes and tickets within each swim lane by priority.	The Kanban board’s swimlanes should be sorted by priority, fast lane on top, followed by the releases lanes. Within each lane, tickets of higher priority are above those of lower priority. This transparency enables the team members to base their decisions on priority.
	Continuously Manage Scope	Respect WIP limits	If all WIP limits are respected and limit breaches are quickly resolved, this will manage the scope to a certain extent. It does not suffice though since it will – neither provide a measure of a realistic release scope – nor assist in the reduction of capacity in the approach of the deadline for feature-completeness.

In a future blog, we’ll show how to continuously manage the release scope without estimating user stories. Stay tuned …