Agile development arose in response to the deficiencies of traditional waterfall-style development, a practice that relied on long-term, sequential planning, and execution. Agile concepts originated in manufacturing but are now used in a variety of industries. Computer software and hardware are chief among them.
The Agile Manifesto prioritizes the following:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile methodologies share certain features, such as the following:
- They are flexible and rely on discovery and discussion rather than on long-term planning and large functional specifications and design documents.
- They work toward smaller, iterative chunks of functionality rather than toward, infrequent and, not always external product releases. Agile teams create frequent releases that allow ready adjustment if requirements change or if a technical approach does not work.
- They are team-based and are, to some extent, self-managing. The individual contributor works closely with a small team whose members have a great deal of freedom designing and executing projects.
Why Do Technical Communicators Need to Know about Agile Development?
Agile methods might be alarming because they could be construed as anti-product-documentation. This is a misconception because the comprehensive documentation that the manifesto dismisses is internally directed, but it is not product documentation. Internal documents can be lengthy functional specifications, detailed design documents, and other plans produced prior to coding. Customers of agile firms receive product documentation and user assistance quickly and tailored to their needs.
Day-to-day, a technical communicator will not see much difference between an agile and a traditional waterfall environment. However, the technical communicator in an agile setting will likely be a member of several cross-functional product teams. In an agile environment, team orientation means:
- Members sit together, if possible.
- Team meetings are a priority.
- Members will come up with new ways of collecting information from teammates in the absence of specifications and internal documents.
- Members take an interest in all work, even if it does not affect documentation.
- Members communicate status, tasks and needs.
- Time permitting, team members help with tasks not related to documentation.
In agile environments, the technical communicator reports to the documentation manager but has the autonomy to manage many day-to-day tasks. These often include the following:
- estimating how long it will take to complete these tasks
- prioritizing tasks
- publicly tracking progress and pointing out obstacles
- securing team cooperation
- lobbying against the notion of document completion for each iteration
Technical communicators can benefit from agile methodologies in the following ways:
- team integration and support as company staffers learn what technical communicators can contribute
- increased autonomy and more responsibility for success
- increased visibility
- improved work-flow with fewer peaks and valleys
- opportunities to grow in, or beyond, current role
- better chance of working with happy SMEs
- better chance of working for a successful company
However, an agile approach can have pitfalls. Examples include the following:
- Membership on too many teams: This is one of the biggest complaints voiced by technical communicators in agile environments. Often a single team will not generate enough work for a full-time technical communicator. When this happens, a technical communicator can be assigned to two teams which means twice as many administrative demands. If assigned to too many teams, a technical communicator might neglect one team over another. If the demands of being a member more than one team are too trying, a technical communicator can be rotated between teams according to the workflow.
- Teams that are too large to be effective: If an agile team reaches ten or more members, administrative demands can sap its agility. If this happens, it may be time to split the team into two groups.
- Rigid attitudes about documentation: Some enthusiasts claim agile does not encourage technical communicators to create product documentation. However, agile consultant and author James Shore, in his book The Art of Agile, argues against this view, “Product documents have business value; schedule them with stories.” Shore contends that, in the highly customer-focused world of agile development, the customer’s need for effective product documentation trumps all other requirements.
- Conflict between iteration and release schedules: The documentation manager will ensure that documentation for soon-to-be-released products is complete and correct, even if it means suspending agile teamwork.
- Distracted technical communicators: The documentation manager should ensure that technical communicators are not pulled into non-documentation tasks like Quality Assurance.
First version posted by Christine M. Sigman (c.m.sigman@gmail.com) on 27 May 2010.