Home
  • About
  • Contact
  • Presentations
  • WordPress Consulting
  • Advertising
  • For Students
  • Jobs
  • Podcasts Book Reviews

    Have Notebook Will Travel

    March 29th, 2009 | Posted in blog 14 Comments »

    This is a guest post from Collin Turner about staying afloat as a technical writer in an agile environment.

    When the sound of my Outlook calendar groaning drifted across my office I knew I had fifteen minutes to prepare for a rapid-fire succession of meetings that would last three hours … the “Agile Gauntlet.” It was a daily occurrence and a price I willingly paid for the opportunity to write documentation in a functional Agile environment. Survival consisted of a few barebone rules:

    1. Adopt a GTD (Getting Things Done) system that’s fast, dead easy and only as complex as the tasks it contained. I ended up using Evernote with my camera phone* to get snapshots of Whiteboards, Microsoft OneNote to catch bullets (and drop the pictures into the appropriate meeting) and a Moleskine notebook for those ever important “paper” moments.
    2. Ditch the desktop computer and go for an adequately powered laptop that you’re comfortable carrying around. Make sure you’ve got a good battery and wireless connection.
    3. Use your time and resources to build strong working relationships with developers, engineers, project and product managers. You are not necessarily a member of a specific team … you are ghost haunting all of the teams. Try to be a friendly ghost and leave the poltergeist tactics for those moments when they’re absolutely necessary. In the follow up meetings, ask if you can use a voice recorder. It helps keep concepts fresh and separate.*
    4. Set aside a location where you can write, edit, and revise in relative peace. This can be your home, an empty room, bathroom stall, your car … wherever. If you don’t do this, you will go insane.

    The meetings were a frenzied walk around of fifteen minute stand-ups between 12 working development teams. I listened, took notes, asked questions, and scheduled followups if documentation was due for specific teams in the current iteration and more information was required. Those fifteen minute pearls became crucial planning and development points for core documentation. After the meetings I solidified my notes by re-writing the pieces most critical to me in the current iteration. Each team meeting note went into that team’s folder and any documentation was updated accordingly. It became a process that moved quickly and kept me organized, important when considering the amount of information 12 different teams can produce in a short amount of time! Since the walkarounds were usually scheduled in the mornings, the rest of my day could be dedicated to followups and writing. Once a week we usually scheduled Iteration Planning Meetings where my documentation was scheduled for each team. This gave me the road map needed to navigate upcoming tasks and plan accordingly. I hope you see the emerging theme here. Organization. Obsessiveness is not required to document Agile teams, but dedicated organization is. If it gets away from you once, it’s twice as hard to wrangle back into focus. Work in broad strokes first, chisel away until you’ve created manageable chunks. You’ll be amazed at how easy Agile becomes once you’ve broken it down to simple tasks and follow the process. When your documents are ready for detailing? That’s when you find the “quiet place” and focus on the fit and finish. Add and polish the details but remember that your working in Agile. Your documentation is fluid and will change, often. Make it fit the requirements of the iteration, but don’t worry about making it the last word unless the project is over. One piece of parting advice? Communication with the teams is as important as anything else. You’ll find many developers and engineers who don’t see documentation as a crucial piece of the process. Don’t fight them or try to convince them otherwise, the time you spend in battle will just eat your iterations and create resentment. Work with them, ask questions, listen, and let them explain their work. Assume nothing and learn everything. This is the key to integrating yourself as a vital member of their team. They will start coming to you with questions and important facts. You will gain allies and Subject Matter Experts — priceless commodities in any Agile environment.

    About Collin Turner Collin is a technical communicator, sometimes author, editor, and photographer usually found deep within the workings of APIs, writing manuals or managing projects. He lives in northern Utah where you can find him out among the mountains or online at www.collinturner.com. Collin is riding out the recession by documenting the hardware industry.

    Sponsors

    Tags: , , ,

    If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.

    Both comments and pings are currently closed.

    14 Responses to “Have Notebook Will Travel”

    1. [...] am a guest contributor on Tom Johnson’s “I’d Rather Be Writing” website. My article “Have Notebook Will Travel” details the basic survival techniques [...]

    2. Anne Gentle says:

      Great post, Collin! My co-worker and I think you should use the title of this post as the title of your blog. Snappy. :)

    3. Hmmm…that’s a great idea!

      Thanks. I think I’ll do that.

    4. Leif Kendall says:

      Hi – this is a very interesting post but I can’t help wondering why someone didn’t separate that big paragraph into more manageable chunks! My eyes are tired from reading blogs and a bit of white space would be appreciated! But a great post nonetheless.

    5. The colors of your blog really go well with each other, did you design it Yourself?

    6. [...] The always interesting I’d Rather Be Writing has a guest post from Collin Turner about his adventures working in an Agile development environment. [...]

    7. Dalaman says:

      A fantastic read….very literate and informative. Many thanks….where is your RSS button ?

    8. Good post, detailed and well-written, which is rare these days.

    9. Nice tips and good information! Thanks for sharing about this.

    10. I just wanted to thank you very much for this illuminating article. I have already bookmarked your site, when I have more free time I am going to have to do some further research. Well back to my dreaming of Panama or back to the books – I wonder which one is going to win out. :)

    11. Henry says:

      Nice in theory but my experience is that Agile leads to 60-hour weeks for the technical documentation teams at the end of each sprint plus unlimited amounts of re-writes. In my experience, I’ve had several writers ask for transfers or they’ve eventually quit.

      And, I’ll probably quit by Easter.

    12. Sheila_Hunter says:

      Ah yes. Agile. It only works well for the PMs and developers…maybe. As a writer it leaves a great deal to be desired. When a writer drops into a new team and needs to get up to speed quickly the first thing they do is read all the information they can find, which includes specs. Now we all know that specs are never kept up to date but at least it gives the writer a base to start from. With no specs how do you find what was intended? In my opinion Agile is just an excuse to not do the preliminary think work and just fly by the seat of their pants over time.

    13. This is just amazing read so I just had to say thankyou.

    « »