Creating Motivation in Asynchronous Environments

I’m currently reading Leaping the Abyss: Putting Group Genius to Work, by Gayle Pergamit and Chris Peterson (who’s on our Advisory Board). The book is about the MGTaylor DesignShop process.    (2K)

Quick aside on MGTaylor: Founded by Matt and Gail Taylor, these folks have been around for almost 25 years, and are pioneers in facilitating what they call Group Genius. I had a chance to work with Gail and Matt at the recent PlaNetwork Conference, and came away in awe of their process.    (2L)

The MGTaylor process focuses on synchronous collaboration: same time, same place gatherings. Pergamit and Peterson write the following about the Design Shop experience:    (2M)

Without having attended the event — and discovered for ourselves both the costs imposed by some of our traditional procedures and the benefits that are possible within 72 hours — we would have remained curious, but not moved to action. (9)    (2N)

I had a similar experience at my first Dialogue Mapping workshop, taught by Jeff Conklin in July 2001. Prior to that workshop, I had read several of Jeff’s papers, and had come away with many interesting impressions of the IBIS grammar and the Dialogue Mapping methodology. However, those impressions were not motivation enough for me to try the process myself. One two-day workshop single-handedly created that motivation.    (2O)

I recently told this anecdote on our Collaboration Collaboratory mailing list, and suggested that synchronous collaboration was far superior at generating motivation than asynchronous collaboration.    (2P)

Is this true, and why? Are there patterns of asynchronous collaboration that excel at motivation?    (2Q)

I think it’s true. It’s simply a matter of show versus tell. When a group is sitting in the same room together, you can show whatever it is you want to show. When a group is dispersed, you can only tell them about whatever it is you want to show, and hope that they go and play.    (2R)

That said, I’m sure there are patterns of asynchronous collaboration for creating motivation; I just can’t think of many offhand. An obvious one is Tell A Friend — personal recommendations from people you trust. If my sisters recommend a book, I’m liable to read it. If my friends Justin and Cindy recommend a restaurant, I’m liable to try it.    (2S)

Grass Roots Peer Review

We had a Bay Area gathering of the Blue Oxen Associates Collaboration Collaboratory at Applewood’s Pizza in Menlo Park, California. Nine of us showed up, and we had a great time mixing and chatting.    (3P)

At one point in the evening, Brian Lincoln told Jon Cheyer his idea of Grass Roots Peer Review. They talked for a bit, and then Jon drew me into the conversation. Before we knew it, we were all discussing the idea,    (3Q)

Eventually, we started exploring a possible experiment that the collaboratory could perform. I posted a synopsis of that discussion on the tools-yak@collab list.    (3R)

A Unit Test Success Story

I spent the past few days closing out PurpleWiki bugs in preparation for our impending v0.9 release. And once again, unit tests saved my butt.    (3I)

Automated unit tests are like programming with a net. You invest a little bit of time up-front writing the test, and then you save a ton of time later. Most importantly, unit tests give you confidence to experiment. You can dramatically refactor your code without worrying about unknowingly breaking something.    (3J)

I’ve used unit tests on a number of small projects, and have been pleased, but not overwhelmed with the results. However, my experiences with unit tests and PurpleWiki have been extremely gratifying. Our unit tests have consistently caught bugs that might otherwise have stayed hidden for months, even years.    (3K)

Extreme Programming (XP) advocates writing tests before writing code. I cheat a bit here. I usually write a few test cases, write the code, then write the automated unit test. Same goes for bug fixes. More importantly, we mandate a unit test for every bug fix. If changes to the source code revive an old bug, the corresponding test will catch it immediately.    (3L)

On a related note, I ran into Chris Sepulveda, an old college acquaintance, last week. He’s been an XP consultant for several years, and he recently moved from NYC to the Bay Area. We had an excellent discussion about XP patterns and adoption. In particular, he bemoaned how narrow thinking about the methodology prevented many people from incorporating it into their processes effectively. XP is as much about philosophy as it is about methodology.    (3M)

Chris is loaded with good thoughts, and is slowly but surely sharing them with the rest of the world on his blog.    (3N)

CSS Stylesheets for EEK Speaks

I got an e-mail from Steve Iman, who had downloaded my blosxom flavours files for this blog. He said that it took him a while before he realized he needed my CSS stylesheet to make the flavour files work.    (3E)

I didn’t include any CSS files in the package, because they are publicly available from my web site. However, you will definitely need them if you want to play with my flavour files. Here are the direct links:    (3F)