Agile
      (from a technical writer’s perspective)




Presented by: Tara Charter, Business Analyst/Technical
           ...
Introduction & Background
Introduction / background
              (Agile from a technical writer’s perspective)

Fresh from 3 years of RUP, I starte...
Agenda
AGENDA
         (RUP / GUP from a technical writer’s perspective)

•   Where is the requirements management tool?
•   Twee...
The requirements
management tool is a … a …
     A … WIKI?!?!?!?
         (WHAT?!?!?!?!)
The requirements management tool is a wiki?
         (Agile from a technical writer’s perspective)


• Use a Wiki bible
• ...
Tweet Up!
(It’s time to rise to the technology occasion)
Tweet Up!
              (Agile from a technical writer’s perspective)

•   Get Involved
•   Stay in the Middle
•   Attend ...
RUP into Agile
Agile in a Nutshell
             (Agile from a technical writer’s perspective)

• Adaptive, Simple, Less Formal Documentat...
Why the divergence
        (Agile from a technical writer’s perspective)


But RUP was so good
• For complexity
• For long...
RUP into Agile
         (Agile from a technical writer’s perspective)


Taking RUP into Agile
  – Keep the proof of concep...
Agile – What might be missing
        (Agile from a technical writer’s perspective)


Be Sure You Can Still Answer These
 ...
Their Daily Life with Agile
  (what the development team does every day)
Their Daily Life with Agile
           (Agile from a technical writer’s perspective)

Daily Agile Recipe – for the develop...
My Daily Life with Agile
My Daily Life with Agile
          (Agile from a technical writer’s perspective)


Daily Agile Recipe – for the Technical ...
RUP vs Agile
The devil is still in the details.
          (Agile from a technical writer’s perspective)

It costs money to fix programm...
The devil is still in the details.
         (Agile from a technical writer’s perspective)

                               ...
The devil is still in the details.
        (Agile from a technical writer’s perspective)

Result:
Efforts to produce
  bet...
The devil is still in the details.
        (Agile from a technical writer’s perspective)

Why:
When the business
 analyst ...
The devil is still in the details.
        (Agile from a technical writer’s perspective)

Benefits:
Timely and Reusable
  ...
Surviving Weekly Iterations
Deliverables per Iteration
       (RUP / GUP from a technical writer’s perspective)


Business Analyst / Technical Writer
...
Lessons Learned
Lessons Learned
      (RUP / GUP from a technical writer’s perspective)

• Get corporate accounts with local businesses
  ...
Q&A
Upcoming SlideShare
Loading in...5
×

Agile And Technical Writing

2,564

Published on

My experience with Agile. How I transformed my business analysis and technical writing techniques to fit the Agile world (coming from RUP).

Published in: Business, Technology
2 Comments
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,564
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
2
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Agile And Technical Writing"

  1. 1. Agile (from a technical writer’s perspective) Presented by: Tara Charter, Business Analyst/Technical Communications Specialist 1/31/2009
  2. 2. Introduction & Background
  3. 3. Introduction / background (Agile from a technical writer’s perspective) Fresh from 3 years of RUP, I started an Agile consulting project in July of 2008 – at a startup company aiming to re- develop an existing eCommerce Web application. “What is Agile?” I had been voraciously studying this ‘new’ methodology, even attended workshops, and I couldn’t wait to begin this new project. Time would fly, waste would be minimal, and everybody would work efficiently! My first day on the job, I was not new to Software Development – or Information Technology, having been part of the IT world for 19 years. As a consultant and employee, I had seen lots of IT projects start and end – some successfully, some not so successfully. However, little did I know that I would live, eat, breathe Agile for the next 6 months!!
  4. 4. Agenda
  5. 5. AGENDA (RUP / GUP from a technical writer’s perspective) • Where is the requirements management tool? • Tweet up! • RUP into Agile • Their Daily Life with Agile • My Daily life with Agile • RUP vs Agile • Surviving Weekly Iterations • Lessons Learned • Q&A
  6. 6. The requirements management tool is a … a … A … WIKI?!?!?!? (WHAT?!?!?!?!)
  7. 7. The requirements management tool is a wiki? (Agile from a technical writer’s perspective) • Use a Wiki bible • Organize it the way you would a project plan • Set up a left-side navigation to Schedule, User Stories, UATs, Developers Notes, and Throw-Away • Empower the team to read/write • Update constantly • Consult the Change History daily
  8. 8. Tweet Up! (It’s time to rise to the technology occasion)
  9. 9. Tweet Up! (Agile from a technical writer’s perspective) • Get Involved • Stay in the Middle • Attend all Stand Ups • Contribute to Stand Ups • Co Locate with the Team • Attend Code Reviews • Attend Lunches, Off-site ‘Meetings’ • Play in the same sandbox • Get a copy of the local code environment • Use the same tools (For me this included MacBook, iPod, Gmail, Pigeon, Skype, Windows Messenger, Blackberry, iPhone, Google Docs, Glassfish, Hudson • Learn the Vocab (follow blogs, twitters, instant messages, Facebook)
  10. 10. RUP into Agile
  11. 11. Agile in a Nutshell (Agile from a technical writer’s perspective) • Adaptive, Simple, Less Formal Documentation • More informal and centralized documentation (Wiki) • Can quickly change direction in a day • Favors advanced programming methods • Favors more experienced team members • Works better when customers are on site • Rewards independent thinking • Rapid, continuous delivery of feature sets • If it works, it’s done • Welcome late changes • Osmotic communication • Face-to-face communication • Data refactoring along the way • Architecture refactoring along the way
  12. 12. Why the divergence (Agile from a technical writer’s perspective) But RUP was so good • For complexity • For longer project lengths • For more iterations And Agile is even better • At working in changes to requirements • At presenting feature sets sooner • At testing and fixing sooner
  13. 13. RUP into Agile (Agile from a technical writer’s perspective) Taking RUP into Agile – Keep the proof of concept – Add story point estimating – Replace use cases with user stories – Replace detailed requirements with detailed UATs – Keep the automated testing tools – Document the test results – Everyone is an author on the wiki
  14. 14. Agile – What might be missing (Agile from a technical writer’s perspective) Be Sure You Can Still Answer These Questions: – How do you know when you’re done? – How do you know you’ve got good requirements? – How do you know the requirements are valid? – How do you know the system meets requirements? – Why did we make that change?
  15. 15. Their Daily Life with Agile (what the development team does every day)
  16. 16. Their Daily Life with Agile (Agile from a technical writer’s perspective) Daily Agile Recipe – for the development team – Constant face-to-face communication • C’mon take them headphones off already! – A little standup in the morning • State what you’ve done the Last 24 hours, Next 24 hours, and major blockers – in 2 minutes or less – What did you say, honey? • The Agile team is your new family. Get used to it. – Be your own best judge • Find someone you can ping things off – make a decision – and then move on!
  17. 17. My Daily Life with Agile
  18. 18. My Daily Life with Agile (Agile from a technical writer’s perspective) Daily Agile Recipe – for the Technical Writer – It’s Okay, there is a ‘change history’! • Cringe and then give everyone read/write access to the wiki. – Get in the middle • Document everything that you hear and see. – Extreme Technical Writing • Get ready to translate quickly and then move on.
  19. 19. RUP vs Agile
  20. 20. The devil is still in the details. (Agile from a technical writer’s perspective) It costs money to fix programmatic mistakes in any SDLC. If the requirements are ambiguous, unclear, invalid, then the application will be rejected no matter how good it is.
  21. 21. The devil is still in the details. (Agile from a technical writer’s perspective) Iterative Because each iteration Documentation results in an (Specifications, User Guides, executable release, Online Help) the requirements can be validated sooner and so the programmatic errors could be fixed sooner… Source for original graph without documentation notation: From Waterfall to Iterative Development—A Challenging Transition for Project Managers Philippe Kruchten. Rational Software White Paper.
  22. 22. The devil is still in the details. (Agile from a technical writer’s perspective) Result: Efforts to produce better documentation sooner increases. The documentation is more likely to mirror the current task at hand and so the documentation is less defective.
  23. 23. The devil is still in the details. (Agile from a technical writer’s perspective) Why: When the business analyst and documentation resources are closer to the source of the information and the information is new and current, the documentation is less likely to contain defects and is also reusable sooner.
  24. 24. The devil is still in the details. (Agile from a technical writer’s perspective) Benefits: Timely and Reusable documentation is more cost effective. Timely uses of reusable end-user documentation include training and marketing materials.
  25. 25. Surviving Weekly Iterations
  26. 26. Deliverables per Iteration (RUP / GUP from a technical writer’s perspective) Business Analyst / Technical Writer Deliverables per Iteration – Updated user stories and UATs for the last sprint (input to QA and testing). – Current sprint’s user stories and UATs. – Updated end-user documentation. • That’s right, write the user guide as you go. – Input to the same news feeds that everyone else is subscribing to – get on the same twitters, blogs, facebook groups, whatever.
  27. 27. Lessons Learned
  28. 28. Lessons Learned (RUP / GUP from a technical writer’s perspective) • Get corporate accounts with local businesses who deliver breakfast and lunch. • Twitter is your best friend. So is your laptop. • Forget about spreading workload evenly throughout the lifecycle of the project – just worry about TODAY. • Bring stakeholders in sooner – and more often. Don’t be afraid of them! • Use and pay attention to automated testing to detect errors. • Same as with RUP: Use documentation to test requirements -earlier. EARLIER!
  29. 29. Q&A

×