Your SlideShare is downloading. ×
0
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Agile And Documentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile And Documentation

1,385

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,385
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Developing a workable documentation process by “being” Agile rather than “doing” Agile
  • 2. Don’t just do Agile… Be Agile
  • 3. <ul><li>The title of this presentation is a bit misleading. If you read up on any Agile methodology, you will find that there is very little written about documentation. That’s why I like to apply the spirit of being Agile rather than “doing” anything specific. </li></ul>
  • 4. The Advent of Agile
  • 5. <ul><li>Agile started in Februrary 2001 when 17 practitioners from different methodologies came together on a trip to the Utah mountains to ski and relax and try to find common ground. Because of the wide differences in their approaches, the didn’t expect to agree on anything substantive. </li></ul><ul><li>At the end of the weekend, they were supprised at the outcome and at what they had agreed on: which were the four value statements and the twelve supporting principles which together became the Manifesto for Agile Software Development. </li></ul>
  • 6. What is Agile anyway?
  • 7. Individuals and Interactions <ul><li>over processes and tools </li></ul>
  • 8. <ul><li>Agile values individuals and interactions over processes and tools. The best way to convey information is by talking face-to-face, which is why Agile teams try to be co-located and self-organizing. </li></ul>
  • 9. Working Software <ul><li>over </li></ul><ul><li>comprehensive </li></ul><ul><li>documentation </li></ul>
  • 10. <ul><li>Agile values working software over comprehensive documentation. It’s not that documentation is ignored, but preference is given to the software and to documentation that is a living part of the process. Working software is the primary measure of success. </li></ul>
  • 11. Customer Collaboration <ul><li>over contract negotiation </li></ul>
  • 12. <ul><li>Agile values customer collaboration over contract negotiation. Business people and developers should be working together daily – which is why you will often find customer representatives on the team… Agile methods stress customer involvement. </li></ul>
  • 13. Responding to Change <ul><li>over following a plan </li></ul>
  • 14. <ul><li>Agile values responding to change over following a plan. Changing requirements are actually welcomed, as they are an opportunity to iterate closer and closer to what the customer really needs. This doesn’t mean, however, that Agilists don’t plan – but planning often involves 3x5 cards with user stories on them. </li></ul>
  • 15. Sustainable Pace <ul><li>Continuous attention to technical excellence and good design </li></ul>
  • 16. <ul><li>Agile processes are intended to promote sustainable development so that a constant pace can be maintained indefinitely. Agility is also enhanced by continuous attention to technical excellence and good design. </li></ul>
  • 17. Simplicity <ul><li>Self-Organizing Teams Reflection and Improvement </li></ul>
  • 18. <ul><li>Simplicity is the art of maximizing the amount of work not done. Teams that are self-organizing produce the best architecture, requirements, and design and, at regular intervals, the team reflects on how to become more effective, and adjusts its behaviour to become more effective. </li></ul>
  • 19. Methodologies are Prescriptive
  • 20. <ul><li>The different Agile methodologies are as prescriptive as any other methodology. They all have various practices that they recommend, and which are designed to help you to achieve better results. </li></ul>
  • 21. No Prescription for Documentation
  • 22. <ul><li>However, there is very little about documentation practices – except for how to write better user stories and use cases. </li></ul>
  • 23. So what does it mean for technical writers?
  • 24. <ul><li>Many practitioners actually include technical writer as one of the roles in an Agile team… the key concept here is that the writer is actually a part of the team – not separate from it. That means participating in daily meetings and interacting with the engineers. </li></ul>
  • 25. The biggest difference is the Mindset
  • 26. <ul><li>This can require a change in mindset if you are used to coming in, writing the documentation, and then moving on to another project. On an Agile team, you would be participating in the development process, being the voice of the user, and writing documentation in parallel with the development work. </li></ul>
  • 27. Integration with the Development Team
  • 28. <ul><li>Agile teams are cross-functional, so there are plenty of places where technical writers can contribute skills that are complimentary to the skills of the engineers. </li></ul>
  • 29. KIS and KIL <ul><li>and a dollop of Horse Sense </li></ul>
  • 30. <ul><li>You have to be flexible. Keep it simple, and keep it light. Don’t try to bend the process to fit the documentation, adapt the documentation so that it works with the team and the culture, and delivers only what the project needs. </li></ul>
  • 31. Documentation should be “Fit for Purpose”
  • 32. <ul><li>The documentation should be just enough, just in time to fulfill its purpose… and “good enough” is often the measure of success. Use the documentation as part of the testing, so that becomes part of the process. </li></ul>
  • 33. Focus on Users and their Needs
  • 34. <ul><li>Because technical writers usually have a good understanding of the users, they can often help with task analyses and designing workflows. Writing documentation also usually brings with it a good understanding of the behaviour of the system from the user’s perspective. You can use this knowledge in testing. </li></ul>
  • 35. Develop Design Patterns
  • 36. <ul><li>Develop design patters for documentation components, much like engineers use design patterns for common system components. Create templates with reusable sections that can be mixed and matched. By the way – structured content doesn’t have to mean DITA. Create templates for units of structured content that you can copy and paste and fill in the blanks. </li></ul>
  • 37. Design for Change
  • 38. <ul><li>Try to write things once and put them in at an appropriate place in the information flow, then reference them from other places. Cover single tasks from end-to-end, then create a “cookbook” that strings the single tasks together to cover units of work. </li></ul>
  • 39. Whiteboards… <ul><li>and Markers… and Cameras… oh my! </li></ul>
  • 40. <ul><li>The tools can be simple… personally, I love my digital camera, and I use whiteboards – a lot. </li></ul><ul><li>The Agile Manifesto is available online at: http:// www.agilemanifesto.org </li></ul>
  • 41. Thank You

×