When a team adopts an agile method it almost always happens in the same order. The board comes first, because it is the visible part and takes half an hour to set up. Then the recurring meetings, because they can be put in a calendar. Last, if at all, the constraint — which is the only part that actually changes how the work gets done, and the only one that costs something.
The intermediate result is a board with five columns where everyone has three cards in “in progress”, and a daily meeting where each person takes a turn reporting that they are busy. Every object of the method is in place. The time between “we decided to do this” and “it is in production” has not moved by a single day.
A board without limits is a list with columns
A work-in-progress limit is the rule that says: this column cannot hold more than N cards. It looks like bureaucratic restriction and it is instead the engine of everything else.
Without the limit, the board records what happens. With the limit, the board starts preventing something: when the column is full you cannot pull another task in, and you face a choice you could previously postpone. Either you finish something, or you go and help whoever is stuck, or you declare that there is an obstacle outside your control.
Those are the three things a working team does constantly, and they are exactly the three things nobody does without a constraint — because opening a new card is more comfortable than closing an old one.
Starting is not delivering
Work in progress produces nothing until it reaches the end. Eight tasks started and sitting at eighty per cent are not “almost eight tasks”: they are zero, plus the cost of holding eight different contexts in your head.
It is arithmetic that convinces everyone on paper and almost nobody in practice, because started work gives a feeling of progress that unstarted work does not. A board with many cards in motion looks like a productive team. Often it is a team paying interest on eight debts of attention.
Reducing the number of open things shortens delivery time without anyone working faster. This is not motivation, it is queueing: the less there is in the system, the less each individual piece waits.
The limit exists to surface obstacles, not to measure people
This is where the method is most often misread. A low limit is not a way to check that everyone is busy: it is a way to make visible, quickly, whatever is preventing things from finishing.
When the column is full and nobody can pull, the conversation necessarily moves from the task to the impediment. A review that never arrives, a missing environment, a decision nobody has taken. These things existed before too; they simply stayed invisible, because everyone worked around them by opening something else.
Removing those obstacles is the job of whoever leads the team, and the constraint is what puts it at the top of the list instead of the bottom.
When the process does not hold, the problem is often the architecture
This is the part the usual account of agile method almost always leaves out, and it is the one I find most interesting.
If two people cannot work in parallel on two separate tasks without stepping on each other, that is not a coordination problem: it is coupling. If every change requires touching the same module, if one delivery sits waiting for another that touches the same files, if integration time exceeds development time — no ceremony fixes it, because the problem is not in the process.
A work-in-progress limit helps here too: it surfaces structural friction in the form of queues, where it can be seen. A team that cannot keep three things running in parallel is usually working on a system that does not allow parallel change, and the right answer is not one more meeting but a better-drawn boundary.
This is why I do not treat leading a team and designing the system as two separate subjects. They are the same thing seen from two sides: the shape of the architecture decides how many things the team can genuinely do at once.
What I watch
Few measures, and none about individual people.
Cycle time — from when a task enters work to when it is in production — says more than any estimate, because it is a fact rather than a forecast. Its variability says even more: a team that delivers on unpredictable timescales has a problem the average hides.
And the number of tasks blocked waiting on someone else, which is the direct measure of how much the team depends on things outside its control. If it grows, asking for more commitment will not help: the dependency has to be removed.
None of these measures lends itself to judging a person, and that is a requirement rather than a side effect. A flow metric that becomes a report card immediately stops telling the truth, because everyone learns to make it look good.
In practice
If I had to suggest where to start, I would invert the usual order: the limit first, then the board, and meetings only when they serve something the work itself does not already show.
An uncomfortable constraint on a team with no board still produces useful conversations. A perfect board with no constraints produces a tidy archive of unfinished work.
← All articles