Our March 2012 Meeting: “Agile Documentation (Hi, Honey, I joined a cult!)”

Meetings, STC NorthBay Blog, Training, Uncategorized

Fundamentals of Agile Development
Mike Ziegenhagen, a technical writer and tech pubs manager in the software business for more than 18 years, has also specialized in documenting virtual worlds. One virtual world you may be familiar with is the one that “relates” (read “force fits”) product specifications to actual products. If you have ever suffered from the disconnect between fantasy specs and real deliverables, you will appreciate how the Agile process keeps a tight rein on development, making sure that each feature works properly before subsequent features are added — all executed in cycles of generally a couple of weeks at a time. The Agile approach embodies the principal of iterative and incremental development: Never get ahead of yourself, and keep it real. While “Agile Documentation” is not yet a topic on Wikipedia, it is not hard to extrapolate from stepwise development to stepwise documentation.

Mike spoke from experience. For the past two years he’s worked with a team of writers in a large enterprise software company that embraced Agile software development from the top management team down. (Without proper buy-in and support at the highest levels, it is hard to realize the benefits of this approach.)

Some Basic Principles
An Agile Manifesto lists four fundamental priorities. Favor . . .

  • Individuals and interactions over Processes and tools
  • Working software over Comprehensive documentation
  • Customer collaboration over Contract management
  • Responding to change over Following a plan

    • There remains value in the functions on the right, but these should never dominate.

    Real reality, not the virtual variety, is key. Unlike the all-to-familiar MS Project approach, where 100-page best-laid plans of mice and men soon go stale, Agile requires daily truth-telling sessions in meat space. Each participant stands and briefly addresses three questions: What have you done since yesterday (in an interval known as a “sprint”), what are you doing today , and are you being blocked from what you have to do? A series of sprints comprises a release for the multiple teams, called a scrum (yes, development can be bruising like rugby). In the sport, a scrum restarts the game after a minor infraction — a fair analogy. In development, a Scrum Master ensures that progress is made at each sprint truth-telling session. At the top of the process is the Product Owner — who is closest to the “first customer” and knows precisely what a potential buyer needs, wants, and is willing to pay for. All other features can come after the basic functionality of the product is rock solid. What a concept!

    And the benefits?

  • Avoid the “spec monster” approach, which creates bloatware or (worse yet!) phantomware.
  • Avoid turning the prototype into a product (seen that fantasy before?).
  • Meet changing needs and markets easily, simply by adding or removing iterations (you can always catch up later if you need to).
  • Address bugs early and often, preventing unplanned delays in product releases.

    • Agile Documentation
    Until someone writes the Agile Documentation page on Wikipedia, here are the principles Mike has arrived at from his experience as a writer involved in the Agile process:

  • Don’t sweat providing documentation for discoverable tasks. (Click OK already!)
  • It is virtuous to keep things simple, but only if you provide enough information for the user to accomplish a task.
  • Provide simple documentation for complex tasks (keeping in mind the principle above).
  • Don’t make documentation more than it deserves to be. Documentation is part of the process of users doing their work; it is not the process (communicate rather than “document”).
  • Write the documentation you would like to read. (What a concept!)
  • Follow the principle of Occam’s razor: Keep things as simple as possible, but no simpler (see above).
  • Build documents from the center outward, as time allows. Use the software, take notes, flesh it out. Do not write the outline and fill it in with content! (cf. “fantasy specs” above)

    • But Wait, There’s More!

    This should be enough to get you interested and motivated to learn more about Agile. And what better resource for that than the excellent slides you may have missed if you were not at our meeting. Many who attended will have some thoughtful insights to take back to the workplace.

    So dig a bit and see what Agile could do for you!

    2 thoughts on “Our March 2012 Meeting: “Agile Documentation (Hi, Honey, I joined a cult!)””

    2. So how is this agile documentation different from minimalism?

      Quoting from http://www.namahn.com/resources/documents/note-minimalism.pdf which is paraphrasing Carroll’s Nuremburg Funnel (1990):

      – Train users on real tasks
      – Provide action-oriented learning
      – Help users get started fast
      – Guide discovery and exploration
      – Rely on the user to think and improvise
      – Exploit the user’s prior knowledge and experience
      – Slash the verbiage (“less is more”)
      – Allow for reading in any order by providing modular units of information

    Comments are closed.