Scrum and the Single Writer
Click a link below to jump to a particular section; click any "
CONTENTS" image following a section heading to jump back here.
How much bacon can one Pig put on the line? Agile Scrum can be a beautiful thing. The Technical Writer produces timely, accurate, "shippable" user assistance at the end of each Sprint, reducing the risk of delivering incomplete or inaccurate documentation by the release-time rush.
However, Scrum involves many meetings, much planning overhead, and time-consuming team collaboration. Is it possible for a single writer to keep up?
This paper summarizes my experiences as lone writer supporting several Scrum teams in an Agile environment. As expected, there are pros, cons, and most of all incredible opportunities for growth and contribution.
What's It All About, Agile?
Agile development methods are proving successful and Scrum is emerging as the most popular approach. Technical writers need to learn how to fit into a process where their contributions might not have previously been considered. Contributing as a Pig especially relevant where the lone writer is concerned, as the challenge of managing input and feedback from multiple teams can approach overwhelming.
I want to share my experience in a growing software startup company where I remain the lone writer, aside from a contractor or to who specialize in non-software documentation. It is not my first position as a lone writer, but it is the first time I have encountered Agile Scrum.
Knowing My Place?
My small company, unlike many others, adopted Agile Scrum from the get-go. We did not have to make a painful transition to Scrum from a waterfall methodology. Originally, I was member of a few small teams that required my services to develop user guides and online help for three software applications.
As we grew, my role evolved from a member on all teams, to a member of the "Core Services" all-purpose team. The charter of Core Services is to support the other Scrum teams, which now number seven. My team members' responsibilities touch every other team-Build Master, Test Automation Engineer, System Test Engineer, Quality System Project Leader, and Database Administrator.
As a team, we are required to maintain a backlog, have daily stand-ups, present demos and status at Sprint reviews, and conduct Sprint planning for our user stories. As I was previously free to focus on the team with the most immediate priorities, I now have additional responsibilities as a Core Team member. Furthermore, as you can imagine, my team is not exactly cross-functional.
The Scrum-Ban Experiment
Kanban is a lean, or just-in-time methodology which is often used in manufacturing for inventory control and, like many good methodologies (including Scrum), originated in Japan. The philosophy is that you should only take on as much work as you have the capacity to perform. As translated into Scrum-Ban, each team member maintains a Work in Progress (WIP) board where sticky notes are placed in columns to represent scheduled tasks (Sprint commitments), tasks that not planned but necessary, work in progress, completed tasks, and impeded tasks.
We are committed to work on no more than three tasks at a time. The WIP board gives visibility to our progress and status. When a WIP sticky is moved to another column, a task-in-waiting sticky takes its place.
In addition to giving us visibility, Scrum-Ban proved to be a great organizational and motivational tool. However, we ultimately found that, like Scrum, it did not work so well if everybody in the organization was not doing it also. The demand on Core Team members did not allow us to "just say no." Still, the WIP board is used by some team members today.
I recommend further reading on Kanban and Scrum if you are interested in how to make the best use of both of these methodologies together or separately.
Writer As (Scrum) Master
I find that being a member of a Scrum team such as Core Services presents many opportunities to test the leadership waters. Technical Writer as Scrum Master? Why not?? It is the type of role where our organizational and communication skills are especially useful. And it is a great way to get to know all the players and gain an understanding of what they are doing. This important role is highly valued in some markets today and can be the key to a new career path, or to other positions within your organization.
Here are some additional bonuses.
I contribute to the process on a daily basis
Being part of the process is definitely much better than reacting to the needs of an organization in a less-than-timely fashion. Furthermore, I have my own user stories and through this team structure, the stories have visibility. I get to talk about them in front of everybody. I get feedback and input. Want to be sure your documentation or user experience design is reviewed? Get it into the Definition of Done! As a part of the daily process you and your work are no longer an afterthought.
Customers are Chickens and I build the coop
Customer requirements and their subsequent feedback are key to Agile Scrum. This input makes the wheels turn. My company does an excellent job of helping us understand customer needs through mutual visits, and inviting these important stakeholders to a review and demonstration, complete with breakfast, every three months. Furthermore, I am able to talk to customers personally and get the feedback I require-no waiting for that comment card that may never be mailed back. Finally, additional emphasis on customers and their needs turns the spotlight on my work.
Did the Piggy Really Go Wee Wee Wee?
Scrum encourages agility (duh!) so naturally there are areas that our process needs to address.
(Sprint) Size does matter!
Our Sprints are two weeks. Documentation tasks are usually approached at the end of a user story, which is often the end of the Sprint. Too many teams and this is hard to manage. Other companies I know involved in Scrum only add documentation tasks and sometimes UI design tasks to the same Sprint in which the development occurs only when their Sprints are three weeks or longer.
Don't let the tools drive the process
We use Rally to manage our requirements, user stories, and defects. While it is a great tool, it is just that, a tool. The nail doesn't define where I hang my hat. Although we are required to use Rally as a means to communicate our progress, the Scrum-Ban experiment showed that we can be creative in showing off our process.
Who needs time for lunch, anyway?
I support seven teams. 'Nuf said.
Not only can the lone writer be a team member on multiple teams, the writer can contribute significantly to the development and advancement of the Agile Scrum process. The practice of Scrum will stretch you as a technical communicator and a team member!
Kathee Kuvinka is a technical communications professional with twenty years of experience in private companies and government agencies, crisscrossing the country to write and edit software and hardware documentation of all types. This is her first experience with agile Scrum. Her current employer is committed to the Scrum process to produce products that respond to the needs of their customers.
Senior Technical Writer