I had my first Open Space experience Thursday night at the Agile Iowa user group. It was a great new experience in performing meetings, and it was one of the few times where I’ve been in a meeting where I was actually engaged and getting something of value through the whole meeting.

The two hour meeting consisted of the following:

• 6:00pm: Pass out sticky notes, where anyone in the group can write up a topic for discussion. For example, members of the group brought up topics like “Agile Adoption Across Non-Agile Companies”, “Agile Metrics”, and “Promoting TDD Among Non-TDD Developers”, to name a few. (This actually only took about 5 minutes. We spent the rest of the time touring the Iowa Student Loan facility to see how they had changed their environment to promote agility.)
• 6:15pm: The leader/facilitator collected the stickies and posted them to the board. Each member was allowed two votes toward their top two topics of interest. After everyone had voted, the top four topics were selected.
• 6:30pm: The first set of sessions begins. Two of the four topics are chosen for discussion. Each session is designated a room. Members get up and go to the topic session they are interested in. During the session, one person takes notes based on what was discussed.
• 7:00pm: The second set of sessions begins. Members move to the next session they are interested in and sit down for discussion.
• 7:30pm: Re-group with the rest of the group members. The person who took notes at each session provides a summary of what was discussed, for information-sharing. (We actually didn’t end up doing this, as the second set of sessions went long. This is one thing I wish we would have done.).
• 7:50pm: Hold a retrospective with the entire group. Each member is able to provide input on what went well / what didn’t go well with the Open Space, so that changes can be made to make the next Open Space better.

Now, I’m not suggesting that we all go out and start converting our traditional meetings to Open Space meetings (well, you can if you want…). But it is always good to look “outside the box” from time to time, and try new things.

In the workplace, I see this providing value as an information-sharing / idea-gathering opportunity between co-workers in the office. For example, if you have a problem with “silos” (e.g. teams doing their own thing, not knowing whether other teams are doing something similar), hold an Open Space. And recommend (or mandate) that team members go to different sessions to promote cross-team collaboration.

InfoQ posted a pretty good interview with Jeff Sutherland over what qualifies a team as actually doing agile (Scrum, specifically) rather than just going through the motions.

Particularly, he addresses some of the disadvantages of merely piecemealing agile practices into a traditional team development environment.

E-mail is a heavily-utilized communication tool in the workplace. We all use it. Many of us have spent countless minutes (or hours) customizing our signatures, fonts and colors. Some of us even update our signatures regularly with little quotes or anecdotes.

But e-mail, while a great communication tool, has led to great inefficiencies in the workplace.

When I draft an e-mail at work, I typically want to make sure it goes out to all interested parties; therefore, I usually send or CC it to one or more e-mail distribution lists. Often, a couple recipients will exchange a few Reply-All’s back to the group to discuss a few details between each other, in essence filling the Inboxes of the other recipients with unnecessary e-mail trails. This happens a lot at my job. I get tons of e-mail, some of which I care about. Some is just informational, or FYI. But each time, I am pulled away from whatever task I am working on to check my e-mail just in case.

Case in point: I sent an e-mail to my team’s DL regarding a question about some server configurations that needed to be applied to one of our vendor products. Obviously, it wasn’t necessary to send it to the whole team. In reality, it only needed to go out to the admin and probably my team lead. The developers could have cared less. But I wanted to make sure they were aware of it in case they had issues with their software.

This is where a practice like Daily Meetings has huge benefits. At these daily, 15-minute meetings, each member of the team has the opportunity to mention what they have been working on and bring it to the attention of the group. Keep in mind, however, that further discussion between a subset of the group should not occur during the meeting (since that would lead to the same inefficiencies as the mass e-mail distribution); instead, hold a separate meeting/discussion immediately following the meeting.

(Note: While drafting this post, I found it ironic that I got a “Mailbox is over its size limit” message from the Exchange Server…)