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.
Funny, in direct proportion to the number of scrums one has endured:
Rules of SCRAM
The decision came down yesterday: our latest Agile/Scrum project will have to produce some rigid waterfall SDLC artifacts. We’ve enjoyed a “bureaucracy break” for awhile, choosing things like simple wiki pages and working code to manage and communicate designs, test plans, sprint backlogs, and the like. But now we’ll have to use some (verbose and redundant) standardized Word document templates for requirements/SRS, designs, code reviews, test plans, test cases, etc.
It isn’t the case that waterfall is “all bad” and agile is “all good”; rather, it’s easy to forget the motivation for each. First, keep the paying customer happy, then place the emphasis on elegance and “the simplest thing that could possibly work”, and then let form follow function. Whether the deliverable is a wiki page, Word document, Visio graph, UML diagram, EA model, xUnit, script, or code, pick the best tool for the job. But don’t, for example, use outdated templates simply for standardization’s sake. The mindset that emphasizes style over substance is the same one that measures lines of code rather than capability: increasing bulk without adding value.
I sometimes have to combine waterfall and Agile techniques to keep multiple stakeholders and competing interests satisfied. And it doesn’t have to degrade to “agilefall” or “wagile”; there are ways to successfully blend the two. For example, go ahead and develop a high level multi-sprint plan and stuff it in Microsoft Project if forced to. But only define sprint goals and high level content in advance. Don’t pretend you can predict detailed tasks six months in advance; rather, plan each sprint as you get to it and fluidly adjust the backlog as needed. Go ahead and write that big spec and design document (to satisfy a contract or pre-paying customer) before starting your first sprint; just use a lightweight change control process to quickly include new discoveries.
I suppose “agiley waterfalling” is like running a chute: you plot out your course and pretend you know exactly how you’ll do it. But the details of the run will be a wild blend of surprises and adjustments, with some boofs along the way.