Excellent and Consistent Content Development through Agile and Scrum

According to the Conference Board’s CEO Challenge 2007 (published in October 2007), chief executives predict that execution will take precedence over profit or top-line revenue growth. Indeed, excellence in execution and consistent execution of strategy by top management rank first and third, respectively, as greatest concerns. A simple line of logic reasons that what is top-of-mind in a CEO is—and should be—top-of-mind in every person within the organization who desires to remain with that organization. Hence, the introspective documentation manager will ask, “Do I have my team optimized for consistent, excellent execution?”

It’s a fair bet that your colleagues in software development have asked themselves this question and have answered it by adopting principles of Agile Software Development. By way of background, “Agile” is a philosophy about the relative merits of eight issues surrounding all software development. Agile adherents value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The Agile philosophy brings out the best in software developers. It satisfies their deepest desires to produce software that is valuable the customers. It accommodates late-arriving information that alters functional behavior. It focuses on the delivery of working software. It allows managers to devise projects for motivated individuals, and then gives them the environment, support, and trust these individuals need to get the job done. Agile breeds consistent excellence.

If Agile produces all of these benefits in software developers, there is reason to conclude that a modified Agile Manifesto for Content Development would inspire a similar kind of consistent excellence.

The Agile Content Development Manifesto
The idea of an Agile-based manifesto is nothing new. Emily Chang and Max Kiesler articulated the main points of an Agile Web Design Manifesto in February 2006. Their manifesto has six statements focusing on such things as rapidity, simplicity, and collaboration. Scott Ambler, the creator of Agile Modeling, cites five values for his own modeling manifesto: communication, simplicity, feedback, courage, and humility. There is nothing sacred about the number of phrases or elements in a manifesto, but a manifesto should be sufficiently succinct and complete to form the basis for a larger set of principles and practices. Here, then, is a proposed manifesto for Agile Content Development with a few notes about each tenet:

Individuals and interactions over processes and tools. Hardly original, but the essence of every manifesto I’ve read. We lose something innately creative and liberating about ourselves when we submit blindly to a particular way of doing things or to a particular set of prescribed tools for getting those things done.
Examples and illustrations over definitions and prose. These ideas find expression in teaching and training little children. Difficult concepts are easily grasped and applied with a few well written examples and a picture. How many of your readers feel like a six-year-old when first picking up your company’s product?
Customer collaboration over controlled authorship. Achieving consistent excellence in content production is a collaborative process with the consumer of that content: the customer. The proliferation of customer-written wikis and blogs are evidence of customers’ willingness to contribute to the body of content about virtually any subject or product.
Responding to change over following a plan. Someone who values Change over Plan builds a relationship with team members that harnesses and thrives on changes that occur in every project, rather than carping about being the last one to know about those changes.

I admit that these four statements look like a quick rework of the Agile Software Development Manifesto. That is to be expected. Content development and software development are symbiotic in their relationship to each other, both as to the skills necessary to be proficient and the temperaments found in the best practitioners.

More importantly, the two manifestos should be similar. Teams adopting Agile Software Development have consistently executed at the highest levels of excellence even as the triple threat of product revisions, expansions, and configurations have outstripped the capacity of the more traditional Waterfall software development model to manage these changes. Documentation teams should be similarly agile in their organization and operation. This goes well beyond exporting one’s own documentation team members to various software organizations who are following Agile. It means to reorganize one’s team into an Agile entity, adopting Agile-derived methods as the basis for the team’s internal operations with the goal of achieving operational excellence day after day. Hence, the two manifestos should be similar, and some of the derived processes should be similar, too.

Scrum: an application of the Agile Content Development Manifesto
One of my favorite Agile-based methodologies for building software and managing software development is Scrum. I like Scrum all the more because its concepts apply easily to managing content development teams. Wikipedia has a serviceable explanation of Scrum Management. The main elements are these:

The product owner. This person is the voice of the customer. In software development, it’s often the Product Manager. In software documentation, it could be the Product Manager, but I would argue that it should be someone from Technical Support; they hear the customer’s voice all day long.

AUTHOR’S NOTE: The argument for a technical support person to be the product owner for technical documentation may be off-kilter. After all, a Product Manager is responsible for the whole product, which includes both software and documentation, so it seems more natural to have this person be the product owner for the technical documentation. However, my professional experience includes several years as a software developer, a product manager, and a technical support engineer. In surveying that experience, I find myself recalling a lot of customer frustration on the telephone because the product documentation was poorly written. Hence, while it is counter-intuitive thinking, I find myself trusting the judgment of a technical support engineer more than I trust the judgment of a detached Product Manager to know what kind of technical documentation the customer needs to read. Your experience may be different and so you may think differently on this point.
The scrum master. This is the facilitator, the one tasked to remove impediments that the team encounters. The scrum master also enforces the rules of good Scrum. In my view, this person is you, the technical documentation manager.
The scrum team. This is a self-organizing group of authors, subject-matter experts, and reviewers numbering between 5 and 9 people. These people do the actual work.
The daily scrum. This is a daily project status meeting where each member of the scrum team answers three questions:
- What have you done since yesterday?
- What are you planning to do by tomorrow?
- Do you have a problems preventing you from accomplishing your goal?

Some additional points about Scrum:

The product owner determines what is to be written and keeps track of this list in a product backlog. If the documentation product owner is the Product Manager, then the list of things to be written usually mimics the list of features to be implemented. If the documentation product owner is from Technical Support, the list of things to be written will skew towards the kind of detail to emphasize for each product feature that is implemented.
During a 15- to 30-day period (called a sprint), the team creates a set of publishable documentation. The topics to be authored during a particular sprint are put into a sprint backlog, and the team breaks down each topic into units of work that never exceed one or two days each.
Writing assignments and other units of work are accepted, not assigned. Individual members of the scrum team select units of work to accomplish; the product manager and the scrum master do not assign work to any particular team member.
Scrum teams are self-organizing. The person selecting a unit of work seeks out other resources as needed to help complete the assignment correctly.

Why Scrum Drives Excellence
Scrum drives excellence in three ways. First, it lets team members take ownership of a unit of work and be accountable for the success or failure of that ownership. The freedom to take ownership of something is a liberating concept. It gives the person license to seek out the resources and means necessary to complete a task, and allows him to receive credit for completing the task effectively. Under this kind of motivation, only most incorrigible of workers will fail to improve their ability to consistently deliver high-quality documentation on time.

Second, it puts the documentation team manager—as scrum master—in the position of enabling success. Enablement comes because the manager’s primary focus is to remove obstacles, ensure fair and correct Scrum “play”, and to conduct post-sprint retrospectives to identify areas of team improvement. Furthermore, the documentation team manager does not have to worry about balancing a team member’s workload, a sizeable job in non-scrum team management. These two factors remove many of the interpersonal problems that otherwise creep in between the team and the manager as schedules compress and product features change at the last minute.

Third, Scrum is all about handling last-minute changes. At the end of each sprint, the product owner is free to adjust priorities for the next documentation sprint. The impact of this adjustment is minimized because all output from a documentation sprint is potentially publishable; that is, there are fewer opportunities for a late-breaking change to derail a long, multi-week/multi-step author/review process. The commitment to product potentially publishable documentation at the end of a 15- or 30-day period naturally constrains processes to a manageable size. If some kind of rework is necessary due to a feature change in the product, the amount of documentation that must be discarded is likely constrained to what was written within that period alone. (Not always, but certainly likely.) When the amount and scope of rework is sufficiently contained, late-breaking changes are no longer the source of corrosive bickering between documentation and software development teams. Instead, changes are seen for what they are: alterations to the product’s capabilities and documentation that reflect what customers really want the product to do.

Reconciling Agile Content Development with Agile Software Development
In proposing an Agile Content Development Manifesto and its derivative Scrum Management methodology, there is natural concern about who takes direction from whom. After all, the Product Manager is indeed the owner of the whole product; he or she sets priorities for the software team. In most companies, the documentation team’s priorities are derived from the feature priorities set by the Product Manager, so the common approach is to deploy technical documentation team members into the overall product development team. Some may question why a second manifesto and Scrum Management dedicated to technical documentation teams is necessary.

The answer to that question is a function of how the technical documentation team manager assesses the value and uniqueness his or her team within the larger organization. A conventional thinking documentation manager will do a fine job of keeping the troops happy, getting the best tools available, and working within the product development team as governed by the software engineering team leadership.

A forward thinking manager, one who really believes that technical documentation is corporate asset, will seek any and all means to elevate that asset to become a distinctive competence within the industry. That thinking translates into actions that produce excellence, the kind that CEOs are looking to differentiate a company within the current competitive climate. A manager’s key action, then, builds an identity around his technical documentation team. She begins by defining a set of core principles (the Agile Content Development Manifesto) and a methodology based on those principles (the Scrum Management methodology applied to technical documentation). She continually leads her teams in their step-wise approach toward operational excellence, and she anticipates cross-over issues between the production of documentation and the production of software. But she runs her own show because she’s striving for excellence.

Don’t think that I’m arguing in favor of building silos between technical documentation and software development. Instead, recognize that technical documentation is a separate function from software development (your teams write words; those teams write code). That is the natural division of things. Each function draws on different tool sets, operates within its own set of processes, and produces separate output that ultimately joins at the packaging phase of the product (whether that means including on-line help in the final product build or inserting printed documentation into the shipping box). Hence, to achieve overall excellence in product development, each function needs its own separate identity in order to consistently optimize its operations.

The Agile Content Development Manifesto and Scrum Management provide that identity.

About Eric Kuhnen
Eric Kuhnen is Managing Partner at Focal Partners. He can be reached at .

More articles about Content Management : Technical Writing : Technological Innovation