Can I Be an Agile Technical Communicator When My Team Is Not?

The typical Agile development process presents challenges to the technical communicator

The actual implementation of an Agile project varies from place to place. In a fairly typical model, the cycle begins with a prioritized set of customer requirements. These requirements are usually written in the form of user stories, which take the simple form: “As a [user], I want to [x].” For example, “As a system administrator, I want to change my password.”

A cross-functional Agile team forms, which typically includes the product owner (who represents the customer), a project manager, one or more developers, one or more testers, and—maybe!—a technical communicator. An Agile team ideally has no more than 10 members.

The team takes the highest priority stories into a sprint, which is a time-limited development cycle that typically lasts no more than a month. Remaining stories become the product backlog, to be addressed in future sprints.

Each sprint begins with a planning phase that breaks the stories into manageable tasks that can be assigned to team members. After this, the team gets to work, meeting briefly every day to assess progress. Most Agile teams do test-driven development, where the testers work closely with the developers to ensure that the functionality is working properly right from the start. When tasks aren’t progressing, the regular meetings make this immediately clear. Work is reassigned, reprioritized, or even removed from the sprint altogether if necessary. And because the product owner, who represents the customer, is a key part of the small team, everyone hears immediately about any changes to customer priorities. Likewise, the product owner sees when there are roadblocks in the development environment and can reset customer expectations as needed. Constant communication eliminates the chance for surprises for anyone at the end of the sprint.

After the sprint, the team holds two important meetings. First, the team holds a review meeting in which they demonstrate working software to stakeholders—those outside of the Agile team. This meeting is usually when funding decisions are made for upcoming sprints. Finally, the team holds a post-mortem meeting, where they discuss what went well and what did not during the sprint. This retrospective allows the team to learn for future sprints. For this reason, it’s ideal when the same people can continue working together on the same Agile team from sprint to sprint.

In my slight exposure to Agile at my workplace, I have not yet seen a technical communicator assigned solely to one Agile team (unlike developers and testers, who tend to be dedicated to one team at a time). Working with multiple development teams is not new for most of us, of course. What is new, however, is the regular, close communication with all relevant parties throughout the cycle.

What Agile is not

Many techniques, tools, and buzzwords are associated with Agile: pair programming, stand-up meetings, cross-functional teams, burn-down lists, scrum masters, and so on. But these simply represent ways to work toward the values in the Agile Manifesto — they are neither necessary nor sufficient for Agile. So even though I can’t yet attend stand-up meetings or participate in a cross-functional Agile team, I have plenty of opportunity to become more Agile-esque and therefore work more effectively.

How do we fit into the process?

The prospect of moving to Agile development can raise a lot of questions for technical communicators:

• How will we manage without the usual project artifacts, like in-depth feature specifications, that we rely on to plan our work?
• How do we balance workload and handle context-shifting if we are assigned to more than one Agile team?
• How do we participate in the stand-up meetings if we are not in the same physical location as the rest of our team?
• If we’re constantly working in sprints, how do we schedule the maintenance and general quality-improvement work required for the upkeep of any documentation library?
• When do we work on documents that are not tied to user stories?
• How do we budget? If we’re not estimating by estimated page count at the outset and instead are allocating a percentage of our time to the Agile team for the number of days in the sprint, how do we account for varying amounts of content required?

I haven’t yet seen Agile in practice and so am not going to attempt to answer these questions now. They are important questions, however, and ones that my publications department is considering as we prepare to enter the new development environment. We hope to have answers in the next few months.  In the meantime…

Can I be Agile if my team isn’t there yet?

As a technical communicator, I follow the development environment I work in. In my unit, we currently work in a traditional “waterfall” environment: first requirements, then design, then execution, then testing, then bug fixing, then beta release, then more bug fixing, then a commercial release. I absolutely must adhere to this structure. I have certain deliverables due at the various stages along the way, and — likewise — I rely on planning documents and other artifacts from other groups. I can’t ignore this structure even if I want to. For the most part, then, I must wait for my unit to become Agile before I can truly be an Agile technical communicator myself.

Even if my team follows a waterfall development process, I can be an Agile technical communicator

But even though the milestones of the waterfall schedule rule my project and therefore dictate my activities, I can adopt several practices to become more Agile, on my own. Many of these are really simple, common-sense ideas.

1. Remember the customer

Because Agile requirements are written in the form of user stories, everyone on an Agile team is focussed on the customer needs.

Customer focus, or user advocacy, is hardly a new attitude for many technical communicators. Certainly, I have colleagues who complain of being the only user advocates on a development team, a feeling shared by many throughout the tech comm community. Most of us welcome such an approach to defining requirements!  For example, we may ask: “Is the customer better served by a description of each and every widget on the user interface, or by instructions on how to complete the essential tasks?” Technical communicators already ask such questions every day, questions that align perfectly with the Agile philosophy.

2. Divide work into small tasks

In the planning phase, Agile teams break the user stories into smaller tasks that can be completed within a sprint. Tasks too large for a sprint are subdivided. This approach:

• Gives greater visibility into the work to be done
• Helps reveal which tasks might be blocking other tasks
• Allows work to be divided among team members
• Makes estimates more accurate
• Gives the team a sense of accomplishment as tasks move from “in progress” to “done”

Whether or not I am on an Agile team, such a strategy helps me stay on track, be transparent, and more easily hand-off or reschedule tasks when I am behind schedule. I have already started looking at my work this way. For instance, instead of a large task called “do peer reviews,” ( which might be 8 hours, 24 hours, or 72 hours of work—who knows?!), I now list the individual documents I have to review. And I list them publicly and have only one or two on the go at a time.

3. Use a task board

The task board is the single most important information radiator that an Agile team has.              — Tom Perry

A public, tangible (that is, non-electronic) task board plays a key role in many Agile development environments. In its simplest form, the board shows task progress. Team members consult the board every day to move sticky notes, evaluate progress, and adjust estimates.

Because the board is public and updated daily by those doing the work, it increases the project’s transparency and the team’s accountability, and it clearly shows when tasks aren’t progressing. Unlike a project file that lives on the project manager’s computer, with sporadic updates and weekly reviews, a task board on public display is more likely to be accurate and up-to-date. Moreover, a task board is lightweight: tasks are described by a word or phrase that fits nicely on a tiny sticky note (some people joke that 3-M invented Agile). No heavy-duty specifications are needed.

The Agile task board promotes transparency and accountability, and keeps the Agile technical communicator on track

We all have to-do lists: in a notebook, online, or scribbled on a napkin. A task board is really nothing more than a physical, public, up-to-date, to-do list. And it’s something that I, as an individual, can adopt right away.

4. Improve communication

My team is distributed across four countries on three continents, so interaction in-person is rare. If I need to contact someone, I tend to send email rather than picking up the phone. But Agile emphasizes individuals and interactions. One of its key principles is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This lets people work in the same direction and quickly respond to change. Face-to-face isn’t often possible for me, given the geography, but picking up the phone is something that I can and will do.

 

5. Respond to change over following a plan

This is my favorite value from the Agile Manifesto. In the past, I have sometimes spent far too much time carefully planning my work only to be waylaid by circumstances. Despite careful effort, again and again I find that that my estimates are off, that I haven’t anticipated or mitigated the right risks, and that I don’t always end up in the same place as the software developers because requirements change without enough communication. So it was good to hear our Agile trainer say that perfect long-term planning is impossible in the inevitable “cone of uncertainty” at the beginning of any software development project.

The Cone of Uncertainty: Estimates at the outset of a project are likely to be off.

The cone of uncertainty describes how our knowledge improves our estimates as time advances on a project. At the outset, we know very little, and our estimates are almost certain to be off. (Whether we over- or under-estimate may be a function of job title more than anything.) Only as the project progresses do we learn more and make better projections based on that knowledge.

The weakness of the traditional waterfall method of planning and executing a project lies in the requirement that we make long-term projections precisely when our estimates are going to be most inaccurate. If we instead make estimates for the shorter term and regularly revisit and adjust them, our plans evolve more effectively, and accurately. As distinguished engineer Dr. Barry Boehm noted more than 30 years ago:  “The further a project progressed, the more accurate the estimates for the remaining effort and time became.”

 

Practically speaking, this means I will:

• Plan less (if I can get away with it!), and focus on the short-term.
• Beat myself up less when I “get it wrong.”
• Fail early, communicate, and readjust.

6. Timebox

Many Agile projects fix deadlines firmly but allow adjustments to the scope, an  approach known as timeboxing. Timeboxing focuses team members on the most important deliverables: if you must finish on a certain date, you’ll likely work on the top-priority items first. Contrast this with a project that has a flexible deadline. In such a project, you can choose to work on the easiest items first, perhaps negotiating a new deadline if necessary. Important items are crunched at the end of a cycle where quality may suffer, or the deadline shifts far enough to dissatisfy the customer.

Prioritization is the key to successful timeboxing. In the sprint-planning phase, Agile team members work together to prioritize tasks.

As an individual, I can use timeboxing to limit effort on my own work so that I don’t have things hanging out on my to-do list forever. Instead, I focus on the high-priority work in my queue, which helps me overcome some of my weaknesses: procrastination, perfectionism, and over-commitment.

7. Limit work-in-progress

Another of my weaknesses is a tendency to work on several tasks simultaneously. That may sound like a virtue, but researchers have shown that humans aren’t so good at multi-tasking. When we have a lot going at once, we miss details and take longer to get things done. And only things done by the end of a cycle can be considered “done” — work-in-progress doesn’t help us if we’re not finished when the deadline hits.

Kanban (a form of lean programming related to Agile) recommends limiting the number of in-progress tasks to two. So this means that if there are already two sticky notes in the middle column of my task board, and I want to start on another, I have to finish one first. This sounds good to me.

Conclusion: I Can Be An Agile Technical Communicator Now

While I look forward to eventually being part of a full-fledged cross-functional Agile team, I don’t have to wait to get started. Even in my traditional waterfall environment, I have started to bring some of the principles of Agile into my day-to-day working life. Ironically perhaps, the steps I have taken so far have made me feel more a part of the team than I did before, even though I am borrowing from a different model. The task management techniques and the emphasis on communication that I learned in my Agile training are already making a difference.

References:

• Agile Manifesto. http://agilemanifesto.org/principles.htm
• Boeme, B. W. 1981. Software Engineering Economics. Englewood Cliffs, NJ : Prentice-Hall, 1981 (http://csse.usc.edu/csse/TECHRPTS/1984/usccse84-500/usccse84-500.pdf)
• Hallowell, Edward M.. Crazy Busy: Overstretched, Overbooked, and About to Snap! Strategies for Handling Your Fast-Paced Life. 2007. Ballantine Books.
• Perry, Tom. 2007. Agile Tools: Tools for the Agile Practitioner. http://agiletools.wordpress.com/2007/11/24/task-boards-telling-a-compelling-agile-story/