You have probably seen variations of the Scrum/Kanban board, and from looking externally, ours is no different, but I thought it might be a good idea to go through how our board works. A practical example as looks can be deceiving.

To give you an idea of our circumstances, we are a BAU team. So we do both support and development work. We are a long lived team, but can be deployed to projects individually.

The Basic Board Layout

As you can see from our board, we have a few more columns more than the “To-do, Doing and Done”.
Each column represents a step in our development process.
Analysis – Analyse the card to determine what work needs to be done.
Build – The actual development step.
Test – Testing obviously
Review – where we get the code peer reviewed
Deployed – where it is deployed into production and finally
Done – the card is complete.

This should be obvious to anyone who has done development work before. Nothing new here.

You may also notice that we have sub-columns. WIP and DONE (Yes, multiple Done columns!).

What does this mean, well.
WIP – Work in progress. This is where when a card is actively being worked on lies.
DONE – When you finish working on the card in that process, you move it to the DONE column.
What this does is give you a visual indicator on what cards are actively being worked on, and what cards have been completed in that process.  Then, the person who performs the next process (Not necessarily the same person), when they start working on the card, they move that card from the DONE column to the WIP column of their process.
So for example, John is a BA doing analysis on a piece of work. He takes the card from the backlog, moves it to the WIP column. The card stays in this column until he completes the card. It may stay there an hour, it may stay there a week while he works on other stuff (I’ll get to this scenario later). Either way, you can see what is in progress.
Once John is finished his piece of work, he places it in the DONE column. Now, Jane is a Developer. When she has spare capacity, she will take the card from the DONE column under Analysis and move it to the WIP column of Build where she works on it. The card itself then follows the processes through the life cycle until it is completed and deployed into production.
Fairly simple.

The next thing you may notice is that we have our projects listed in the backlog. Here we put the next lot of cards ready for work. We have divided things into projects because… that is how we work. It may not be right, but it is the current process. I’ll get to this later.

Another thing you may notice is the colour dots across the top. Each colour is a representation of the process. I’ll get to this later. Now I will explain how the cards work!

The Basic Card Layout

Now, our cards are quite simple. Across the top, we have a header where we give the relationship of the card to what it is for. In this example, I have given the header “Retrospective” as the card may have been related to a task determined during the Retro.
The next segment is the Description. Here we give a short description of what the card is for. In our team, we do not do stories, but we can – but only when they make sense. So far we haven’t needed to.
Then we have the date the card was created, the sizing Small, Medium or Large and who the card is assigned to.
I hear some Agile people saying that this is a no no, I agree, but that is how we work. At least for now.
All this is pretty standard.

We also have different colours for the cards themselves. White is BAU tasks, Red is unplanned work, Blue for Internal Team projects, Green for External Business projects and Yellow for Personal Development.  Therefore from a visual perspective, you can see what everyone is working on.
Unplanned work – Red – is a special case. This is work that has skipped the backlog and become urgent. It may be an unplanned request from the business, it might be a bug. It is basically anything that has disrupted the flow of cards and caused someone to stop what they are currently doing and do something else.

But, now we get to the interesting part – the coloured dots.Each dot has a meaning.

The Red dot represents a card going backwards. Lets say that a defect was found during testing. The card then goes back to build to fix the bug. A red dot is then added. If the card fails testing again and goes back to build, then another red dot is added. If the card rolls back after deployment, another red dot is added. The idea is that we get a visual representation of troublesome cards. The idea is not to discipline the person causing the problem, but to identify the problem in the first place and then look at ways at preventing it for similar work in the future.

The other colours, you will see represent the process steps.
For each day that a card sits in the WIP column of the process, a dot is placed on the left side.
For each day that the card sits in the DONE column of the process, a dot is placed on the right side.
We just use whiteboard markers to place the dots (I have multiple colours!) instead of stickers. Stickers can be too big.
What this shows is how long a card is in each column.  This can help identify bottlenecks in the process such as resourcing constraints.
Basically, if a card has measles, then it is sick.

Now, on the back of the card,
we have a section for notes. This could be acceptance criteria, it could be blank. The option is there.
Then at the bottom of the card, we have replicated the columns of the board again. Here we record actual work time. So time actively working on the card. We do not assume that if the card is in the WIP column, that it is actively worked on. This is the case when someone has multiple cards open. They may be working on something but it may be blocked (which we indicate with a tag labeled “Unblock Me!”) waiting for something.
When combined with the left hand side dots, we can get a ratio of actual work time vs lead time.

Say you worked on a card for 20.5 hours as indicated above. But the card was in WIP columns for 6 days, 48 hours. Our ratio is 20.5/48 which gives us a 0.43 ratio. So what this means is that the next card of similar size (hence why we add sizes to the cards) If we guess that it will take d days of work (16 hours), we can expect it to be completed after 37 hours.  About 4 days. The actual time again is recorded in a similar manner and the variation is then graphed. This can then be used for reference for future estimations.

The cards themselves are placed on the whiteboard using magnets. I got a couple of those magnetic calendars you get in the mail to place on your fridge and cut it up to about 1cm or smaller squares and used blu-tak to attach them to the back of the cards. It makes it simple to move the cards and so far we haven’t had many cards fall off. Much better than post it notes.
The cards themselves are printed out on a colour laser printer to get the different colour cards and we just mark them up with pen. The cards are quite small. About 4cm x 5cm.

Analysis

This board itself does not make you Agile. Lets have no delusions about this. What it does do though is help get you Data!
Data to help determine where the bottlenecks are, data to help with estimation. Data to determine if a change in the system has any affect.
Having a board itself does not help you be agile, it just helps you gain a bit more understanding on how you work. Its what you do with that understanding, that data and use it to progress towards agility that determines if you are agile or not.
Do nothing with the data other than make pretty graphs, and you are changing nothing.
Using the data to guide your decisions, that is where the real power is.

Now, I should mention that I do not force anyone to follow this process – except myself. I have left it up to the individual team members to determine the value,  but as a fellow developer, I can at least go to my manager with more solid backed by data information than just doing a finger in the air guess.

I would also like to mention that you should not follow our board like for like. Use our board as an example, but iterate and analyse your processes to develop your own methods.
Our board is constantly changing an how it works now is not how it may work in 6 months time.
For example, I would like to try reducing the number of projects, set work in progress limits, try to remove the assignment of tasks to individuals and make it more team based, but that requires a culture shift which is pretty hard to do overnight.  It is my intention that over time, as we identify problems using the data from the board and figure out ways to solve those problems, that we get better.
Yes, we could implement an existing framework such as Scrum, but then we get into the culture problem again. Who knows, we may figure out Scrum ourselves, or figure out some other method. My intention is that it is for the team to explore and not for me to dictate (not that I could anyway).