STC 2008: Day Three, June 3

June 3, 2008

Today for me was mostly split between two types of events, talks about Agile development techniques, in particular Scrum, and two “progressions.” To take the latter first, progressions were a new concept to me. A progression is held in a room with several large tables, each of which has a moderator with a particular topic. Over the course of a one to two hour progression, participants cycle through 1-4 tables, and have a short conversation with the moderator and other participants. It’s a bit like the conference version of “speed dating,” without the fear of rejection.

I ended up at three tables over two progressions, covering topics from Marketing yourself as an independent consultant, to Managing in-country translation reviews, to Managing Virtual Teams. I found the progressions a good way to network with experienced pros, though there was less prepared material than I expected. Still, I made some good contacts and got some good ideas.

The two Scrum talks, Scrum: An Agile Approach to Managing Content Projects, by Julie MacAller of Microsoft, and Agile Development: Challenges in Transforming TechComm Departments, by Mike Wethington of Troux Technology, provided a nice overview of Scrum. There’s no space here for (nor are you likely to have the patience for) a full description of Agile methodologies or Scrum, but here is my best understanding of the Cliff Notes version based on a grand total of two hours of talks. Skip ahead if you’re familiar with Scrum.

The base of the methodology is the Roadmap, which is a high level, long term, multi-release plan; the sample Mike Wethington showed was just one page. Releases are implemented through a series of Sprints, each of which is a 2-4 week cycle. The planning process generates a backlog, which is the list of all the work being done on the project. The granularity is such that any writer will implement around 10-12 backlog items over the course of a 2 week sprint.

There is an initial planning session for each sprint that selects the backlog items that will be implemented during that sprint. The items may be design, implementation, documentation, or testing; in short, if it’s not on the backlog, it doesn’t exist. Over the course of the sprint, the full team meets every day for a short (15 minute max) meeting (called a scrum) to discuss: 1) what was accomplished in the last day, 2) what’s next, and 3) what’s standing in the way. When the team gets big, these meetings may be split, with a representative from each scrum attending another (still only 15 minute) scrum with other representatives.

Sprints continue until the release is complete.

The basic idea is to build a visible, inspected, and adaptable process. Key to making the process work is quick turnaround and resolution of issues, plus open communication among all committed parties.

Unlike some methodologies, Scrum gives documentation a full seat at the table. In Scrum terminology, there are Pigs and Chickens, as in “when you make ham and eggs, chickens are interested, but pigs are committed.” The committed (pigs) are the core of the team and are all central players. Technical communicators are considered pigs, along with developers and QA (quality assurance).

Some of the keys to making scrum work, according to Julie and Mike, are:

  • Make sprint goals customer focused, grouping detailed topics into customer “stories”
  • Pick the right moment to start writing. There’s a tendency to get started too early, which can be a real problem with a fluid process.
  • Get every work item on the backlog, including reviews and SME interviews.
  • Keep processes lightweight; since you report status daily, formal tracking can be lightweight.
  • Make sure daily scrum meetings are with development, and not separate.

Overall, I found scrum to be an intriguing methodology. I’ve managed writers who have used earlier incarnations of Agile methodologies, including spiral development, which is similar, but with longer cycles (more on the order of 6 months), but this is the first time I saw this kind of methodology as offering a significantly better way of doing things.

One final note. The second talk, by Mike Wethington, resembled a scrum. There were constant questions, and the talk evolved based on the questions. In a sense, each slide was a sprint, with frequent questions and discussion. I think this was not by design, though Mike was receptive to questions. Rather, it was just a result of participation by several folks who resonated with the ideas, and were assertive. In fact, I wonder whether a side benefit of this methodology is to encourage more assertive behavior on the part of technical communicators.

The one talk that didn’t fall into these categories was Creating Task-based Navigation with DITA, with Mike Priestley of IBM and Amber Swope of Just Systems. They gave a good combination talk/demo on creating task-based navigation using an application called Task Modeler, which is beta software available from IBM. This application uses a GUI to let you build a DITA application, including the ditamap, relationship tables, and topic groups. It was nice to see these two skillful presenters put together a nicely integrated and interactive presentation.

My only reservation was a claim that DITA is “ridiculously cheaper” to customize than a custom schema. One company (Nokia) found that changes took 50% less time for DITA, and would have been even better if you didn’t count the planning time. While I’m sure the difference is significant between DITA and a custom schema, the comparison I’d like to see is DITA vs. DocBook. I would not expect to see nearly the difference. However, this demo did show that the tool support for DITA is improving quickly; the Task Modeler is a very nice application that I expect will become very popular.

That’s all for now.



  1. Great entries from the conference. Thanks for putting these together, it helps me feel like I got a little more out of the conference just by reading them, even though I too was there. đŸ™‚

    Found these because you tagged them with stc2008, so I will tag mine as well. Good thinking!

  2. Richard:

    I hope my session was helpful to you. We did stray from the deck quite a bit but it was obvious, at least to me, that we needed a more interactive session. Mine was the 3rd Agile session of the day for many people and there is just too much to talk about.

    Rather than pontificating from the podium, I did try and draw in audience members who I knew had experience with Agile to give their views and help answer questions.

    If you have anything you’d like additional information about or have questions, contact me or join the Content Wrangler Community Agile Documentation group.

    Best regards,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: