A different kind of agile board

A few months back we took on a new product and in doing so thought we'd refresh the way we work, largely focussing on our board to help speed up our delivery. Just to be clear before going into detail, there is no right or wrong in terms of boards, just what fits you as a team. The details below are just our journey and findings that hopefully others may find interesting or at least take ideas from.

The Previous Board

We used a very common and perscribed board, in Jira as pictured below (this is a quick mock up so not exactly how it was):

It's a proven way of working and very effective in certain contexts, but in our case we found it a bit heavy/clunky and additionally we'd let certain problems manifest:

• No WIP limits. We actually used multiple "swim lanes", with no limits per lane or overall. The work per lane was commonly contextually different. All of this meant we found ourselves spread across multiple, differing pieces of work (leading to context switching or knowledge silos) and starting many things but finishing few. One consequence was needing to have regular inter-team knowledge share sessions (again not a bad thing, but manifested through a lack of working together).
• Lack of vision/understanding. When working on complex systems or problems having cards sat in columns wasn't helping us visualise and see what we were trying to build. We'd churn through cards with little thought to the problem at hand, or overall solution.
• JIRA overhead. We'd let the "features" (subjectively seen as bloat/waste) of JIRA complicate our board. Tags, epics, goals, stories, swim lanes, estimates, statuses, tasks, sub-tasks etc... The board wasn't fun any more. I often find when something becomes too complicated or a pain to use, people stop using it properly, and that was beginning to happen. There was a distinct lack of love for the board.

One option was to spend time fixing those issues with our JIRA board, but sometimes it's good to try something new, so that's what we did!

Diagramatic Board

This is a technique I used at my previous company. Simply put, our board, for what we're working on now, is a diagram. And that's the beauty of it, it can be whatever we want it to be (that best helps us) that best represents what we're trying to solve. Stories/tasks are stuck where work needs to be done. And avatars are stuck where people are working (strictly only one avatar instance per person!). When work is done, we change the colour (to green) or simply take it off the board. We try to work in weekly blocks, although that is by no means strict. If we finish a piece of work, then the board gets wiped and we draw the next problem and get to work. A week is just a nice unit of time we can all generally relate to, and as a team we try to deliver at least weekly.

While I prefer a physical board, we currently use RealTimeBoard as some of the team work in different locations (from home, or when visiting family abroad etc...):

There are a few caveats:

• Discipline - it's an open, free format. The idea is that what is drawn can be whatever is needed in order to help visualise and solve the problem. There are no rules or boundaries.
• Regular Reviews - what you draw on Monday may not be appropriate come Wednesday due to findings or decisions. Always question/analyse etc... the board daily and redraw it if needed. Don't let it become stale or not representative of the problem.
• No Silver Bullet - it won't solve all your problems, it's a tool that *may* solve *some* of your problems. For example it doesn't directly solve our WIP limit issue mentioned above. It tries to help by us only solving a single problem at a time (so that everyone is working on the same context), but the bounds of that context are still defined by the team.
• Keep It Simple - just like our JIRA board, if you over complicate your board it'll end up hindering rather than helping you. We've gone through phases of numerous multi-colour post-its, icons, graphics, even having a legend (we have one, but a minimal one for accessibility).
• Be Flexible - be like the board. The board should be flexible and changeable. So should you in terms of adapting to the work you're doing. In some cases this kind of board won't be effective but that's ok, don't use it!

Common Problems

• Something that commonly happens, is a discovery results in multiple additional cards spawning onto the board (although this is a problem that can happen on any board). We like to "jail" new items in a discussion area before adding them to the diagram. For a while we didn't do this, and it became difficult to track progress and scope as cards just kept on appearing.
• RealTimeBoard doesn't have any built in card types etc... We found when working individually, everyone would put things on the board slightly differently. Task or story, how things are worded, colours used, sizing etc... Again a problem that can happen on any board, but looked particularly messy on a diagramatic board. We solved this by working together, at least when breaking down work and updating the board, as this helped enforce a team-accepted way of doing things.

Backlog

Just for clarity, we still have a backlog which is an ordered list of work (currently sat in JIRA). We still use JIRA for certain things (RealTimeBoard even has JIRA integration although the cards look a little ugly). The great thing about a diagramatic board is that you can compliment it with other tools, in fact I'd encourage it.

Little Touches (Accessibility)

Having read about simulating colour blindness I decided to make our board a little more accessible as we have a colourblind team member (hence the slightly random colours in the picture above). RealTimeBoard isn't particularly helpful with the available colours (something I've raised with them and they've responded to very quickly) but using Oracle Color it is possible to pick more accessible colours for the board. We typically stick with the 3 left most colours (grey, orange and green) on the RealTimeBoard palette so that everyone knows which ones to pick (and doesn't end up picking similar shades/variants etc...). Here's how they might look to a colour-blind person according to Oracle Color:

Go Try!

This article only covers so much, and is sure to raise quite a few questions and doubts. It's far better to see in action by giving it a go. Remember it doesn't need to be permanent and it may not work for you... but at least give it a try!