When the Board and the Work Disagree

In 2016 I was engaged by Lloyds Banking Group to model product and agile practice in the Single Customer View lab, where I owned the roadmap and backlog for three full-stack DevOps teams. The board was, by every visible measure, healthy. Columns moved, stand-ups were brisk and the work-in-progress limits were respected. Delivery was still slower than the board suggested it had any right to be. This is an account of why, and of what we did about it.

The Situation

The Single Customer View was a data product with a simple promise and a difficult implementation: one accurate picture of a customer across insurance, financial planning and retirement, delivered through online banking. Three teams, a shared backlog, a kanban board that everyone could see and a sponsor who, reasonably, wanted to know why the pace on the board and the pace of releases did not agree.

The answer, once we found it, was that the board was measuring tickets. It was not measuring work. The gap between those two things is where kanban quietly fails in most organisations that adopt it, and it took three specific forms in our lab.

Three Ways the Board Misled Us

Waiting recorded as working. A ticket in the "In progress" column while its owner waited on another team's interface was not in progress. It was queued, with better presentation. We only saw the scale of it when we began tagging wait states explicitly and found that most of our cycle time was spent waiting rather than working. From that point flow efficiency, not velocity, became the number we managed.

Work that never reached the board. Production support, the favour for a colleague, the quick look at an incident. None of it was on the board, and all of it consumed the same people. The board showed capacity that did not exist. The remedy was unglamorous: everything went on the board, however small, or the board was fiction.

Columns that described hand-offs rather than value. Our columns read Development, Code review, Test, Deploy. We had drawn the organisation chart, not the customer's journey, and every column boundary was a queue we had institutionalised. We redrew the columns around outcomes and watched two hand-off queues disappear, because they had only existed to serve the shape of the board.

What We Changed

Nothing clever, and I am wary of accounts that suggest otherwise. We measured flow instead of motion. We put every piece of work on the board. We made the waiting visible, so that it could be debated. Within a quarter the board and reality agreed, and once they agreed the board began to do its real job, which is not to track work but to start the right conversations. A board that never embarrasses anyone is not mature; it is decorative.

Alongside the flow work, I trained, coached and mentored the Financial Planning and Retirement lab in product practice, so that the discipline outlived my engagement.

Outcomes. The Single Customer View won Scottish Feature of the Year and was featured at Digital Transformation London. Customer Net Promoter Score for the experience reached 92. The same period produced improvements to the retirement planner and online banking journeys, including the Top Up My Pension feature, which rounds up everyday transactions into a pension contribution.

A Test for Your Own Board

Choose any ticket in your "In progress" column and ask its owner what they did on it yesterday. If the honest answer is "waited", your board is misleading you in the same way ours did, and you now know where to look first.

Companion tools: the flow checks live in the Flow Health Check, and the three short pieces on Scrum, Kanban and flow give the method underneath. The engagement is listed in the portfolio.

Free to share, with attribution.More field notes · Freebies · How I can help