Agile Integration Model (AIM) for Global Writing Teams

By Akash Dubey

World Economy 2.0—increasingly being built on or supported by the high-tech industry—is all about the connected world, where virtual offices, remote teams, multi-timezone schedules, and telecons during Uber rides with hard-to-decipher accents are the new normal. These are the new, subtle, and unavoidable occupational hazards of a global and offshored workforce that’s mushrooming with increased business demands for economical labor and talented professionals.

It’s anyone’s guess whether the ongoing political rambling, tariffs, sanctions, protectionism, and the 250-trillion world debt will ever be able to reverse or halt the globalization wave that has drenched 99.000099% of the world. Businesses can’t stay competitive unless they tap the global talent and effectively utilize cost arbitrage. The following quote by Lee Kuan Yew attests to the veracity of 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. They too are subjected to the aforementioned occupational hazards, depending on which part of the offshoring equation they belong to.

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).

• Heck, your cartoon character (Tina, the tech writer) doesn’t even get enough airtime in cartoon strips of popular newspapers.

It’s 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 (read “gossip”).

• 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 non-existent 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—or you were deriving sadistic pleasure from their pain.

Now that I have doused 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 Agile Integration Model (AIM).

What’s AIM?

Agile Integration Model (AIM) purports to provide a framework to technical writers who work in agile teams. It’s particularly focused on alleviating pain faced by remote technical writers.

Current Scenario (or Problems)

NOTE: 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 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 in the case of remote writers.

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 demo. 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 for your 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/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 are the benefits to users.

• 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 for the best!