April 2019
Text by Aktsh Dubai

Image: Rawpixel/istockphoto.com

Akash Dubey works with iManage LLC as director of technical publications and localization. He has nearly 20 yearsí experience in the field of technical communication and has worked with multinationals such as Hewlett-Packard, Siemens, Cisco Systems, and EMC Corporation. Akash heads India's largest and oldest community of technical communicators and language professionals, Technical Writers of India (TWIN).


akashjd[at]gmail.com
http://twin-india.org


 

Agile Integration Model (AIM) for global writing teams

Built on the high-tech industry, the World Economy 2.0 is all about our connected world, where virtual offices, remote teams, multi-time zone schedules, and telecons during Uber rides including hard-to-understand accents are the new normal. With it come new, subtle, and unavoidable occupational hazards of a global, offshored workforce.

Itís anyoneís guess whether the ongoing political rambling, tariffs, sanctions, protectionism, and the US$ 250 trillion world debt will ever be able to reverse or halt the globalization wave that has washed over almost the entire planet. Businesses canít stay competitive unless they tap the global talent and effectively utilize cost arbitrage. The following quote by Lee Kuan Yew attests this claim:

"If you deprive yourself of outsourcing and your competitors do not, you're putting yourself out of business."

Now, letís put the spotlight on technical writers. Depending on which part of the offshoring equation they belong to, they can also be subjected to the occupational hazards of a global economy.

Itís hard to be a technical writer:

 

  • You are often dependent on Subject Matter Experts (SMEs) for information. 
  • Not all product team members appreciate your contribution. 
  • Your check-ins donít qualify for a new build spin (resulting in outdated integrated help for last-minute changes).
  • Your cartoon character "Tina, the tech writer" doesnít even get enough airtime in cartoon strips of popular newspapers.

Itís even harder if you are a technical writer in a multinational company with customers, R&D, product management, and technical support teams located in a different geography.

 

  • Your information sources are limited.
  • You have little visibility into customer use cases and pain points.
  • You arenít part of some of the crucial product meetings and vital hallway conversations.
  • Your relationship with SMEs is very transactional and doesnít translate into any informal help that team members sometimes offer.
  • Your work-life balance is almost nonexistent because your commute is long and stressful, and your evenings are punctuated by stand-up meetings with global stakeholders.

If this article is still within the ambit of your attention span, I surmise that you could relate to some or most of the trials and tribulations of your brethren. Now that I have dispensed enough gloom all around, the stage is all set to disclose the silver lining (no, I havenít worked as an insurance sales agent). Itís time to introduce the Agile Integration Model (AIM).

What is AIM?

The Agile Integration Model (AIM) provides a framework for technical writers who work in agile teams. Itís particularly focused on alleviating the pain faced by remote technical writers.

Current scenario (or problems)

The following problems may not be true for all writers, but a large percentage of teams grapple with these challenges.

Challenge 1

The development team identifies the tasks for a sprint in the sprint kickoff/planning meeting. These meetings are long and fairly technical, as developers tend to dive deeper into the feature requirements and technical implementation so that they can arrive at story points for each task. As writers do not find the discussions relevant, a lot of them act as mere spectators or do not attend these meetings, especially if they are remote or in a different time zone.

Essentially, the development team doesnít see any active engagement from the writer(s).

Challenge 2

When the sprint begins, technical writers normally rely on UX wireframes (if available) to understand product features and get started with their initial drafts. They are unable to view the features or seek clarifications from the development team members because the features are under development during the first few days of the sprint.

Essentially, the writer is working in isolation and is out of sight for the development team. The absence is even more pronounced if writers live and work in remote locations.

Challenge 3

When the sprint is over, the development team provides a demo of all the features completed in that sprint. Writers do participate in these meetings but donít share any demos. In many cases, writers are unable to develop documentation for all the features completed in that sprint because some of the features are completed at the end of the sprint.

Essentially, writers are unable to actively participate in the sprint demo meetings.

These problems create a perception that writers arenít engaged, do not have technical expertise to explore the product, and/or have little knowledge of product features.

AIM to the rescue

The root cause of the problems discussed earlier is the engagement or integration process employed by the writer (or the writing team).

In my experience, half the battle is won if you show up in all key meetings. All stakeholders need to see you as an integral part of the team, as an engaged member, as a contributor. The remote writer will have to work harder on this, as he or she is not visible to the team in the same office.

In addition, try the following AIM guidelines at various stages of document development lifecycle:

Requirement gathering stage

Ensure that you do the following at the requirement gathering stage:

 

  • Participate in the sprint planning meeting. Be visible. If you are in a different time zone, review the sprint tasks tracking board right after the sprint planning meeting concludes. Be engaged.
  • Work with the Scrum master and update the documentation assignee field for tasks that impact documentation. Be engaged. Share this update in the stand-up meeting. Be visible.
  • Review wireframes (if any). Use this opportunity to provide feedback on the UI language and workflows. Be engaged. Share this update in the stand-up meetings. Be visible.

In addition, engage with stakeholders:

 

  • Talk to the product manager to understand WHY users need the identified features and WHAT the benefits are. 
  • Talk to module developers to understand HOW the features work.

 

Content generation stage

Ensure that you do the following at the content generation stage:

 

  • Work with the development and QA teams to install the application. Be visible.
  • Test the application. Be engaged.
  • If any defects are found while testing the product, raise bugs. Be engaged. Be visible.

 

 

Content delivery stage

Ensure that you do the following at the content delivery stage:

 

  • Work with the development team to understand and learn the process to check in your help files into the source control, so that you can reduce the dependency on the development team. Be engaged.
  • During the sprint demo meeting, present the drafts that you created in that sprint. In fact, use this opportunity to highlight which drafts are incomplete due to lack of input, feedback, or late completion of the features. Be visible.

In summary, aim to become an integral part of the team by regularly engaging with all stakeholders/SMEs and by being visible at all key meetings and forums. This will significantly change the perception of your contribution.

AIM will help you aim for the best!