Blog LogoBlog Logo

Creating an informative workspace

23 Jun 2007 ~ 5 min read


Earlier this evening Agile Scotland ran a presentation by Rachel Davies* called Creating an Informative Workspace which I found really interesting. The basic idea is that you permit developers to define their workspace to ensure that communication improves. The “Informative Workspace” is concentrated around “Big Visible Charts”. The following is a write up of my notes from the presentation.

The idea of the Big Visible Chart is to communicate the plan, the progress, the test results and the domain model. This is simply becuase it is too much information to be able to keep it all in our heads at once.

At the smaller end of the scale are the charts that each team member puts in their own space. These charts contain information that the individual developer finds useful, however they remain visible to all who want to view them. They become “Information Radiators”. That is, they radiate information so that other people can see the state of things without having to actually interrupt the developer. It is well known that an interruption that maybe only lasts a few seconds has a knock on effect as the developer then has to get back into the topic that they were concentrating on in the first place.

It is important that the developer is careful about what they present. The chart needs to be understandable so that people don’t go away with incorrect ideas or have to interrupt the developer. It also needs to be readable from a distance.

The team should be permitted to maintain their own space. Management should not bog down the developers’ charts with information that is not useful to the developers. If the information is not useful to the developers then it will distract them from the job at hand.

The team could, for example, use a team wall with lots of index cards pinned to it. Coloured stickers could be added to the cards that increase visibility and add information that can be easily spotted from a distance. At the more high-tech end of the scale a plasma screen could be used to display information such as the build results from cruise control.

The Big Visible Chart should also include the “big picture” so that everyone is reminded of what is being worked towards.  For instance, a scrum burn-down chart could be included; timelines to show what had been done and what is still to do; putting up the release date of the iteration and showing what is in the release and what is not.

All the information on the charts are a form of feedback that can be used to modify actions to keep everything on track. However, be aware of too much feedback which will overload the developers with information. If there is too much noise then people will filter it out and valuable information will not be recognised.

The process of creating the charts and defining what is put on them should be reviewed periodically throughout the project. It is important to have a “retrospective” meeting to discuss what went well, or not well, or is just puzzling. Update the charts as a result to ensure that the best infromation is available. These meeting could be about once per month, and the length could vary from an hour to an afternoon.

In the retrospective meeting do root cause analysis. Sometimes the process needs to be rethought rather than just speeded up as the observations made might just be a symptom of a deeper problem. Also, be aware of focusing too much on one problem because it is often possible that by moving another part on the solution to the problem becomes more apparent.

Getting positive feedback to developers is also important. If a developer can find out how useful they system they are building actually is to the users, or how it has benefited the business it can increase moral and improve productivity.

Some teams have mood indicators on their Big Visible Chart. This works well for indicating the mood of individual developers, however it isn’t so good at showing the mood of the whole team.

Since the majority of Big Visible Charts are paper based systems and have to be updated manually it is important to ensure that it is updated regularly. For example, there could be a daily standup meeting around the big visible chart where it is reviewed and updated. It is important that when information is no longer relevant it is removed.

NOTE: This was rescued from the Google Cache. The original date was Tuesday, 26th April 2005.

🔄 Follow up footnotes - 10th August 2026

* Some of the original links on this post have since died, so the links now take you to the way back machine. It is an increadibly useful service run by the internet archive. You can donate to it here.


Headshot of Colin Mackay

Hi, I'm Colin. I'm a software engineer with over 30 years of experience based in central Scotland, specialising in Microsoft technologies, initially with C++ and then in C#. I was a Microsoft MVP from 2007 to 2010 and a Code Project MVP from 2005 to 2009.