This Month’s Pattern *

75 Fridge Door

Team members routinely display their work products for all to see.

You often hear about the “need to know” principle from managers: Pass to other people only what they need to know to perform their jobs; do not communicate information unless it is absolutely necessary for the task at hand; restrict the information flow to the bare necessity. The Fridge Door pattern defies this advice, and yet correlates strongly to successful projects. Here’s how it works: Even though it is not vital for everybody to know everything, the team displays significant information in a highly visible form. It’s in places where everybody on the project team is sure to look—when entering or exiting from the office or the project war room, or on the way to the coffee machine or the rest rooms. Some of the information can be updated—by almost anybody—in a casual way, with pencils and colored markers left for that purpose. These displays are living documents that contain important status and structure information. Healthy teams share artifacts such as the following, from different roles in the project:

  • a release plan
  • work assignments for the week or for the current release, so everybody can see who is on what task during a particular period of time
  • burn-down charts or any other form of progress report in an easy-to-grasp representation

The following requirements artifacts are often shared:

  • the context diagram of the system, so everybody can see what belongs in the system, what is outside, and where the interfaces are.
  • the list of use cases (or the use-case diagram), most often a one-page overview of the processes to be supported by the system. We often see it color-coded by stage of development of the process; for example, red for “planned,” yellow for “under construction,” and green for “done.”
  • a matrix of use cases versus domain classes (a sort of high-level cross-reference list matching domain entities to use cases).

Software architects often display the top-level structure of the software system—for example, the twenty most important components and their relationships. This is not to be confused with the slick presentation slides created for marketing purposes. It’s the real structure that architects are working with, and you’ll see a few hand-drawn corrections about new dependencies and some red question marks about unwanted dependencies.

Testers often proudly present overviews of their test cases and the coverage they are achieving with them. Even someone who is not part of the QA sub-team can get a pretty good understanding of how his work is affected by QA and testing.

Visual displays like these offer all project members an editorial opportunity to present what they care about and what they want others to care about, too.

    “With information radiators, the passersby don’t need to ask questions; the information simply hits them as they pass.”
    —Alistair Cockburn, Agile Software Development (Reading, Mass.:Addison-Wesley, 2002), p. 84.

A public display of project artifacts indicates trust among the team members; it sends the message that nothing is hidden for merely arbitrary reasons. There is no fear of having others detect incompleteness or schedule slips. Team members on fridge-door projects are substantially less inclined to “spin” or sugarcoat their progress reports.

The fridge door also saves on ponderous version management and document distribution. Many of these displays are updated on the fly and thus give up-to-date status information to everybody.

Walking down a corridor, you may see “We just improved the name of the interface to the accounting system, to better reflect the fact that it is not discrete but an online stream of information.” Around a corner, you may see another posting: “Did you see that the latest requirements change has thrown us back by 4 days compared to yesterday’s sprint plan?”

There is something very natural about fridge-door displays. Shared artifacts not only demonstrate pride in achievement, but also provide the “you are here” function for projects, literally keeping everyone on the same page. Compare this to a culture that sports motivational posters adorned with mountain climbers, rowing teams, galloping white horses, and a tired variety of feel-good phrases.

Where would you prefer to work?

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Brussels, Mastering Business Analysis
10-Jan-2017 to 11-Jan-2017

James Robertson teaches Mastering Business Analysis. Contact IT Works for details of this course.  

Brussels, Mastering the Requirements Process
21-Feb-2017 to 23-Feb-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works

for details. 

Oslo, Mastering the Requirements Process
21-Feb-2017 to 23-Feb-2017

Suzanne Robertson teaches Mastering the Requirements Process. For more information on this popular course, contact Den Norske Dataforeningen.

London, Mastering the Requirements Process
14-Mar-2017 to 16-Mar-2017

The Spring edition of Mastering the Requirements Process with James Archer. Please contact IRM UK for details.

Brussels, Mastering Business Analysis
22-Mar-2017 to 23-Mar-2017

James Archer teaches Mastering Business Analysis. Contact IT Works for details of this course.  

London, Mastering Business Analysis
28-Mar-2017 to 29-Mar-2017

James Archer presents Mastering Business Analysis. Please contact IRM UK for details and registration.

Rome, Mastering the Requirements Process
3-Apr-2017 to 5-Apr-2017

Rome, Mastering Business Analysis
6-Apr-2017 to 7-Apr-2017

James Robertson teaches Mastering Business Analysis. Contact Technology Transfer for details of this course.  

Hilversum, Mastering Business Analysis
10-Apr-2017 to 11-Apr-2017

James Archer teaches the popular Mastering Business Analysis. Details from Adept Events in English or Dutch.

Stockholm, Mastering the Requirements Process
9-May-2017 to 11-May-2017

Brussels, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details. 

Hilversum, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Archer presents Mastering the Requirements Process for Adept Events. Details and registration: English - Dutch.

in depth

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Take a look at Tom DeMarco's Risk Management for Dummies article, published in CrossTalk.

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.