This is Part 2 in a 2-Part post – please see Part 1.

Quick Recap

This post explores how a semantic wiki can support self-organizing teams, using a rock and roll band as a case study.  We developed a semantic wiki using the Symcordia™ platform to enable the band’s development and learning – both collectively (organizational learning) and for band members (individual learning).

Necessity is the Mother of Invention.

The band began as a vehicle to cover classic rock songs.  Over the first week or so, we found ourselves drowning in endless email chains, with lists of songs to cover, suggestions for band names, and so on.  I’ve always found emails to be both inefficient and frustrating as an approach to coordinating and sharing knowledge across a work group.  We were finding it tough to keep track of all the suggestions and maintain a “single source of the truth” to guide our practice and development.  We believed there was a better way, so we quickly (initially about 3 hours work) built a band wiki using my company’s Symcordia™ platform.

A band has several characteristics that make a wiki a great enabler:

  1. Playing in a band is a highly collaborative endeavor.  Wikis are inherently collaboration tools.
  2. Playing in a band demands shared knowledge:  What are we going to play?  Which key should we play it in?  Who will take which parts (e.g., lead vocal, harmony vocal)?  Wikis are a fabulous way of capturing and sharing knowledge.
  3. A band must develop and grow – or it dies on the vine.  Wikis are wonderful enablers of individual and collective growth and learning – they can put at your fingertips all that you need in terms of knowledge and tools to develop and grow – things like musical scores, YouTube tutorials, song lyrics.
  4. For a developing band, history and shared experience is crucial to learning: What did we try and why?  What worked well – and not so well?  A wiki is an ideal vehicle for capturing history and creating shared learning.
  5. A band depends on all sorts of creative decisions:  What’s the best sequence of songs for a given context?  Which settings worked best for amplifiers, mixing boards and effects pedals?  A wiki is a great way of enabling and capturing those decisions and the logic and collective wisdom behind them – one place to keep a ‘single version of the truth.’

Initial Design and Features

Given these characteristics, we came up with our initial design.  Here’s a screen shot of the wiki sidebar – a primary navigation mechanism.  Note, we’ve not yet tried to make the site “pretty” – we will eventually create a public face into selected portions of the band wiki, and use a more fancy style sheet for that:

There’s an inevitable section about the band – each member has a page where they can post personal details, photos, videos, etc.  We’ve also worked up some “principles” or “simple rules” about how we want the band to work (e.g., We encourage band members to move from instrument to instrument.)  Having these on the wiki allows us all to collaborate on developing the principles and bringing them to life.  We struggled with naming the band, so we created a space for us to develop naming ideas, comment, vote and converge on a final name.

The most important space, in terms of developing as a band, is the Band Repertoire.  As you’ll see above, there are sections for:

  • Performance Ready Songs – songs we feel are ready for performance to an audience.
  • Songs In Development – songs that we are working on with a view to readying them for performance, at which time they get promoted to Performance Ready pages.
  • Prospective Songs – songs that we’d like to perform and within our talent and limitations, e.g., if it needs a flute, we probably can’t do it (sorry, Jethro Tull!)
  • Song Ideas – suggestions about songs we’d like to try at some time.

Typical Song Page

Here’s a partial screen shot of a typical song page:

Key here is:

  • The version of the song (some songs have multiple versions by different performers – for example the Guns ‘N Roses version of Knockin’ on Heaven’s Door is quite different from the Bob Dylan original).
  • A YouTube of the song by the performer we are trying to emulate, so we’re all aiming for a common performance outcome, or at least, a starting point to develop from.
  • Links to the tablature (music) for guitar, bass, drums, keyboards and any other learning aids.
  • The key we will play it in.  (Four band members playing a song in different keys does not sound so good!)
  • Performance Notes – clues about how to perform a song, and observations on how we are doing so far.
  • Song lyrics – lead vocals and harmony vocals singing different versions of the lyrics can really spoil a performance!

Semantic Properties

Each song page has a Semantic Properties box:

In order to protect my band mates privacy, I’ve ‘faked’ the assignment of parts to be all me!  But each part (vocal and instrument) can be assigned to different band members, and we can try different assignments at our practice sessions to see what works best (and capture this in our Performance Notes).

We can also vote on different aspects of the song.  The things on which to vote change depending upon context – e.g., whether it’s Performance Ready, Song In Development, Prospective or Song Idea.  For Performance Ready songs, a question is, “How well do we perform this song?”  For a Song In Development, it is, “Are we getting better with this song?  Are we ready to perform this song?”  And for a Prospective Song it’s, “Do we want to work on this song?”

Because these are Semantic Properties, we have pages that dynamically generate reports, such as:

  • Which parts I am playing what roles on?
  • Which songs do we most want to work on?
  • Which songs are improving the most quickly – or slowly?

Capturing Performances

We capture MP3 recordings and video clips of our performances and embed these in the song pages, track and rate how our performances are evolving over time – creating an historical record of growth and learning.

How Is It Working Out?

I’m going to save my richer response to this till we have a little more experience under our belts, but there are some early insights that I’ve seen many times before with my business consulting clients as they try to leverage collaborative tools like this:

  1. Email habits die hard!  For all the frustration with email overload, and the inefficiencies and inadequacies of email for collaboration, band members’ first instincts are to send an email, which begets a natural reply response.  Good thoughts are lost to the ether and invisible to the wiki!
  2. It’s tough making time to learn – even though the learning curve for a wiki is trivial.  The late Dr. Stephen Covey talked about the man struggling in the woods to saw down a tree.  An old farmer came by and observed, “That saw looks pretty dull.  Why don’t you sharpen it?”  The man replied, “I don’t have time to sharpen the saw – I’m too busy sawing!”
  3. I know from my business client experience with wikis that they gain the most traction when their use is ‘in the natural flow’ of daily work habits.  For our band members, they tend not to sit at desks with a computer screen and a browser.  They are busy executives moving from meeting to meeting and town to town.  Their dominant means of communicating beyond their meeting context is via Blackberries – phone calls and emails – so the band wiki is not ‘in the flow.’  This will change when we release a version of Symcordia optimized for smart phones and tablets.

Lessons Learned from a Reader

I’ll close this post by pulling a comment from the Part 1 post.  The comment came from Glenn Remoreras, one of my favorite bloggers (See Simple Processes.)

Based on my experience of championing the use of wiki with my team, it was a bit of a crawl, walk run process– and we are still crawling after a month. Here are our lessons learned:

  • Adoption champion is critical to success of the process. (I took this challenge myself as the manager of my area). As champion I generated initial contents and encourages to channel collaboration through the tool by suggested practices.
  • Different team members will have a different level and pace of adoption. That’s normal and acceptable. I did not force my team to use the tool, I slowly introduce it in our meetings and reporting.
  • Leader’s example is important. The leader spearheads the different ways to use the tool by doing it himself/herself. Later on the team will realize the benefits by experiencing how it changes the way they work.
  • Crawl walk run approach is necessary to not force the team adoption. Team members will adopt when they realize that it actually facilitates better flow of information and better team collaboration. Don’t rush it!
  • Subsequent and consistent use of the information in the community (wikis, blog, forum, file sharing) for information purpose to outside entities strengthens importance and drives team members to adopt.

My team is getting there collectively. Now we are managing some of our project status reporting, meetings, team locator, activity-task assignment, forum, and file sharing through the team community we have established.

Disclosure

My company is centered around a semantic wiki platform – currently optimized for IT groups (see Symcordia.com for more) so I do have a few axes to grind.  But I’m also a true believer in wikis as an enabler of collaboration and performance improvement. This is based upon my experience as a consultant and our client’s experiences using Symcordia™, our semantic wiki platform.  The platform is built on the underlying Confluence wiki engine, with a variety of plug-ins that add semantic properties, sortable tables, page ratings and so on.

Image “Classic Rock” by C.F. Payne courtesy of Reader’s Digest

Enhanced by Zemanta