Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Information Development in an Agile Environment


Published on

Information Development /Technical Writing / Technical Documentation in an Agile Environment

Published in: Technology, Business
  • Be the first to comment

Information Development in an Agile Environment

  1. 1. Information Development in an Agile environment Neeraj Bhatia <ul><li>Symantec Corporation </li></ul>
  2. 2. Agenda The transition to an Agile environment 1 Planning the transition 2 InfoDev considerations 3 What changed in the Agile model? 4 Lessons learnt 5
  3. 3. Agile Terminology Backlog Prioritized list of requirements User story Requirement formulated in the everyday business language of the user Feature breakdown Process of breaking down features/requirements into small estimable user stories Iteration/Sprint Single development cycle, usually measured in weeks Hardening iteration Iteration dedicated to eliminate technical debt, including bugs, integration testing, final QA, docs, etc. Scrum team Cross-functional team working on a set of user stories
  4. 4. Our Agile roadmap 2010 2009 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 * All numbers approximate
  5. 5. Why Agile? <ul><li>Long development cycles, time to market considerations </li></ul><ul><li>Development delays, lack of predictability around release schedules </li></ul><ul><li>Quality issues: late engagement for QA and test teams </li></ul><ul><li>Inability to respond to changing marketplace </li></ul><ul><li>New products require constant adjustment in response to customer feedback </li></ul><ul><li>The theory that moving to an Agile environment will address these issues </li></ul>
  6. 6. Planning the transition Presentation Identifier Goes Here
  7. 7. Initial reactions “ No more feature freeze! We can now add features in the last iteration if we need to.” Product management “ No more FDDs!” Engineering “ No FDDs? Hold on … we probably need to discuss the process again.” QA, InfoDev “ Can’t we ship the product when Development is done? Do you really need the hardening iterations?”
  8. 8. Getting Started: Decisions, decisions <ul><li>Iteration duration: Two weeks, three weeks, four weeks? </li></ul><ul><li>Entry and exit criteria: What do you mean when you say Done? </li></ul><ul><li>Tracking tool evaluation: VersionOne, Etrack, Accept360? </li></ul><ul><li>Team composition: Scrum teams, other teams? </li></ul><ul><li>Meeting frequency </li></ul><ul><li>End-of-iteration demos: Logistics, participation? </li></ul><ul><li>Training: Concepts and tools </li></ul>
  9. 9. Team Organization and Communication Team Charter Composition InfoDev representative Release Team Cross-functional team driving the release One representative from each functional group Lead/Manager Team of N Cross-functional team driving a theme or a feature set PM, TPM, Support, Dev, QA, Testing, InfoDev Lead writer for theme/feature set Scrum team Cross-functional team executing on a feature set Dev, QA, InfoDev Writer working on the feature set Release Team Team of N #3 Scrum Team 1 Scrum Team 2 Team of N #2 Scrum Team 3 Scrum Team 4
  10. 10. <ul><li>Repeated small bursts of software development cycles. </li></ul><ul><li>3 week period </li></ul><ul><ul><li>First 2 days to plan the ~2 weeks ahead. </li></ul></ul><ul><ul><li>Next ~2+ weeks of execution. </li></ul></ul><ul><ul><li>Last 2 days to meet exit criteria </li></ul></ul>Anatomy of an iteration (Product A)
  11. 11. Information Development considerations
  12. 12. Information Development considerations <ul><li>Reduce lag between development and documentation </li></ul><ul><li>Link feature completion to documentation completion </li></ul><ul><li>Complete documentation tasks within iteration </li></ul><ul><li>Author and review content in same iteration </li></ul><ul><li>Assess each user story for doc impact </li></ul><ul><li>Define entry and exit criteria for documentation </li></ul><ul><li>Use hardening iterations for end-to-end doc reviews and to finalize the content </li></ul>
  13. 13. InfoDev tasks during an iteration
  14. 14. Documentation review process
  15. 15. Authoring and review cycles Week 1 Week 2 Week 3 Week 4 Week 1 Week 2 Week 3 Week 4 Sprint n Sprint n+1
  16. 16. What changed in the Agile model?
  17. 17. What changed with Agile <ul><li>Documentation approach </li></ul><ul><ul><li>From “I first need to understand where this fits in the doc set.” </li></ul></ul><ul><ul><li>To “Let me write it as a standalone piece and get it reviewed. We will handle content placement later.” </li></ul></ul><ul><li>Documentation reviews </li></ul><ul><ul><li>From “Review pages 23, 347, and 460 of the 800 page guide.” </li></ul></ul><ul><ul><li>To “Review this two page chunk that describes your new command.” </li></ul></ul><ul><li>Writer morale, relationship with Engineering </li></ul><ul><ul><li>From “Engineering always provides info at the very last minute.” </li></ul></ul><ul><ul><li>To “What my scrum team is working on will impact your docs too” </li></ul></ul><ul><li>Shift in accountability from InfoDev to the scrum team </li></ul><ul><ul><li>From “We need these 1200 messages reviewed by InfoDev.” </li></ul></ul><ul><ul><li>To “How can we help in getting these 1200 messages reviewed?” </li></ul></ul><ul><ul><li>Of course, there were ups and downs </li></ul></ul>
  18. 18. InfoDev Scorecard <ul><li>Documentation more aligned with Development and QA schedules. </li></ul><ul><li>Less rework, less churn during final reviews. </li></ul><ul><li>More doc issues addressed during the release; less deferrals. </li></ul><ul><li>Better control on task and incident backlog throughout release. </li></ul><ul><li>Pulled in RTM by two weeks. </li></ul>* Product A data. All numbers approximate Metric X.0 Y.0 Number of incidents opened during final doc reviews 200 60 Doc review incidents as % of total doc incidents 33 20 Deferred doc incidents 50 0 Open incidents one month before RTM 200 40
  19. 19. What did we learn?
  20. 20. What did we learn? <ul><li>Agile methods work, even in cross-site environments. </li></ul><ul><ul><li>Requires some flexibility in terms of meeting times and frequency. </li></ul></ul><ul><ul><li>Centralized tracking tools and communication helps. </li></ul></ul><ul><li>Choose your iteration. Some tasks are best done in the “next” iteration. </li></ul><ul><ul><li>Prevents rework, especially for GUIs and wizards. </li></ul></ul><ul><li>Plan for the hardening iterations. </li></ul><ul><ul><li>Hardening iterations are important. </li></ul></ul><ul><ul><li>Development during hardening iterations can take away some benefits of the Agile methodology. </li></ul></ul><ul><li>Choose your meetings. </li></ul><ul><ul><li>Scrum meetings are important. Attending each meeting called by the scrum lead may not be a good use of writer time. </li></ul></ul><ul><li>Manage your workload. Maintain a sustainable cadence. </li></ul>
  21. 21. What did we learn? <ul><li>Linking development and documentation tasks is a key enabler. </li></ul><ul><ul><li>Use tracking tools to create parent-child relationships between features and documentation. This helps shift accountability for doc tasks from writers to scrum teams. </li></ul></ul><ul><ul><li>Create tasks for documentation development, reviews, and integration. </li></ul></ul><ul><li>A topic-based approach complements Agile development practices. </li></ul><ul><ul><li>Task assignment by module/feature as against by book. </li></ul></ul><ul><li>We may never get 100% Agile. </li></ul><ul><li>But Partially Agile is better than Completely Waterfall. </li></ul>
  22. 22. Neeraj Bhatia [email_address]