The benefits of getting a Technical Communicator to be part of your agile team
In this blog post, I discuss how beneficial it can be to work with a Technical Communicator (TC) in your agile team often known as a Technical Writer, Documentation Specialist, or Content Writer. This post is based on my own experience; I was a technical writer for over 10 years until chance gave me an opportunity to extend my skill set and direct me to a newfound passion for all things agile.
Who is a Technical Communicator?
Tech Communicators create support documentation for end users using plain English practices so users can understand information the first time. Whether it is user guides, help files, installation manuals, or how-to guides and FAQs. You name it, I have done it.
The Technical Communicator’s role in Agile
The technical communicator is part of the cross-functional team; their unique talent is that they are the user advocate. The TC needs to build relationships with the development team to be an effective team player. This includes working with:
Product Owners
Scrum Masters
Developers
Testers
UX Designers, and
Specialists.
TCs should do their homework
To start, TCs should do their homework by reading job descriptions, old reports from information radiators (Jira boards, backlogs, and sprint reports), incident reports, retrospectives, release notes, and so on. Once they get a good grounding, they should work with your support team and testers to get further insights.
Next, I will break down what each distinct relationship looks like, and what TCs can do to ensure they succeed in supporting their team to produce the best user content possible in an empirical environment.
Technical Communicator and the Product Owner
In my experience, it is the responsibility of the technical communicator to find value in optimising this relationship. To begin with, the TC needs to find value in how the Product Owner (PO) can help optimise the documentation. The TC should get a general understanding of what your PO does and how they do it. There are many ways to do this; start by talking to them.
Then the TC should negotiate with the PO, to work with them to see what features are coming through on the road map; this will help the TC plan their work more effectively.
Useful tip for TC: Ensure they get the coverage they need, i.e., it is good to find out what features and changes are coming up; set up a monthly meeting with the PO to know what is coming up.
Technical Communicator and the Scrum Master
If TCs can work closely with the Scrum Master (SM), they can gain access to the right people to be able to document all the functions and features. Scrum Masters can help optimise relationship management by providing access to the right people. I would recommend any TC to support SMs as much as they can, i.e., be the team scribe, organise demos, etc. Like technical communicators, scrum masters are high-level thinkers and good listeners, and typically they work with a lot of people. If TCs can harness this relationship, then their ability to do their job becomes easier.
Technical Communicator and the Development Team
TCs have different perspectives from testers and developers. They advocate for users; they work with developers and testers to ensure all user support needs are met. TCs do have a natural affinity with development teams, as they are willing to ask silly questions, you know, questions that users need to know!
Over time they end up having this wall where nothing penetrates; a TC will see a developer’s eyes roll and simply make it a challenge to bother them until they relent. Seriously though, TCs tend to be polite, considerate, and patient. That is a great talent!
The Technical Communicator’s impartiality and ability to be a user advocate are their superpowers.
Ways of Working
Work with an agile mindset by breaking work down, chunking, and managing units of information relevant to the current requirements.
Tips: Set up monthly meetings with product owners and scrum masters so you know what is coming up. If you can organise a sequence of features, you will have your own road map. Take control!
Think about a unified customer experience by working closely with testers, the support team, and sales teams strive for customer excellence.
Set up a community of practice within your organisation.
TCs should own their space, and be the champions of their profession.
I would recommend for TCs to help their team create individual user stores for writing the user documentation. These user stories are then separated from the user stories used for implementation but are still associated with them.
The original user story nevertheless has a documentation task (the so-called doc task). The developers can use the doc task to write notes for the TC to create the end user documentation. The documentation user stories that are assigned to the TC are based on these document tasks.
Finally, TCs tend to have great people skills because they need to get important information from a developer or tester, and to maintain that need, they need to build and maintain that relationship. agile!
