3 Agile Insights or: How I learned to stop worrying and love the Scrum

For over a year, I have been the lone tech writer on an Agile team full of top-notch system analysts. I have to confess that I was nervous about the prospect of spending my whole morning working on the same project, with the same people. And my development skills are limited to HTML and a few ill-advised forays into JavaScript and Ruby. How would I contribute to such a team?

I’m happy to announce that although I am still not much of a programmer, I have discovered some interesting things about Agile. So off we go…

1. Agile is a mindset, not a prescription. When people say they are “doing Agile” or a project is being run as an “Agile project,”  I’ve discovered that there is probably some room for argument. They might be confusing Agile with something else.

The characteristics of Agile were cherry-picked from a variety of software development project approaches, including Waterfall, Extreme Programming (XP) and Scrum. Eventually some developers formally codified these principles in the Agile Manifesto. Although this makes it easier to describe Agile, it also makes it a bit more challenging to define it.

To work in Agile, team members gradually develop an “Agile Mindset” that favors consensus, small changes, continuous feedback and learning, and individual interaction. Being Agile means that team members operate under shared vision and personal accountability, while enjoying the autonomy that allows them to choose how to tackle the tasks they work on.

In my time with the Agile team, I found that this way of working was both more efficient and more satisfying. Each day was organized around value-added priorities rather than a fixed schedule.

2. The Agile Manifesto is open to (mis)interpretation.

In 2001, a group of 17 experienced programmers gathered at a ski resort in Utah to codify their common beliefs by creating the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I recently heard a project manager say that developers don’t like to write documentation because “the Agile Manifesto prohibits it.” As a tech writer and an Agilist, I had to object. Another person in the room helpfully piped up, “People over documentation, right?” No, not quite.

The second bullet above is the source of much confusion. Lazy developers might use this statement to get out of documenting their projects, but the developers I worked with understood that “working software over comprehensive documentation” didn’t mean “eliminate all documentation.”The clue comes in the final, bolded statement: “while there is value in the items on the right, we value the items on the left more.”

In an Agile mindset, documentation flows from working software and constant communication. It may come later in the process, or it may grow out of the user stories that guide each sprint. In a complex project, a technical writer can take on many of these documentation duties.

3. Tech writers have a stake in Agile development. At several junctures, our Agile team was threatened by reorganizations and efforts to mirror our success in other teams. We usually were able to fend off these threats by emphasizing team velocity: it takes time to bring a team through the “forming, storming, norming” stages, and we were unwilling to lose what we had.

But why keep a technical communicator embedded with the team? In my organization, only a handful of other projects had used Agile or Lean methodologies, and as far as I know, they never included technical communicators like me.

Technical communication experts suggest  that even though technical writers on Agile teams focus on content, they can contribute to the team effort by providing usability input or helping with end-user testing. This type of participation creates a more visible role for writers, and allows us to offer more informed opinions—assuming we’ve been paying attention all along, as we should.  It is also important to insist on accuracy by asking questions, gaining access to test systems and prototypes, and learning as much as possible about how the product works.

One of the criticisms of Agile is that its fast pace does not always lend itself to improving the user experience (UX) through testing. My presence enabled us to do a modest amount of usability testing to improve the interface. With limited resources, we performed 20 tests during a single four-month project. Because of the iterative nature of Agile, we were able to conduct two or three tests after each of the latest builds, recording impressions and problems to take back to the development team.

In conclusion, I plan to bring my Agile Mindset to future projects, whether or not they are using an Agile framework. The availability of different project management models means that teams can always figure out a way to work to best meet the needs of end-users.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s