State of Agile Implementation in Documentation Teams
- 1. State of Agile Implementation in Documentation Teams (Case study approach) Vasanth Vaidyanathan Project Manager & Agile Expert vasanth.vaidya@gmail.com tcworld conference: 02/20/2014, Bangalore
- 2. Agenda ● Agile Manifesto and Documentation ● Scrum Process ● Elements of Scrum ● Case study to understand state of agile documentation ● Review of survey results (written response) ● State of agile implementation ● Conclusion Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 2
- 3. Sounds familiar? ● ● Many writers are trying to figure out how to meet deadlines, write quality documentation, and stay sane as their software companies switch from the traditional “waterfall” method of development to the increasingly popular Agile methodology (Source: Scrumalliance.org) The combination of Agile development’s high speed, limited planning documentation, and short delivery cycles creates a unique set of challenges for documentation groups. These challenges require a shift in thinking about resource management, task allocation, and completeness of information in technical publications groups (Source: Comtech-serv.com) Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 3
- 4. Agile Manifesto and Documentation ● ● ● Agile Manifesto says “Working software over comprehensive documentation”. This may not refer to user documentation :-) This might refer to hundreds of artifacts being created during the course of software development. Scrum Primer 2.0 carries a reference to technical writers and documentation. Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 4
- 5. Scrum Process Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 5
- 6. Elements of Scrum ● Product Owner, Development Team, Scrum Master ● Product backlog, User stories ● Sprint planning meeting ● Sprint backlog ● Daily Scrum/standup meeting ● Sprint review and retrospective ● Potentially shippable product increment Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 6
- 7. The documentation angle To learn about agile adoption in documentation teams, we use a case study approach. Thanks to all those who participated in this study and helped to build this presentation. Sudha Bhat Manager, Information Development Unisys Global Services (IT services/consulting) Rajeev Jain Lead, Technical Publications Rightster (online video distribution) Srilakshmi Murthy Associate Lead, Technical Schneider Electric Publications (Energy management) K.S. Sundararajan Technical Communicator HCL Technologies (Offshore IT and software development company) Francis Anthony Information Architect & Manager Roamware (voice and data roaming) Rahimunnisa Lead Technical Writer Talisma Corporation Mayur Bhandarkar Technical Writer TIBCO Software Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 7
- 8. Feedback on Agile Implementation Survey – Written Response (R indicates response) ● Which agile methodology do you use? R1: Custom implementation of agile run by our internal software quality assurance department. ● Thus spake the scrum king: The Team in Scrum is seven plus or minus two people. What is the size of your scrum team? ➔ R1: 10-20 ➔ R2: 26 ➔ ➔ Feb 20, 2014 R3: We have a separate documentation scrum team R4: 8-10 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 8
- 9. Feedback on Agile Implementation Survey – Written Response ● Do writers work on nonscrum/other projects? ➔ ➔ Thus spake the scrum king: The Team avoids multitasking across multiple products or projects, to avoid the costly drain of divided attentions... Feb 20, 2014 R1: Writers could be assigned to other projects on part-time basis. R2: Some writers work on nonagile projects. They could be assigned as part time writers to agile teams. They are usually assigned to non-feature tasks like installation, release notes and API generation. If they are assigned to feature docs, they have a problem blending in quickly. (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 9
- 10. Feedback on Agile Implementation Survey – Written Response ● Are technical writers part of the scrum team(s)? ➔ ➔ Thus spake the scrum king: ● The Team in Scrum is “cross-functional” – it includes all the expertise necessary to deliver the potentially shippable product... Feb 20, 2014 ➔ R1: Part of the scrum team occasionally, but part of the sprint meeting. R2: Writers are part of several scrum teams. This means writers can’t attend all the daily standup meetings. R3: Part of more than one scrum team. If the input from both the scrum teams come late, it would be a challenge for the writer to meet the committed delivery date. (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 10
- 11. Feedback on Agile Implementation Survey – Written Response ● Is documentation created and reviewed during the sprint? ➔ Thus spake the scrum king: ● ... Definition of Done to be as close as possible to potentially shippable increment as that will decrease delay and risk... Feb 20, 2014 ➔ R1: User's Guide and Administration Guide are created within the sprint. But Reference Guide and Technical Notes are created outside the sprint. This is an additional effort not included in sprint planning. R2: Initial review during the sprint, but complete review happens after the (sprint) release. (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 11
- 12. Feedback on Agile Implementation Survey – Written Response ● Is documentation created and reviewed during the sprint? ➔ Thus spake the scrum king: ● ... Definition of Done to be as close as possible to potentially shippable increment as that will decrease delay and risk... Feb 20, 2014 R1: Most docs are written and reviewed within sprints and stories are marked as completed after the doc review is done. For delivering generic docs such as Reference Guides, we operate in nonagile mode and provide it for review at logical points in the development cycle. Most of these guides are fully reviewed and signed off during the stabilization sprint. (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 12
- 13. Feedback on Agile Implementation Survey – Written Response ● Is documentation created and reviewed during the sprint? ➔ ➔ Thus spake the scrum king: ● ... Definition of Done to be as close as possible to potentially shippable increment as that will decrease delay and risk... Feb 20, 2014 R1: Engineering is ahead by one sprint and this is agreed upon to avoid late inputs to documentation during the same sprint. R2: Documentation tasks can overlap across sprints if feature development/testing are spread across multiple sprints. At the end of a sprint, documentation might not necessarily be release ready. (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 13
- 14. Feedback on Agile Implementation Survey – Written Response ● Is documentation plan kept separately? ➔ ● Thus spake the scrum king: ● ... Plan which user stories to implement in the sprint planning meeting. Feb 20, 2014 R1: We do 45 minute separate sprint meeting for documentation. R2: Documentation tasks are part of engineering stories and they are added to the sprint backlog. However, there is a project plan to track the overall documentation deliverables of the program. (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 14
- 15. Feedback on Agile Implementation Survey – Written Response ● Have writers/developers taken on other roles in Scrum teams? ➔ ➔ R1: Non-writers have expressed interest in creating documentation. R2: Technical writers are given tasks of updating backlogs in excel sheet and updating them. ➔ R3: Writers are assigned with software usability testing. ➔ R4: Writers have taken on the role of scrum masters on some occasions. Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 15
- 16. Feedback on Agile Implementation Survey – Written Response ● What are the drawbacks of developing documentation the agile way? ➔ ● ● R1: Sprint releases converging on the same date. We work around this by performing production work after the sprint release date. R2: Technical writers have to work on individual functionalities and need SME help to compile all the content into a single document with correct workflow. This needs additional effort. R3: A fully loaded Agile team leaves very little time for any other activity such as self development, research and innovation. The workaround would be to make sure the teams are not fully loaded. They must be given breathing time, and there must also be down time between two agile releases so that team members can recharge. Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 16
- 17. Feedback on Agile Implementation Survey – Written Response ● What are the drawbacks of developing documentation the agile way? ● ● R4: Due to agile methodology, changes to documentation are constant. Therefore, what is delivered as part of a sprint may not be valid in the next sprint. Engineers are busy coding during the sprints. Even though inputs and review are accounted for during the sprint, this often never happens. There are also instances where there is UI mismatch with documentation during the testing cycle. This has resulted in documentation bugs. R5: Sometimes there is a lack of getting the complete picture. As a feature is developed across multiple sprints, a writer might lose the essence of working with the feature in one flow. This might lead to some gaps in documentation. Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 17
- 18. Feedback on Agile Implementation Survey – Written Response ● What are the advantages of developing documentation the agile way? ➔ ➔ ● ● R1: Robust and highly efficient. R2: Technical Writers are part of all the Scrum meetings and hence don't miss out on any information. R3: Documentation team is involved early in the development cycle and they are aware of the product progress due to effective communication in scrum methodology. This helps the team to be in sync with the engineering team always and facilitates documentation delivery which is customer centric and closely coupled with the product. R4: Documentation tasks are broken into multiple subtasks. For documentation tasks that run into many days, breaking them into smaller logical chunks help writers to plan and complete their activities. Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 18
- 19. Feedback on Agile Implementation Key Scrum Processes and Deviation Tweak in agile process required for documentation Not dedicated to a particular Scrum team Documentation not created and reviewed within the sprint Separate doc plan for planning Parameters of Deviation Exceeding recommended size of Development Team Writers not part of sprint planning meeting No participation in sprint review and retrospective 0 Feb 20, 2014 10 20 30 40 50 60 70 80 90 100 *The values indicate the percentage of companies that deviate on a particular process. (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 19
- 20. Conclusion ● ● ● ● ● ● Scrum is the preferred Agile methodology for most organizations. Most organizations have modified Scrum to fit their set up (called "scrum but"). Organizations have deviated on a number of key scrum processes (indicated in the chart – previous slide). To ensure success, there must be no deviations from the Scrum process. Scrum calls for change in organizational culture and mindset. Organizations need to ensure that priority for documentation is raised. And must carry out procedural/cultural changes to ensure documentation can be delivered incrementally at the end of each sprint. From the Scrum Primer: "Organizations (should not) mutate Scrum into just a mirror image of their own weaknesses and dysfunction, and undermine the real benefit that Scrum offers: Making visible the good and the bad, and giving the organization the choice of elevating itself to a higher level." Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 20
- 21. References ● Scrum Primer 2.0: http://www.scrumprimer.org/ ● Manifesto for Agile Software Development: http://agilemanifesto.org/ ● ● ● Images courtesy: http://www.freedigitalphotos.net/ and photo of King Henry I from: http://tinyurl.com/q3puuk6 Scrum Process image: From Wikipedia, under creative commons license: http://en.wikipedia.org/wiki/Scrum_(software_development) YouTube videos: ● ● ● Scrum Master, Funny movie about the power of scrum: http://www.youtube.com/watch?v=P6v-I9VvTq4 Scrum But: http://www.youtube.com/watch?v=rVtB7WhyK5Y Survey feedback and written response (participants acknowledged in Slide 12). ● Scrum Alliance: http://www.scrumalliance.org/ ● Comtech Services: http://comtech-serv.com/ Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 21
- 22. Q&A Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 22
- 23. Thank You! For more information, write to vasanth.vaidya@gmail.com Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 23
- 24. Backup Slides Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 24
- 25. Essentials of "Development Team" ● ● ● The Team in Scrum is “cross-functional” – it includes all the expertise necessary to deliver the potentially shippable product each Sprint – and it is “self organizing”. The Team decides how many items (from the set offered by the Product Owner) to build in a sprint, and how best to accomplish that goal . Each member of the Team is just a team member. There are no fixed specialist titles in a group that adopts Scrum; there is no business analyst, no DBA, no architect, no team lead, no interaction/UX designer, no programmer. Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 25
- 26. Essentials of "Development Team" (continued...) ● ● ● ● Each person certainly has special strengths, but also continues to learn other specialties. Each person has primary, secondary and even tertiary skills, and is meant to “go to where the work is”. Someone with primary skill in technical writing might also help with analysis and programming. The Team in Scrum is seven plus or minus two people. In Scrum, the Teams are most productive and effective if all members are 100 percent allocated to work for one product during the Sprint. ● The Team avoids multi-tasking across multiple products or projects. ● Stable teams are associated with higher productivity. Feb 20, 2014 (c) 2014 Vasanth Vaidyanathan. No part of the presentation may be copied or reproduced without the author's written permission. 26