September Meeting Review:
Being Barnyard Agile

by Marty Vick, Senior Member

So a question: Will document creation remain a sweep-up operation after the “real” development work is done?  Must the writer sourly await the nightstick called product development?

On September 18th, Associate Fellow Kathryn Poe and Engineering Director Matt Stringfellow, both of DataCert, Inc., offered an alternative way. That way is the use of the Agile software creation framework, a collection of highly flexible development methods. Part of it includes chickens and pigs, but more on that further down.

First, think of how things are typically done. Product development departments use the traditional waterfall approach (with Kathryn at the bottom: lots of stuff coming down—and fast). The engineering team has finished “their” work and now “you” get the whole kit and caboodle. You have one week to create all required user documentation, plus training guides.
Compare that with one of the main Agile methods, called Scrum. Scrum guides the iterative flow of the work activities across phases through bursts of work called sprints (1-10 days). Sprints focus effort on code for individual product features or increments of work. Each team member rapidly skims work to be done, taking away an ID card naming a task or activity. The team member then completes the task and moves the card to the next appropriate project phase.
The completed activity is a foundation for the next dependent activity that’s likely to be worked on by someone else picking up the card again. With freedom comes responsibility.
In DataCert’s environment, a product owner manages the whole process by using customer requirements (“voice of the customer” in Six Sigma parlance) to define product features. The collection of features makes up a backlog or listing that’s used to define the work. Managing the work is a Scrum Master who is the project champion. He or she communicates the project’s vision and provides all the care and feeding needed by the Scrum team. The team does all the heavy lifting: software development, documentation creation (Kathryn), and quality inspection (Kathryn again).

The upshot is that the technical writer participates at the beginning of the development process, not at the end. The documentation work begins where it should: at the beginning of product development. Kathryn no longer stares grimly upward while a crushing workload comes down. She now canoes along with the team.

So, what about the chickens and pigs metaphor?  Pigs are the get-it-done project team members and the product champion. Chickens are stakeholders: all the other folks affected, like users and the business’ management team. Those role names are based on a humorous viewpoint in the Agile community. Check your local search engine for the inside joke.