Clever Hamster

Lean SCRUM: pruning away estimation

Worth reading is an article recently posted on InfoQ, called The Current Direction of Agile. Jon gives an overview of how Lean philosophies are influencing agile methodologies, toward a tighter, sprier, lighter process. These are the lean approaches that interested me:

• Equal Sized User Stories: Rather than spend time estimating stories, force stories to be of all equal (fixed) size; then teams can confidently take on the number of stories their velocity supports without much analysis. The smaller the story, the better:  larger stories have more unknowns (risks) and so are less managable.
• Naked Planning: Stop estimating, and perhaps stop planning and iterating, too! By managing a short queue of Minimum Marketable Features (MMF’s), listed in priority order and comprised of same-sized stories, the development team can simply pull stories off the list in order. When enough history is accumulated, it becomes easy to answer, "When will that be done?"
• Kanban: Toyota-developed Kanban ("visual board") is taking the Agile team's sprint task board to the next level, tracking the flow of the entire development organization in terms of release cycles, visualizing the movement of features into deployment queues. This big picture answers "Where are we?" for all to see. Here's a great cartoon model.

Zinepal: On-demand magazine formatting of online documentation

A long-time wish for many of us building and using online documentation is how to grab only the portions we want and have it lay out well for print production, handouts, quick references. A new tool, Zinepal ("magazine pal"), attempts just that: it lets you create your own PDFs -- and even schedule daily rebuilds -- from online content. In an email, Zinepal staff claimed that 1-column layouts would be a quick enhancement, that the easiest way to leverage this tool for documentation is to set up RSS feeds exactly the way you want content to be grouped, and that more integration options are in the works. But as it stands today, it's a compelling example of how to give documentation producers and end users the power to build exactly what they need from online content.

I think it's most important to show just how well and easily this "user as editor" approach works. In this example, pointing Zinepal to my blog enables it to detect the feed; from the feed, I can select exactly those pages I want:

The real power is in the next page, where you can customize the output and save those customizations to a template:

Many output formats are available:

The front page can be customized with rich text and saved to a template:

Here is a sample of an internal page

A powerful approach to solving an ever-growing need to customize information delivery! Thanks to Melissa Burpo for finding it.

Porting documentation to wikis: problems and possibilities

Curious about whether methods yet exist to easily port legacy documentation to wiki format, I looked around and found this screencast about WebWorks ePublisher's wiki publishing feature. ePublisher outputs to two wiki formats:

• MoinMoin Wiki
• MediaWiki (which has the richer text formatting of the two)

Good: Word

A strength of ePublisher is that it manages Word source as well as FrameMaker source, which is important for several reasons: tremendous amounts of legacy documentation is sourced in Word, most Help authoring tools output to Word, and Word is a good environment for macro-driven processing of such content, to prepare it for the wiki.

Bad: Security

However, wikis themselves have serious downsides for use as documentation. For example, if you're counting on being able to draft and stage content on the production wiki for a future release, most wikis lack the security you'd need to accomplish that. Yet popular wikis have endless numbers of extensions and plug-ins; here, for example, is a security extension for MediaWiki:

• MediaWiki Extention: SimpleSecurity

However, the page opens with this warning:

If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data. We are not responsible for anything being leaked, leading to loss of funds or one's job.

Better: Wiki with content management

But not all wikis are created equal, and there are hybrids that combine aspects of wikis, content management, and document management systems. Joomla!, Drupal, and Confluence are examples of these. The good news with WebWorks ePublisher is that the new 9.2 release includes wiki output support to Confluence, which is a market leader in wiki-based technical documentation. This ePublisher release supports Confluence across these features:

• Publish and deploy
• Standard wiki markup
• Supports CSS and complex tables
• Wiki category markers

Since Confluence supports the ability to organize content by release version and control page-view access categorically, it is a platform that many technical publications could move to with success. Given Word source, ePublisher should be able to get an organization to Confluence in one step. I hope to find someone who's done it!

Update: Import Word directly

I found this forum thread: http://forums.atlassian.com/message.jspa?messageID=257313202

According to this, importing Word documents directly into Confluence seems the easier, softer way, that's much like importing Word source into Author-it:

"Use the Doc Import feature offered with the Office Connector. Doc Import offers an array of choices when importing. Large documents can be split based on the outline feature used in Word. You can import the Word document to become a wiki page."