Rally:One Writer’s Perspective

Background

• 28 years in technical communications including Symantec, Autodesk, and Cisco.

• Participated in Rally-based projects for past three years.

• Seen varied approaches to Rally:– Rally-to-the-letter approach with daily scrums,

calculated burn rates, task balancing, and more– Sophisticated “to do” lists

What is Rally?

The Agile Manifesto• In February, 2001, 17 software developers met

at in Snowbird, Utah, to discuss lightweight development methods.

• They published the Manifesto for Agile Software Development to define an approach now known as agile software development.

What is Rally (contd)?

Agile Manifesto: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

What is Rally (contd)?The Agile Manifesto is based on twelve principles:1. Customer satisfaction by rapid delivery of useful software2. Welcome changing requirements, even late in development3. Working software is delivered frequently (weeks rather than months)4. Close, daily cooperation between business people and developers5. Projects built around individuals, who should be trusted6. Face-to-face conversation is the best form of communication (co-location)7. Working software is the principal measure of progress8. Sustainable development, able to maintain a constant pace9. Continuous attention to technical excellence and good design10. Simplicity—the art of maximizing the amount of work not done—is essential11. Self-organizing teams12. Regular adaptation to changing circumstances

Personal Thoughts

• Agile is simply another development model• Others:– Rapid Application Development (RAD) developed

in the mid-1970s– Structured Systems Analysis and Design Method

(SSADM) – Waterfall– Dozens more

Personal Thoughts (contd)

• Models are simply…..models• Regardless of model, software development

goals are the same: produce quality software that meets the needs of customers in the shortest amount of time possible.

• Every engineering team has an approach that reflects their management and unique collection of engineering personalities.

Personal Thoughts (contd)

As a documentation writer, the methodology really should not matter; our goals are the same:

to help customers:• Use the application quickly and efficiently.• Get the most benefit from their investment.

Personal Thoughts (contd)

To that end, getting the information and understanding to produce accurate, high quality documentation….is always a struggle!

Personal Thoughts (contd)

Waterfall Method---Engineers (should) prepare functional specs to allow the writer to complete the user documentation. The reality? • Some specs are great; others are less so.• Some engineers are great writers; others less so.• Engineers often not native English speakers.• Specs prepared at start of a release but not

updated.

Personal Thoughts (contd)

Agile---User stories (should) contain sufficient information to allow the writer to complete the user documentation. Details can be in the story or in docs attached to the story.The reality? Some user stories contain detailed information; others do not.

Demo

Cisco Prime Performance Manager:• All user stories have a Doc Required flag.• If set to true, in the opinion of the engineer,

the user story requires user documentation changes.

• If the Doc Required flag is on, the engineer (should) add a Doc Notes task to the story describing the documentation impact.

Demo (contd)

Demo (contd)Rally stories are in one of four states: • Defined• In Progress• Completed• AcceptedDoc development begins with Accepted stories, then moves to Completed ones.

Demo (contd)Rally stories with Doc Required = True should contain a Doc Note task explaining what the documentation changes are.

Demo (contd)Doc Required stories allow accurate completion reporting at weekly program team meetings:• Completed program:

• Program just started:

Final Thoughts• It’s not the methodology; it’s the people. • Communicative, articulate engineers make documentation development easy.• Non-communicative, inarticulate engineers make one feel like a detective looking for

clues in a murder case.• But that’s what makes tech doc writing…..

So much fun!!!