Two years ago, I started my work as a technical writer in an agile development environment. Before, I did not have lots of experience with this agile “thingy” - none at all. What’s even more, gathering information from the species of “software developers” was also quite new to me. But hey, I’m a “TechWritress”, I can handle everything, right?
Enjoy learning new stuff
That goes without saying. But it seems that, in agile software development, you never stop learning. I’m learning new stuff every single day. Even after two years. Which is great!
I started out building up a new API documentation. This meant understanding what an API is all about, knowing the working methods of developers, how they gather information, understanding the basics of their working environment, and their specific tools. It meant finding a suitable documentation tool and platform, and how to deal with these. And it also meant applying many of their tools myself: GitHub, Jekyll, the terminal, or setting up local environments. Not to mention decoding the developer’s technical jargon 😉.
And now, with a TechWriter in the house, there was more to come: I metamorphosed to a content writer. This was another awesome chance to step into something new. I started cooperating closely with UX, which meant understanding the tiny bits and pieces of our different products, and to put myself into yet another user’s perspective: this time not developers, but our merchants.
And with UX already in the boat, we made quite some effort for consistent texts and communication. Not far from that was another new topic: software localization and translation. Yay! As I originally studied technical translation, this was like a home match for me.
Phew, let’s stop here. You got the point, didn’t you? Technical writing is extremely varied and exciting.
Juggle with many balls at the same time
This is closely related to the previous section. Usually, the above mentioned tasks are not required one after another - it’s not as simple as that - but at the same time.
I’m the only technical writer for several scrum teams. A one-woman business so to speak.
The scrum teams work in sprints on a biweekly cycle. Believe it or not: the sprints of more than one team, most likely, have technical writing dependencies. Anything else would just be boring 😊. Be it new REST calls to be documented, wording for new features to be provided, a blog post to be written, processes to be discussed, localization issues to be figured out… All those things might happen within the same time frame. But women are capable of multitasking, right? So we can add some meetings here and there, such as sprint reviews, coordination processes, routines…
Not a big deal. This definitely strengthens one’s coordination and organizational skills.
Which brings me to the next point: being proactive. If the mountain won’t come to the prophet… oops: If the developer (or product owner) won’t come to the writer…😉 … then the writer should proactively approach THEM to squeeze out any information about upcoming tasks.
Recipe to get hold of information:
- wait for the perfect moment
- give a charming smile
- ask the right question
- know when it’s enough
- come back later
- and brighten their mood with coffee, chocolate, or cake.
Proactively checking the teams scrum boards also helps to understand what’s up in the near future and where documentation support might be required.
I mean REAL quick. Being an agile writer means learning and adapting to new technical context quickly. That also applies for gathering information quickly. If you’re too slow, developers already work on the next big topic, and the information you need for your docs is already out of their heads. Which then makes it difficult to write a good documentation.
This also goes without saying. If you don’t love writing, it’s hard to get the message across. This is why developers hate documentation and love having a technical writer around 😉.
Once you’ve written your docs, one could think, “Hey, lean back and relax a little”. Far from it. As a writer in agile development, you have to embrace change. The docs you’ve written just a week ago might be already outdated.
- The feature might work differently than expected.
- Somebody found a bug, which might change the whole implementation.
- The feature concept was changed.
Being an agile technical writer definitely rocks - in a positive way:
- You learn and use the products.
- You broaden your technical knowledge and writing expertise.
- You set standards for writing, language, and terminology.
- You become a MacGyver in technical communication 😎.