A key agile principle is to do the simplest thing that could possibly work.  So it seems paradoxical that as Agile grows, so does the number of increasingly-complex tools to manage the process.  Yet a great way to manage Scrum artifacts (backlogs and burndowns) remains the simple wiki.  To this end, ComSwiki has worked well for me, as it is lightweight, flexible, and fast.

But new corp-rat standards require that I use SharePoint to the degree that “if it’s not in SharePoint, it doesn’t exist.”  So I had the admins create a SharePoint Wiki for my team, and started filling it up with backlogs, how-to’s, and other content.

Frustration soon followed as simple editing often requires deleting text and starting over.  The SharePoint Wiki’s WYSIWYG editor (only available in Internet Explorer) tries to be useful, but often just gets in the way.  For example, try adding a row or column to an existing table: it can’t be done.

Not to be deterred, I turned SharePoint’s limitation into a feature.  The WYSIWYG editor doesn’t work in Chrome and instead pops up a simple text box with the raw, ugly, generated HTML.  Yet I can edit this HTML to do things that the WYSIWYG editor won’t.  So, I now typically keep both Chrome and IE open on the same page and switch back and forth depending on what sort of editing I need to do.

It’s a stone-age approach, but then again, SharePoint is a stone-age tool.  Hopefully, the WYSIWYG editor will be improved and expanded in future releases, but until then, it would have been better for Microsoft to take a “simplest thing” approach.  That is, support the simple markup language of ComSwiki and other wikis rather than attempt a (mostly broken) WYSIWYG editor.