HeraTech

January 27, 2010

Agile Tenet #11 – Self Organizing Teams

Filed under: Uncategorized — heratech @ 9:24 am
Tags: , , ,

Number elevenEleventh in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can’t) be applied or adapted to technical writing.

*****

The best architectures, requirements, and designs emerge from self-organizing teams.

Who is more familiar with the code base – management or the developers who actually wrote the code? I can hear you thinking “Duh, the developers!” Of course.

Who is more familiar with the documentation – management or the writers who spend their day researching, writing, and organizing the content? Again, the answer seems a little bit obvious, doesn’t it?

And yet how many times have we experienced managers trying to do our jobs when they haven’t got the foggiest idea what our work actually entails? I’ve worked at a variety of jobs through the years, and I have learned to appreciate a manager who has come up through the ranks. Managers who started their careers as workers understand the issues that their employees are dealing with. And the wise manager knows when to get out of the way and let their teams go to work.

As you might guess, I’m rather fond of this particular tenet. Nothing irritates me more than a manager who doesn’t trust me to do my job without their constant supervision and input. Who knows my writing process better than I do? I’ve spent years learning and honing my craft, and over the years I’ve learned what works for me and what doesn’t work.

Donald Murray wrote about the writer’s toolbox. His writing books were full of different skills and techniques that his students and readers could add to their own writing toolboxes. You might pull out one technique for a particular project, then put it away and not use it for a very long time. Some people just sit down and start writing. Others need to do research, conduct interviews, take notes, brainstorm, write outlines, conduct interviews, or any number of other techniques. Our brains all work differently, we all process information differently, and we all work differently. Thinking that one writer’s process is the exactly the same as any other is a mistake that non-writers (and even writers) can make all too often.

If one person knows best how they work, wouldn’t it also make sense that the members of a team would know best how their team functions? If you’ve hired motivated individuals (you have hired motivated individuals, haven’t you?) you should be able to step back and let the team run itself.

And it has been interesting watching this tenet in action in our Scrum teams. Rather than have a manager impose structure and order from the outside, in Agile the ScrumMaster coaches the team, but lets them provide their own structure and order. The product owner writes the user stories and assigns priorities, but the teams decide which stories they will tackle in any given Sprint. The team decides amongst themselves which developers will tackle which stories.

I know that some people are uncomfortable making their own decisions. I’ve seen it manifest in everything from students who got stressed out when asked to provide their own opinion on a test (this wasn’t in my notes!) to coworkers who couldn’t make their own decisions without polling everyone in the office about what they should do. But these aren’t the sorts of people who would thrive in an Agile environment, they are most comfortable in an office hierarchy, where management tells them what to do and how to do it.

I wonder if I’m so comfortable with this self-directed approach because I went to Montessori school as a child? Reading over the Wikipedia entry, I noticed this passage:

Applying this method involves the teacher in viewing the child as having an inner natural guidance for its own perfect self-directed development. The role of the teacher is therefore to watch over the environment to remove any obstacles that would interfere with this natural development.

Sounds a bit like a ScrumMaster, whose job it is to coach and remove impediments, doesn’t it? Montessori is about providing an environment for learning. And I think that Agile is about providing an environment where productive work can occur.

December 22, 2009

Agile Tenet #3 – Deliver Frequently

Filed under: Uncategorized — heratech @ 8:09 am
Tags: , , ,

Number three Third in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can’t) be applied or adapted to technical writing.

*****

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

When I was working in a Waterfall development environment my writing process was long and drawn out, similar to writing a novel. I once worked a solid 18 months on a single release. The User’s Guide was almost completely revised, and weighed in at 450 pages by the time I was done. For that particular release I did nothing for three solid months but read through the hundreds of pages of specifications for the release, taking notes along the way of new applications being added to our application suite and new features. Then I struggled with my outline for several weeks, trying to figure out a structure that would accommodate the new material. I was writing notes and draft topics the whole time, but the new release had so many different applications, that it was hard to find a structure that would fit the wide range of new features. Once I settled on a structure, I spent almost a year playing with the software builds, exploring the new features, interviewing a dozen different product managers, writing and revising before the software and doc was actually released.

In Write to Learn Donald Murray describes techniques used by all writers (Collect, Focus, Order, Draft, and Clarify), and urges his students to adapt them to their needs. And that list describes my writing process pretty well. My technical writing textbook, How to Communicate Technical Information, breaks the writing process down to just Planning, Writing, and Revising. However you define your writing process, in an Agile environment it is severely compressed.

I’ve heard TWs estimate that they only spend between 25% to 40% of their time actually writing, with the rest of their time taken up with e-mail, meetings, planning, research, and other non-writing tasks. When you’re writing documentation in an Agile environment, your process is no longer the long slow march towards a major release. In an Agile environment, you’ve got to be much more efficient. You have much less time to think about what you’re going to write, because if you are going to deliver content by the end of the Sprint, you need to stay focused on tasks that support the writing.

I’ve already written about how I use modular writing, and some of the techniques I use for being ready to publish at all times. Making the switch from the long cycles of Waterfall to shorter Agile Sprints has not been as big a shift for me as it might be for writers who were not used to delivering information in small chunks. But even so, I’ve had to learn to let go of my own expectations for the documentation. There has always been a gap between the documentation that I want to deliver and the documentation that I can deliver in a given timeframe. With a shorter timeframe, that gap widens considerably. (Thank goodness tenet #9 is Attention to Excellence!)

It seems to me that one of the tricks of being an Agile technical writer is to be less like the novelist and more like a journalist on deadline, trying to scoop the competition with a big story. Journalists are continuously writing because they have to deliver content, be it a daily newspaper, news weekly, or monthly magazine. But unlike a journalist, the Agile TW can always go back and revise what they’ve written in a later iteration.

Deliver documentation frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale and delivery of smaller chunks of information.

November 23, 2009

Examining My Writing Process

Filed under: Uncategorized — heratech @ 8:24 am
Tags: , , , , , ,

Last Wednesday’s STC meeting got me thinking about my writing style again.  While I’m always writing, it’s not a linear progression from spec to outline to topics to completed project. 

Until I started working in an Agile environment, my progress on a project went something like this:

  1. Read the design specifications and functional specifications.  Try to get an idea of what features were being built.  If I was very lucky, the specs would include a use case, describing what the customer wanted the software to do.
  2. Count up the number of new applications, tabs, subtabs, actions, dialog boxes, buttons, etc.  This is usually the point when I could start estimating doc effort, as each feature and/or task will usually result in at least one new topic, with a small fudge factor added to cover additional concept or reference topics that might be required.
  3. Generate an outline based off the projected UI features.  Each tab or subtab generally gets a concept topic.  Each action, button, or dialog box usually gets at least one task topic, and sometimes two (as in “creating a widget” and “deleting a widget”).  Estimate the number of concept tasks for toolbars, types of widgets, possible widget statuses, commands, etc.
  4. Start writing procedures.  Open this, select that, enter something, click save.  If I’ve got a well written spec I can often start on a draft before the software is even coded.  Sometimes you can write a complete draft of procedure before the software is even stable.  But it’s more likely that I’ll end up writing a partial procedure with the first several steps of a draft procedure then write myself a note that “Click X and what happens next? Software crashes as of Build# on Date ##/##/##.” 
  5. Next I generally add reference material.  Depending on the software, it might be documenting toolbar buttons, icons, commands, possible statuses, etc.
  6. The last thing that I usually write are the concept topics: overviews of new features, descriptions of new tabs, subtabs, screens, best practices.  It usually takes a while to really “grok” the software and how customers will use it.

When we first made the switch to Agile in January 2009, my manager wanted to manage me like the rest of the development team.  The developers had user stories, I had documentation stories.   The developers generated a list of tasks and then estimated story points for their stories.  I generated a list of tasks and topics and attempted to estimate my doc stories.  The developers kept a burn down chart, and I did the same. 

The only problem was, writing documentation is not like writing code and I don’t have a linear writing process.  I don’t tend to start on a topic, write it, and move on to the next topic.  I tend to work on multiple topics at once, writing as much as I can on one topic before moving on to the next.  Sometimes I’ll have an insight in the car during my commute and will need to capture that before I forget it.  I keep notebooks in my car and in my purse so I can scribble notes to myself. 

My manager expected me to work like a developer.  To pick one task and work on it until it was completed.  But I couldn’t write the doc until there was completed code.  And the first four sprints we didn’t have completed code until the last day or two of the sprint.  So if I can’t write until the last couple of days of the sprint, what am I supposed to do for the first three weeks?  (I spent my time closing doc bugs, many of which had been open since before I was hired.)

I wonder how I’m supposed to adjust my writing process to fit into Agile. I’m a multitasker.  I usually work with multiple files open at once.  My brain tends to makes connections between what I’m doing and something that I will be doing in the future, or something that I wrote in the past.  I’m a list maker.  I’m frequently opening up files and making notes of questions, resources, further research to follow up on later.  Part of this is by necessity.  Writers almost never have the luxury of only working on one project at a time.  Especially lone writers.  Right now I’m writing an Installation Guide, working on fixing doc bugs for the next patch release, writing and estimating doc stories for the past several sprints of development.  And my work is dependent on having functional code.  If I try to work through a procedure and the feature isn’t complete yet, I’ll put the procedure aside and work on something else. 

At Wednesday’s STC meeting the two writers said that they document one sprint behind their Agile development teams.  Both of the writers have been doing Agile for three years.  Before we both got laid off, my manager and I had agreed that this was the approach we were going to try.  Now that I’m only working two days a week, I don’t really have a choice but to write the doc after the developers have finished a sprint.

And yet, at the Nashua Scrum Club meeting on Thursday, someone said that if you’re doing testing or writing documentation a sprint behind development that “You’re not doing Agile.”

So, am I doing Agile documentation?  This is a question that I have yet to answer.

Blog at WordPress.com.