By Karen Smith and Patty Gale
Your organization's development teams are adopting the Agile framework. Should your learning content team follow suit? Or continue to work using established processes to produce quality documentation?
If you are part of a learning content team thinking about moving to Agile, here are some pros and cons to consider. The pros describe the ways in which an Agile environment can streamline many day-to-day tasks that you face as a writer. The cons present obstacles and challenges that may seem daunting, along with proposed solutions that can help you work through these issues.
By working together in a supportive Agile environment, you and your team members will discover the strategies you need to be successful as Agile technical writers. You'll soon realize that, as 17th century English churchman Robert South declared, "An obstacle is often an unrecognized opportunity."
People Power
A typical Agile team is composed of five to nine people with cross-functional skills. The team works together to design, develop, test, and document products or features in small increments. When the Agile environment is adopted across an organization, many learning content teams fear that their staff won't stretch far enough to support all of the Agile teams. How can technical writers fit into this framework?
Pro: Increased Collaboration
Agile teams operate under the assumption that "we're all in this together." The team succeeds together or fails together. As a result, roles often blur: everyone on the team can help design, test, and document features.
For writers, this increased collaboration leads to greater insight into the development process and greater access to developers and subject matter experts. Ken Kidder, manager of information development for appliance solutions at Symantec Corporation, said, "I feel Agile requires more communication, and folks are beginning to understand that within the Scrum teams. We experience more communication between teams than ever before."
Con: Not Enough Writers for Agile Teams
Ideally, one writer is embedded in each Agile team. The writer performs as a full member of the team and attends daily stand-ups and team meetings. When you have more Agile teams than writers, perhaps each writer can support two teams. If writers need to support more than two teams, however, they may spend so much time performing Agile overhead tasks that they have little time for writing.
The Solution: If the writer-to-team ratio doesn't work, consider organizing the learning content team as its own Agile team that responds to requests from product teams for new feature documentation. For more information on this strategy, see our presentation on Slideshare, Parkour: Lessons in Agility.
Teamwork
Rather than a process, Agile is more accurately described as a framework or a way for teams to interact and get work done. Agile teams are self-organizing, value face-to-face conversations, and practice an all-hands-on-deck attitude. While the emphasis is on individuals and interactions, the tools and processes that are implemented as part of the Agile framework have value, too.
Pro: Greater Transparency Into Upcoming Work
In an Agile environment, you gain more insight into the work of the teams you support. Each team's development work is outlined and prioritized in their backlog. Tools such as JIRA (www.atlassian.com) or Rally (www.rallydev.com) help teams plan and track the work and provide visibility for others in the organization. Christine Brouillard, senior technical writer at CNC Software, Inc., explained, "We now get a lot of the information we need from backlogs and in face-to-face interactions during meetings. Agile has reduced the amount of time that we sit in developers" cubicles talking to them individually, which saves time for them and time for us."
With increased visibility into upcoming work, you can evaluate the pace at which features are being developed, and plan your work accordingly. The accidental discovery of last-minute features that require documentation occurs less frequently than before.
Brouillard added, "In the past, we would stumble across software changes by chance. The communication mechanism to get the information to us just wasn't reliable. With Agile, even if you don't have all the details about what the changes will be, at least you know what areas are changing, so you can plan for what's coming."
Con: More Meetings
Agile meetings are work sessions where team members plan and prioritize the work that needs to get done (sprint planning), provide status (daily stand-ups), and demonstrate work completed (sprint demos). They provide the framework or structure around which the development work is completed.
When you first transition to Agile, the meeting load can feel burdensome. During the course of a two-week sprint, an Agile team can spend eight hours or more in meetings. You may wonder when you'll have time to develop learning content or perform other work.
A common mistake is to add the new Agile meetings to the existing meeting schedule. Agile meetings are designed to be sufficient for the team to complete their work. Everyone in the organization has well-defined touch points to interact with the Agile team. Ad-hoc meetings can address immediate needs within a sprint.
The Solution: All Agile meetings are time-boxed and have a recommended duration. The Agile team must learn to adhere to the recommended frequency and duration of the meetings. This adjustment can take practice and experimentation. However, under the guidance of the Scrum master (the team's servant leader), the team can improve their Agile practices and interactions, including how often and when the team meets. Casie Oxford, senior content manager at Zix Corporation, said, "When we first started Agile, the meetings were too long. But now that we know what we're doing, we're much more efficient."
Workloads
In a waterfall environment, the writing workload is often cyclical. Early in the release cycle, you may have a light workload. As development work for new features is completed, however, you often encounter "crunch time." You suddenly have more work than you can manage, and you work long hours to get it all done in time for the product release. How does this compare with workloads in an Agile environment?
Pro: A More Consistent, Sustainable Level of Work
One of Agile's biggest benefits to writers is the even distribution of work throughout the year. When collaborating with Agile teams, you document features as they are developed. The product and its documentation are tested along the way, leading to fewer errors or last-minute surprises before a release. And because the documentation reflects the current state of the product, the learning content team can support more frequent releases.
For Casie Oxford, release-driven crunch times are a thing of the past. "We have been doing Agile for three or four years, and there are not as many highs and lows for us. Our workloads are pretty level over time, which means we don't feel nearly as crunched at the end of a release as we used to."
Con: Be Prepared to Reverse Your Work
When you document features as they are being developed, there is a chance that stakeholders will decide a feature is not yet ready for release. Not only must the feature be removed from the product, but its documentation must also be removed.
The Solution: When you adopt Agile, consider how you will address such issues. At the start of a release cycle, make a release management plan for the documentation. Use a content management system with version control. Develop a way to track the documentation that is added and updated for each feature. If a feature is omitted from a release, you can ensure that its documentation is removed.
Iterative Development
In a waterfall development environment, you may wait until the development teams are done designing, coding, and testing the product before you begin developing the documentation. Because you're documenting the finished product, the content is not likely to change.
In contrast, when you work in an iterative development environment like Agile, smaller working pieces of the final product are delivered at the end of each sprint. How does this difference change your work?
Pro: Work in Smaller Chunks and Iterate
In an Agile environment, you're drafting documentation during the sprint in which the feature is developed, or perhaps a sprint behind. As a technical writer, it may feel uncomfortable to not have all the information to document the product. This ambiguity can be unsettling.
On the other hand, knowing that the product is likely to evolve in future iterations means you'll have an opportunity to further refine and improve the quality of the documentation before it's delivered to users.
Con: Projects Are Too Large to Fit Into Sprints
If you're not Agile yet, you're probably used to working through a large, complex project until it's done. You may spend weeks or months on the same project. Keeping up the momentum (and the motivation) can be challenging.
When you transition to Agile, you'll quickly learn that the work required to complete a large project doesn't fit into a sprint. In addition, external dependencies require interaction with people outside your team, and those interactions may extend beyond sprint boundaries. These realities can make it challenging to complete a project within a sprint.
The Solution: Learn how to chunk a large complex project into smaller pieces. Work with team members to break the project into chunks that fit into a sprint, and share the load with others on your team to get it done. Identify dependencies and plan them in your sprint scheduling. Flexibility and adaptability are the keys to making this work.
User Experience
Organizations now recognize that technical communication is an important part of the user experience (UX). Agile teams are learning to incorporate UX design with lightweight prototyping and rapid iteration to evolve designs within a sprint. Some teams invite a panel of customers to sprint demos, or invite their feedback on a prototype during a sprint to make sure the team is providing a positive user experience. How does this emphasis on UX affect documentation in an Agile environment?
Pro: Higher Quality, More Usable Documentation
Being involved with the team during active feature development means you have a deeper understanding of the feature and its use cases. UX designers can provide real-world examples for conceptual topics. Quality assurance (QA) engineers can offer sample data sets for screenshots. Team members review and test the new or updated documentation during the sprint. Having just designed, coded, and tested the product, technical reviewers have immediate knowledge of the features, so their feedback is more accurate and detailed. Ken Kidder explains, "The writers on my team like the fact that reviews are occurring within each sprint, which leads to a technically accurate and successful demo at the end of each sprint."
By participating in UX activities (taking notes during user interviews, observing usability tests, and responding to user questions during a beta release), you can gain insights into users' pain points and be sure to address them in the documentation. When you show documentation to customer panels during sprint demos, you receive early feedback and can iterate the content to better meet user needs. The end result? Documentation that is more accurate and more usable.
Con: Writers Have Little/No Experience with UX
If you have never performed tasks such as interviewing users and conducting usability tests, you may not feel confident participating in these UX activities.
The Solution: Ask your user experience team to hold workshops that introduce writers and other Agile team members to UX methodologies. When UX activities are performed during a sprint, ask if you can participate in some way, such as taking notes or observing sessions. Look at your expansion into the UX realm as another tool in your technical writing toolbox, contributing to your professional development and making you a more valuable member of your Agile team.
Obstacle or Opportunity?
When it comes right down to it, your learning content team may not have much choice: if the organization is adopting the Agile framework, you may be required to follow suit or at least adapt to support it.
If that's the case, look at Agile as an opportunity, not an obstacle. For example, you may find that working in an Agile environment can increase awareness and credibility for the learning content team.
Sprint demos provide an opportunity to share your work, making it more visible to the rest of the organization. For example, before our organization adopted the Agile framework, most of our co-workers thought we only documented new features. Now they understand that we also enhance the quality of existing learning content, improve searchability, and reach out to users by replying to their questions and comments. Our sprint demos have made the organization more aware of these efforts.
In an Agile environment, quality is a team sport. When you participate in the Agile framework with developers, designers, QA, and product management, you work together to mitigate risks, overcome obstacles, and celebrate successes in delivering a better product to your customers. There's nothing like being a team player to build credibility within the organization. Your visibility increases, and you build a greater awareness of the business value your team brings to customers.
Patty Gale is a principal learning content developer for a technical writing team at Autodesk. She also serves as the team's information architect and content strategist. A technical communicator for over 25 years, Patty has worked at businesses all sizes, from small start-ups to large corporations. She has received multiple awards from her employers and STC competitions, including an International Award of Distinguished Technical Communication. She presented about Agile at the STC Summit 2014. Patty holds Bachelor's degrees in Computer Science and Business Management.
Karen Smith is a senior learning content developer at Autodesk, where she has worked with Agile teams since 2011. Currently, Karen serves as the Scrum master for a horizontal service-based Scrum team that develops learning content for over 20 Scrum teams around the globe. She presented about Agile at the STC Summit 2014. Before joining Autodesk, Karen was an instructional designer, e-learning developer, and online instructor for IBM. During her career, she has worked as a curriculum developer and technical trainer for a variety of for-profit and nonprofit organizations. Karen has a degree in public communication.
Autodesk and the Autodesk logo are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates, in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document. ©Autodesk, Inc. All rights reserved.
References
Brouillard, Christine. Senior Technical Writer. CNC Software, Inc. Personal interview on 26 August 2014.
Gale, Patty, and Karen Smith. 2014. Parkour: Lessons in Agility [slides]. Available from http://slidesha.re/1pmHJvI.
Kidder, Ken. Manager of Information Development for Appliance Solutions, Symantec Corporation. Personal interview on 26 August 2014.
Oxford, Casie. Senior Content Manager, Zix Corporation. Personal interview on 21 August 2014.
South, Robert. http://en.wikisource.org/wiki/South,_Robert_(DNB00).
