In this presentation, we talk about state of agile implementation in organizations having documentation/technical writing teams. Is scrum meant for teams that include Technical Writers? How well have organizations adapted this new process?

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