Artifacts of Agility
I've consciously skated past the task of placing Informative Workspaces in its proper place in the conceptual and historical hierarchies of software design methodologies, but I should at least acknowledge that Informative Workplaces is a concept developed in the context of the Agile design methodology. It presupposes many of the aspects that characterize Agile development, including the emphasis on pair programming and a high degree of interaction among team members and test-driven development. If you're not doing Agile development, you may have to translate some of the terminology and even some of the ideas in Informative Workspaces, but you should still find a lot in it of use. And it seems to me that, despite the protestations of the purists, many development teams pick and choose elements of these carefully constructed methodologies and throw out other elements and end up with their own team-specific or project-specific methodology. And if it works for them, why not?
So what's the experience of working in an Informative Workspace? You may have noticed a recurring theme in some of the Informative Workspace details described here: a sense of fun, of whimsy. Those lava lamps, for example. It turns out that the pair of lava lamps is an excellent feedback device, because it provides a clear and unambiguous signal without being obnoxious. And they're sort of whimsical, which also turns out to be a highly desirable feature of a work environment, at least according to a lot of the people who have implemented Informative Workspaces.
So does it get the job done? What's the verdict on Informative Workspaces and productivity?
At first, it seems odd that for a discipline that emphasizes testing so much, there is little more than anecdotal evidence for the discipline's success. But in fact, it's hard to imagine how you would construct a scientific study to compare two different software methodologies. Could you actually assign programmers randomly to experimental groups, give each group a methodology to use and a months-long project to tackle, and observe their results? Sounds a little impractical, but anything short of that will run afoul of self-selection bias or other experimental design problems, it seems. And then there's the problem of defining success. One goal of Informative Workspaces is programmer satisfaction. That, at least, is not only measurable, but Darwinian: If IW makes programmers significantly happier and programmers have any say in the methodologies they use on software development projects, IW will grow.
And there is evidence that Informative Workspaces make programmers happy. A Canadian researcher (Elizabeth Whitworth, "Agile Experience: Communication and Collaboration in Agile Software Development Teams," Carleton University) talked to a sizeable sample of Agile and nonAgile developers and found that Informative Workspaces as an element of Agile development "was seen as truly motivating, [with] team members... more likely to exhibit a strong sense of pride, purpose, and excitement in work."
And that can't be bad.
