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 software 2.Welcome changing requirements, even late in development 3.Working software is delivered frequently (weeks rather than months) 4.Close, daily cooperation between business people and developers 5.Projects built around individuals, who should be trusted 6.Face-to-face conversation is the best form of communication (co- location) 7.Working software is the principal measure of progress 8.Sustainable development, able to maintain a constant pace 9.Continuous attention to technical excellence and good design 10.Simplicity—the art of maximizing the amount of work not done—is essential 11.Self-organizing teams 12.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)

Rally stories are in one of four states: Defined In Progress Completed Accepted Doc 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!!!