Your Kanban board is not your problem

Published

July 11, 2019

Words

805

Reading time

3 minutes

Retrospectives can, and should, throw up some good discussions. Of course that's healthy: everyone in the team should have a voice and needs to feel comfortable being able to contribute.

On the Search and Discovery team at NICE, one discussion we keep coming back to is the setup of kanban board. This is something everyone has a view on, from juniors to leads across all disciplines.

The kanban board

At NICE, we use Jira as our 'source of truth' for cards. We then have a physical board with post-it notes where we run standups. Probably a fairly standard set up, at least it was until lockdown and remote working.

The board varies per team, as it should, based on their needs. Some teams keep the board simple with as few columns as possible. Some break the board down into loads of columns, one of each step of the development process.

In Search and Discovery we probably fall into that second camp. We've got a large team working across greenfield work, live service maintenance on defects, user-centered improvements and change requests. Our development process, and in turn our board, reflects this complex mish mash of work.

Greenfield

I've recently worked on a smaller development team on a 10 week mini-project, joining part way through. This gave us a perfect opportunity to trial new tech, tools and processes. And a perfect opportunity to refactor the board to reflect the smaller, more-focussed work stream.

We also trialled a new way of forming project teams. Normally, work is fairly siloed into each of our delivery teams. But for this piece of work we trialled the idea of pulling people together from 2 different delivery teams, based on knowledge experience and personal development goals.

This meant I was lucky enough to work with Eleanor Mollett. She's got some great thoughts, and written great posts, around kanban boards. It was refreshing to see a different approaches, experience and thought processes from Eleanor and the rest of the team.

Our kanban board was simple, and rightly so. It was a small team, for a short period of time and we knew the board had to evolve. As Eleanor says in her Refactoring the wall blog post:

if you try to start with an ideal board with an ideal workflow, you will always be fighting it

This simpler board setup was certainly a step change for those of use used to the Search and Discovery setup. It did however through up some some healthy discussions during retrospectives and team meetings. There seemed to be 2 clear schools of thought.

Schools of thought

There seem to be 2 distinct camps when it comes to columns on a kanban board. There's the "keep it simplers" who want fewer columns: not far off 'to do', 'doing' and 'done'. And then there's those who want a column for every phase a card goes through: analysis, design, development, code review, test, QA, release and so on.

I'm in "keep it simple" camp (reducing the number of columns), for the following reasons.

First and foremost it prompts communication. So much of what goes wrong in software is down to communication, or lack thereof. Yes, with fewer columns you lack being able to glance at a board and see where a card is at. But what you gain is having to discuss and ask about a card which improves context for everyone, especially at standups.

Secondly, it stops the 'throw over the fence' mentality and promotes ownership of the work across the board. We're all guilty, me included, of picking up a card, doing your bit, and passing it into the next column without a second thought. Someone else will then pick it up. Fewer columns forces you to have to own the card and pass the baton on, rather than just moving it into the next column for the next person. For example, asking for a code review and actively assigning a card to someone else with context. It's active rather than passive.

Lastly, it makes the board less discipline-focussed. Granular columns are so often aligned with disciplines (BA, UX, dev, test and design). This makes the board focus on the individual rather than the team as a whole. It's the teams responsibility to get the card from left to right, not a series of individuals.

Individuals and interactions

But for me, it has to come back to the problem. Kanban boards are there to help the team. Usually a team's main problem is lack of communication. So your board has to help promote and improve communication.

It brings me back to the first core value in the agile manifesto:

Individuals and interactions over processes and tools

Yes, a team is made up of individuals, but it's the interactions that are key. Don't hide behind the board. Communicate more.