Kanban for small teams

When the tool takes precedence over the method

The pattern repeats itself in many small businesses: a team of four or five people decides to finally organise their work in a structured way. Someone has heard of Kanban, a well-known project management tool is introduced, and two weekends are spent setting it up. Three months later, the actual agreements are back on the whiteboard, the real information is in a spreadsheet, and the tool has become a graveyard of obsolete cards. The obvious conclusion is: “Kanban doesn’t work for us.”

This conclusion is almost always wrong. It is not the method that has failed. What has failed is the attempt to translate a very small method into a very large tool.

Just how simple Kanban really is

It’s worth briefly recalling what Kanban essentially requires:

• Make work visible.
• Limit the amount of work in progress at any one time.
• Ensure that work flows rather than gets bogged down.

That is essentially all there is to it. Kanban does not prescribe roles, ceremonies, estimation methods or reporting formats. It is one of the few methods that explicitly starts with what you are already doing today and improves upon it in small steps from there.

A method with three core principles should really be the easiest thing in the world for a five-person team. So why does its implementation so often fail?

Tools solve coordination problems that small teams do not face

The major project management platforms are designed to address a specific set of challenges: numerous teams, numerous dependencies, numerous stakeholders, and distributed responsibility. Their architecture stems from this – role models and authorisation schemes, configurable workflows with approval stages, mandatory fields, automation rules, portfolio views, and integration marketplaces.

Each of these features makes sense for some organisations. For a small team, however, each one initially raises a question that needs answering: Which fields do we need? Which workflows do we need to map out? Who is allowed to do what? Small teams answer such questions conscientiously, because they want to use the new tool properly. An afternoon’s setup turns into two weekends. Three columns become nine, because the template board had nine. ‘Create card’ becomes a form with seven fields, five of which nobody ever analyses.

I call the result ‘configuration debt’: the team has built structures that it now has to maintain, even though they don’t make a single aspect of the actual work any easier. In large organisations, there are people whose job is precisely this maintenance. In a five-person business, it amounts to one evening a week that nobody gets paid for – and that’s why the maintenance falls by the wayside, why the board becomes outdated, and why the truth migrates back to the whiteboard.

The second disconnect: in small businesses, work doesn’t end at ‘done’

There is a second, less frequently cited reason why project tools go off the rails in small businesses: in the world for which these tools were built, the workflow ends at ‘done’. Someone else takes care of what comes next.

In a small business, there is no such ‘someone else’. The same person who carries out the work has previously sold it and must invoice for it afterwards. From a business perspective, a task isn’t finished when it’s done – it’s finished when it’s invoiced. If the project tool knows nothing about the customer base or invoicing, a gap appears in the ‘Done’ column, leaving money on the table. Anyone who has ever painstakingly pieced together at the end of the month which completed tasks have actually never been invoiced is personally familiar with this gap.

This is not an argument against Kanban. It is an argument for taking the last column of the board more seriously than the methodology literature usually does, and for linking it to commercial reality, even if initially only through an agreement: a card only leaves the board once it has been clarified what will happen to it from a commercial perspective.

What remains when you strip Kanban down to the essentials

After several years of working with and within very small teams, a minimal set of elements has emerged that works for me:

Three to five columns, no more. ‘Planned’, ‘in progress’, ‘on hold’, ‘done’ last a surprisingly long time. Every additional column must be assessed against the question: what decision does it help to improve?

The WIP limit is an agreement, not a software function. Whether the tool can enforce limits is secondary. What matters is the phrase the team says to one another: ‘We won’t start anything new until the ‘in progress’ column is empty.’ A team that doesn’t live by this phrase won’t be saved by any validation rule.

Blockers are the most important information on the board. A card that is on hold because of a lack of customer feedback is more important than ten cards that are progressing as planned. A simple mark is enough, but it must be the first question asked during the weekly board review.

Age trumps metrics. Small teams do not need cumulative flow charts. The one metric that’s worth the effort: how long has the oldest card been in ‘in progress’? This single question, asked weekly, replaces an entire reporting module.

No story points, no velocity. Estimation ceremonies are coordination tools for situations where many stakeholders need a shared understanding. Five people who talk to each other every day already have that understanding.

Figure: Kanban – What is really needed and what often creates tool overload

Guidelines for implementation

If you want to introduce Kanban in a small team, a few simple rules have proven their worth:

1. Implementation takes an afternoon, not two weekends. If it takes longer, you’re merely setting up a tool rather than establishing a way of working.
2. Any field that takes longer than a few seconds to fill in when creating a card goes out the window. If nobody fills it in, nobody will analyse it either.
3. One board. Not one per project, not one per person. The power of visualisation lies in everyone looking at the same picture.
4. Cards speak the customer’s language, not the language of technology. ‘Follow up on quote for Meier’s roof renovation’ is a good card. ‘Follow-up Task #217’ is not.
5. Only change the tool once the team has embraced the method. A team that works disciplinedly with sticky notes on the wall will be able to cope with almost any software. A team that doesn’t live by the agreed practices won’t be saved by any software.

These guidelines deliberately keep the introduction simple and help to establish Kanban as a shared way of working, rather than creating yet another system that needs to be maintained.

Conclusion: A look at the benefits of Kanban for small teams

Kanban is a simple method. This is precisely where its strength lies for small teams. It does not require complex workflows, extensive role models or elaborate configurations, but above all a shared view of the work.

Problems usually arise when the tool becomes more complex than the method itself. Additional fields, rules and reports can quickly create more maintenance work than they are worth. For small businesses, there is the added factor that work does not always end with ‘Done’. Often, it is only truly complete once the commercial aspects have also been sorted out.

What matters, therefore, is not to include as many functions as possible, but simply to make visible what is truly necessary for good decision-making. Those who consciously keep Kanban simple achieve, with minimal effort, exactly what small teams need: transparency regarding work, bottlenecks and real progress.

Notes:

Jonas Kutavicius supports businesses of all sizes as an IT service provider. He would be delighted if you visited his company’s website Cryon or got in touch

You can find further information on the principles and practices of Kanban here.

Would you like to support Jonas Kutavicius and discuss Kanban for small teams? Then please share this post within your network or within your organisation.