How to thrive as a technical writer on a scrum team – 1 March 2018 [Meeting]

A common misconception about scrum is that it doesn’t value documentation. This presentation will cover the principles of scrum, providing an explanation of how this misconception occurred and how you can demonstrate the value that you bring to the team. We will also explore some skills, many of which you might already have, that will help you thrive as a technical writer in a scrum environment.

About Our Speaker

Shari Clare has traveled a winding path in her journey through scrum. Her first career was as an Elementary School Special Education teacher. She retrained to be a Tech Writer in 1993, and has worked at about a dozen high tech companies throughout Silicon Valley. She began learning about the scrum/agile in 2006 from Jeff McKenna, a founder of scrum, then became a Certified Scrum Master in 2010. She has worked with scrum teams while at previous jobs at Voltage/HP/HPE. She had been working for about year without the benefit of scrum at Zoom, and recently left to join Telenav, in large part to work at a company using a scrum environment.

View the Slides

Meeting Logistics

Date: Thursday, 1 March 2018

Meeting Recap

by Dan Littman

If you’ve been anywhere near the software world in the last decade or so, you’ve certainly heard about the overlapping development methodologies variously known by Agile, scrum and other terms. Our presenter at the March 1 chapter meeting, Shari Clare, recently came off a gig where she was the sole tech–writer supporting a crew of 300 software developers. She says that to survive there, she snuck in some unsanctioned Agile practices just to get a handle on the workload.

Shari gave us a short history of software development methodologies and a thorough grounding in what Agile and scrum bring to the table.

Briefly, part of what defines Agile is that development tasks are broken down into small actionable chunks and attacked by small teams in bursts called “sprints,” which run just a week or two. Pieces of the design specification are produced collaboratively and sequentially—instead of in the parallel and uncoordinated way of old—and the engineering–complete goal for each sprint is highly defined. That forces the design specification into the open, keeps the team focused on specific modules that can be nailed down in predictable steps, and allows progress to be clearly measured and sticking points quickly identified.

But the Agile methodology goes well beyond normal engineering routines—and normal office routines, for that matter—in asking team members to adopt a specific mindset and follow a set of group–dynamics practices. The Agile Manifesto, first released in 2001, explicitly favors individuals and their interactions over processes and tools, and favors customer collaboration over contract negotiations.

In addition to attending daily standup “scrum” meetings facilitated by a “scrum master,” team members participate in “ceremonies” to mark certain milestones, such as sprint planning, the sprint review (to demo software progress), and the sprint retrospective (to analyze successes and failures). Product owners define the development goals in terms of “stories” that explain what the end–user will get from the software. Then, in scrum meetings, team members define their daily tasks in terms that fulfill the vision of the story. Each team member describes what his or her next piece of the project is, why it is needed, and what constitutes completing it successfully. And members pledge to the team to fulfill the commitments they’ve made for themselves.

You’re probably wondering by now what all this has to do with tech–writing. Well, consider this: At her recent position, Shari quickly emerged as the scrum master. She was shocked at first, but she soon understood that being intimately involved with the programming team yet not being a programmer gave her a perspective her team needed to see the big picture; she points out that a lifetime as a professional communicator didn’t hurt either.

Here are the Agile/scrum tasks and attitudes that Shari believes a tech–writer can—and should—take on for the project.

  • Attend all the scrum ceremonies for your team(s). Adopt the mindset and participate.
  • Use the daily standup meetings to keep abreast of what documentation demands are approaching.
  • Inject your documentation tasks into the stories that drive each sprint. Make sure that finishing docs is part of the definition of complete.
  • Keep documentation in sync with the development process. You’re as committed not to fall behind as the programmers are.
  • Help the product owner write the user stories.

One more point: True to its name, Agile isn’t standing still. A new formulation is emerging, called “Modern Agile,” that has four guiding principles:

  • Make People Awesome
  • Make Safety a Prerequisite (i.e., protect and support each other)
  • Experiment & Learn Rapidly
  • Deliver Value Continuously

Agile, in some form or another, is here to stay, so if you want to steer your tech–writing career toward high–paying software documentation, take the time to educate yourself in Agile and scrum before you go for job interviews.

Coming up: For all you DITA–using and DITA–curious tech-writers, at next month’s chapter meeting we’re slated to hear from Dawn Stevens. Dawn recently took the helm at Comtech Services, the influential Denver–based DITA consultancy started by JoAnn Hackos. Our new room in the San Ramon Marriott’s Bishop Grill is bigger and more modern than our previous digs. It’s also more expensive, which is another good reason to support the chapter by attending the April 5th meeting.