Slouching towards Kanban

It’s taken slightly longer than I intended to get to this stage. This of course is partly due to the slippery nature of software development itself – but in this case, it’s also down to the fact that the end of January is tax season in the UK, and in my case this co-incided with an internet outage which took the best part of a weekend to sort out. I still don’t know the reason but I certainly can’t complain about the level of support I’ve had from my ISP. If you happen to be reading this in Britain and you are looking for a new internet provider – I recommend Zen Internet.

The App still has all the features that were in the previous video – inter device card transfer, flippable cards, sub-boards and so on. The most obvious addition is that you can now add sections – sometimes called swimlanes – to a board as well.

As with boards, a swimlane can be renamed, and deleted if it is empty. They also have a number at the beginning – that’s the total number of cards in this swimlanes and it includes any cards on subboards in this lane too. So if a lane has two cards in it, and also has a subboard with five cards in it – the number on the lane will be seven.

Why bother with a number ? Although I think this §app will be used in a variety of ways, I’m also hoping that it will prove useful to practitioners of Kanban. Kanban, pronounced conbon’ is a time management and project management practice that originated with Toyota. There’s a lot of information out there but to summerise it, it relies on vizulizing work, in this case on index cards, limiting work in progress, and moving cards between swimlanes as work proceeds. You can see me doing this in the video as a card move’s from my ‘To Do’ area, to ‘In Hand’, to ‘Pending’, and on to ‘Completed’.

You can apply the same idea to agile software development, the swimlanes in this case might be User Stories, Design, Code/Test, QA. Endless variations are possible depending on your own particular way of handling work.

One point that Kanban is very clear on is that there is always a limit on the amount of work in progress and this in turn limits the number of cards in any particular swimlane. This immediately leads to the question of whether or not CardBoard should enforce limits ? I’ve chosen not – as you can see here. There’s always a balance to be chosen on how prescriptive a piece of software is made, and I think we often get this balance wrong. If I insisted on capacity limiting lanes, the users would run into the following issues:

1. Non Kanban users are inconvenienced
2. Kanban users who need to go slightly above the limits are inconvenienced
3. There needs to be a way of specifying capacity
4. there needs to be feedback when you try and move a card into a swimlane that full
5. You’ll probably need a way to adjust capacity,


In real life, its pretty obvious that a real notice board with real index cards doesn’t have enforced limits on capacity, and doesn’t really need it either. An overcrowded lane would be obvious. In CardBoard I’ve chosen to go down that route too.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s