WARNING – Methodologies and dogma
Agile purists will be upset by parts of this article but if they thought about it long enough they would see the irony. Coding Futures is not an “Agile” development house; we make extensive use of parts of the Agile methodology but we do not stand on street corners, we have civilised meetings with tea and if they overrun by a minute or two so be it. Consequently this article is not a “How to on Agile” it’s simply a “How we do it” article. It works for us and may work for others.
Update 29th March 2012 by Claire: Since we originally posted this article we have had a lot of feedback, including some great stories of people using variations in unusual locations from hospitals to legal practices. It’s been sometime since we wrote the original article so we have added an update about what we are using now towards the bottom.
What is a information radiator?
The term Information Radiator was coined by Alistair Cockburn in his Agile Software development framework, though many people, even those using other methodologies such as prince2, will be familiar in part with the idea. An information radiator is a display of all the current work and backlog. A simple radiator can be split into 3 or 4 sections:
- Not in Progress
- In Progress
Though how and what you display is dependent on your needs. I have seen many variations, the second most common being 5 columns as described by Agile Advice:
- In Progress
- Roll Out
As a small office we have a single radiator but often companies will have radiators per team, with some sort of company based one. The key is that the radiator is somewhere people will see it, either on a wall or a major part of your dashboard and while it can be virtually anything, it needs to be easy to update and be prominent enough that it gets eyeballed by staff routinely. If your radiator is hiding on your intranet somewhere unlooked at and unloved then it’s probably in the wrong place.
The office information radiator
Coding Futures information radiator is a tad more complex than most, and has been designed around specific needs of a small development company. It is divided into 3 general categories
- In Progress
Backlog is where all the current open ideas/projects/tasks go. Big or small everything starts in the backlog and at any one time there can be dozens of tasks in the Backlog. To help manage the priority order a special section in Backlog is created called “Queue”, this has 8 numbered slots and forms the basis for which tasks need to go forward quickly. It’s worth keeping in mind things go back into the Backlog whenever they are deemed to not be in progress and not completed. There is no shame in something returning to the Backlog in our office!
Is split into 4 sections:
- With Client
- La La Land (aka purgetory)
Active is divided by members of the Developer team. (We also put Glenn on their but mainly so he doesn’t feel lonely.) Each member has his own mini queue allowing in one glance for them to see what they are curently working on. Like the Backlog queue these are numbered (1 through to 4) allowing a developer to be working on up to 4 tasks at a time. If a task is not worked on within a short period/a couple of days it returns to the Backlog. As tasks often interlace it’s quite common for a developers primary task to change but a secondary or tertiary task to be still on the board.
QA is done by all the team, as we don’t have a dedicated QA person however while anyone can put a card into QA it needs to normally be signed off by Tim before it leaves QA, either heading into completed/with clients or back into the Backlog if issues are found.
With clients is still considered an in progress task until they sign off on user acceptance and or deploy onto a live site (at which point we assume sign off). From with clients, the card can move either forward or back to the Backlog.
La La Land occurs when a client has signed off but has yet to use the task, it’s kept in progress as almost certainly there will still be snagging involved. We find a lot of tasks end up in La La Land for a short period. If a task spends too long in La La Land then it’s a good indication of issues with the project in general and provides a simple flagging mechanism (though normally there are many other indications as well).
Our Completed is split into 3 sections:
- Deployed by Us
- Deployed at Clients
- Other but good
Items remain on the completed list until the end of a given sprint, at which point they are removed and the card filed and stored with the date it was taken off the wall written on to the card. The lead dev on the task having the “honour” of signing it off the wall.
Tim and Barry processing the wall after the end of a sprint
We use a very simple system for our Radiator, a large wall in our office, lots of masking tape to create a grid (as seasoned Bar Campers we have lots of experience making grids) and use plain white postcards and blue tack for our card deck. It’s low tech but highly effective. However we have recently been experimenting with working on an electronic version using CodeBase project as a backend.
Building a simple radiator using CodeBase
While we primarily use the wall as our radiator we have experimented with using an electronic radiator. As CodeBase is the centre of our Development world in the office, it made sense for us to build our Radiator within it. Unfortunately CodeBase project management aspects are, while good, not flexible enough for us to extract tickets from various projects and attach them to a Radiator. Instead we created a new project.
The project has custom Statuses, Priorities and Categories.
Categories are simply a list of current active projects. The list is updated by hand as unfortunately there is no API method for creating or updating Categories, Statuses or Priorities of a project.
Statuses mimic that of our traditional Radiator wall, mostly with:
- La La Land
- With Clients
- Deployed by us
- Deployed at Clients
- Other but good
All the statuses are grouped and colour coded by which column they would appear on the wall normally. In addition there are two extra statuses:
both are considered closed. While rare, occasionally a ticket will be deemed not needed or invalid and as such is “Removed”, while at the other end of the spectrum “Completed” is the equivalent of signing off in our physical radiator. Both tickets are marked as closed within Codebase.
Priorities – A simple list of 1-4 priorities with a fifth priority of “none” which is the default.
Basic Process flow
From project management side the flow, goes something like this:
- A ticket is created. If it references tickets from other projects then it links to them (this does mean we occasionally have near duplicates) and assigned a status of backlog with a priority of none and normally no one assigned.
- Developer (or lead in group element) picks task from the radiator and marks as active and assigned to themselves, they then assign the referenced tickets as needed.
- Developer pushes the ticket either back to backlog (though still assigned to them) or to QA depending, if going to QA normally ticket user assignment goes to Tim
- Person assigned at QA pushes ticket to BackLog or to Clients/La La Land/Deployment
- Circle repeats
- After Sprint tickets in Deployment or other which are deemed finished are marked Completed and removed
The nice thing about Codebase is that with a single call to the API you can retrieve all tickets for a given project excluding Complete and Removed statuses using:
Once you have the tickets it’s trivial to build a radiator interface. You can even create some fancy jQuery drag and drop with a call to update the tickets if you want to get really clever.
Their are several advantages to an electronic radiator:
- Easy to update in real time
- Ability to pull in extra data and cross reference
- Can push data to other services (for example all active cards of a user can be turned into a Capsule task)
- You don’t accidentally write on your wall with marker pens instead of the masking tape you were aiming for … oops
However the key reason for using a radiator is for it to be seen and updated. People can concentrate on a physical radiator much more easily as they are passing for coffee, and there appears to be a psychological boon (at least in our office) in moving cards around on the board and ultimately signing off and removal. So, for the time being, we will be keeping the low tech version but will continue to experiment with its high tech version, especially as we start to rewrite our dashboard system.
Update – How we use Information Radiators – Going Digital!
The old radiator…..
The wall based radiator worked really well. But it did cause some problems. First, it left marks on the paint. Reading handwriting also posed a bit of a challenge. Lastly, we couldn’t use it while we were away from the office.
We realised we were outgrowing our analog radiator and needed to go digital with our planning, but how? Do we code a radiator ourselves based of our Codebase expertiment, or try to find one off-the-shelf?
The shiny, new radiator!
We ultimately decided to go with an off-the-shelf product, called Trello. It’s an online board management system that allows you to add boards for your projects, add cards to each board, and assign the cards to team members.
It’s a simple way to assign tasks, separate projects, and keep them on track. It also allows users to see what stage a project is at and who it’s with. This is great if you have multiple projects on the go that are all at different stages, with different people.
So, what does a Trello board look like?
Here’s an example of an information radiator we made using Trello.
As you can see, all the sections we used previously are still here. Each column contains cards, which could be a client name, an article you need to write, an invoice that needs to be sent, an image you need… whatever you need to do.
The most useful aspect of a digital radiator is that multiple users can be assigned to one card, without having to replicate the card. This is essential for tasks that requires input from different team members. You can also add comments on each card, without running out of space on the card!
There’s a ton of information on the side of the screen. You’ll see who is involved in each project and a list of recent activities, so you know what’s changed since you last logged in.
One downside is that with fixed columns we do not have the same flexible “groups” of columns we had with the original radiator this can be overcome with colour coding.
Regardless of if you are going Analog or Digital information radiators provide a simple but very effective way to manage tasks within any size organisation and not just software companies.
Please note Coding Futures is not affiliated in any way with the makers of Trello or Codebase.