My first real-world-pace documentation assignment as technical writer was with a remote scrum team.
Before this assignment, the stories that I heard from seasoned writers had instilled in me the idea that, although my job would be interesting and useful, I would inevitably be seen as the annoying team member who prevents other brilliant team members from doing their job by interrupting them and asking dumb questions about features that were developed 6 months ago.
With this idea in mind, and with the help of my natural shyness towards strangers, I was ready to make myself small, contacting the team via email about once a week to get the info that I needed without being too much of a burden. That was my genius plan.
It was a very bad plan.
It turns out that what the team needed from me had nothing to do with what I expected. They expected me to complete the documentation of what they developed by the end of every two weeks sprint. They expected me to be on the phone every morning for the daily standup and to let them know who I would need to talk to that day. That is not to say that I was to interrupt them all the time of course. But my input was actually expected and welcomed.
In this team, I learned that:
– Shared responsibility for what you deliver can be healthier and more efficient than individual responsibility defined by job role silos.
can should give your opinion when you think it will add value to the team and project, even if you’re not [an engineer|experienced|team lead].
– Developers are not necessarily sad, anti-social, sexist individuals who behave as if they were a mightier specie.
– Short feedback loops are invaluable, for both products and people.
– Documenting features as they are developed (as opposed to after they are done and polished) is not only doable, but it can even result in more sensible features and useful content.
Despite being the newest and only remote team member, I quickly felt that I was part of the team. You could tell because I mentally moved from being “a member of the doc team who works for development team X” to “a member of the X dev team who does docs”.
It’s safe to say that I would have had a very different experience in a non-agile team. The fact that the agile mindset defines collaboration as one of its most important pillars is an amazing opportunity for tech writers to do their best work, because they depend so much on other team members. And I think it’s also a great opportunity for developers. Whether we have the same job or not, it’s the best environment to learn more about each other’s craft, understand each other’s needs and constraints, and build something seamless together. This environment gave me very concrete insights on what it can be like to be a software developer.
So, I’m one of those people who think agile can be really cool. Even when I see dysfunctions in my organisation that drive me nuts and that make me wish I hadn’t dived so much into this topic. I won’t pretend that we have figured it out, that we agiled all the things. But we do make it work to some extent, or I wouldn’t have this story to tell. I like that the agile principles are so pragmatic. I also like how they put people, who are an incredible source of innovation, creativity and delight, at the heart of building solutions to complex problems. These principles are challenging, because people are challenging. But they are good challenges: they are worth more than what they cost.