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.
Hmmm. I read this and I can’t but help thinking that it’s pop psychology coupled with poor information management. The worst thing about information, when working in a group, is that everyone expresses it differently. There’s a lot to be said about consistent approach, legibility, etc. That’s why the team lead should be the one orchestrating this stuff.
A lot of this is a rehash of the classic ghant chart showing milestones, who’s working on what, critical paths, who’s accomplished what, etc.
I guess the thing I’ve never understood about XP is that “they”, the XP proponents, feel they have to come up with all sorts of goofy communication tactics, like “scrum” and “mood indicators”.
XP is not a “one size fits all” solution. Nothing really is. This “Big Visible Chart” idea, sure, is a tool, in fact it’s something I’ve employed before XP was even invented. It’s not appropriate all the time though. Sometimes it can be a big time waster.
In my book, a better starting place would be to take the existing management tools and figure out how they need to be tweaked for the particular team makup, project requirements, and management style.
My 2c. Yeah, I guess I’m pretty opinionated.
Hmm… I guess i go more for Little Visible Tables. Gobs of ’em, tacked all over my walls. Get the colors and layout right, and i can pick out what i’m looking for just by turning my chair, no leaning necessary.
Oh, well, this doesn’t really do anyone else much good, but… by the time someone is standing near enough to my cube to read anything, they’re probably already asking me.
That said, having a great big whiteboard around can be a very handy thing on occasion.
XP is not Scrum. They are both different ideas within the Agile movement.
XP has never said it was a one size fits all. A common theme in the Agile movement is picking the correct methodology for the project. That is partly why it should be the team that chooses their workspace. Also, you said it should be the team lead that orchastrates “this stuff”. Remember that the team lead is part of the development team. It is important to get feedback from the team otherwise the developers in the team will feel that their ideas are not worth anything. If after some discussion some ideas get left at the side then that’s fine, at least the team thought about an idea and weighed it with the goals of the team. This is as much about moral boosting as it is getting information efficiently over to developers. If the information is no use to the developers then it is waste (another part of the Agile movement is Lean Development which seeks to eliminate as much waste as possible)
The problem with Gantt charts is that they become out of date very quickly. Especially as the project moves on and new information comes to light as the client is actually coaxed to ‘fess up about what they really want rather than the vague fuzzy requirements they came out with in the first place.
The “Big visible chart” is just a tool, I quite agree with that, and if I suggested otherwise then that was not my intention. It should be used along with many other tools.
Yes, Marc, you are opinionated 🙂 But that is good, because now I have to try and justify myself rather than just blindly accept what the presenter’s viewpoint.