This document discusses applying Lean principles to technical writing in an Agile environment. It defines Lean and Agile, then identifies types of waste that can occur in documentation, such as unnecessary content, rework, and delays. The author advocates for technical writers to be integrated team members, treating documentation like code and adopting Agile practices like sprints and iterative publishing. Embracing Lean concepts like identifying value, optimizing workflows, and addressing problems collaboratively can help technical communicators address challenges of Agile and minimize documentation waste.

1. Towards an
Agile Authoring
methodology:
Learning from
Lean
Ellis Pratt
@ellispratt
May 2016
ISTC Southern Area
Group

2. Overview
1. About me
2. What is Agile?
3. What is Lean?
4. A Lean view of technical
writing
5. Towards an Agile
methodology
6. Resources
Image: Tim Peake

3. About me

4. About me
Director at Cherryleaf, a technical writing
services and training company in the UK
I’m also on the ISTC’s Management Council

5. And also
I wrote my dissertation on
“A Systems analysis of
manufacturing production
methods”

6. What started me on this
journey
Agile is problematic for
technical communicators

7. What started me on this
journey
“What's just enough
documentation?”
Dom Smith PhD, Red Gate
Software
Mark Eaton CEng BSc MSc
MBA FIET FIOM FRAS (and
holder of the Viscount Nuffield
Medal)

8. I wondered
Could Lean help address
some of the challenges of
working in an Agile
environment?

9. What is Agile?

10. Features of Agile
Self-directing, collaborative
teams
Early, frequent and continuous
releases
Iterations and cycles
Lessons learnt - teams
continuously examine and
evolve their own processes

11. Defer commitment
Decide as late as possible
Particularly decisions that are
irreversible (or at least will be
impractical to reverse)

12. Active user involvement Is
imperative
So the right product is
delivered

13. Requirements evolve, but
timescales are fixed
The scope of an Agile
Development project is
variable

14. Deliver only what adds value
It’s not the process the
customer drives, it’s the car

15. Agile’s effect on writing
Changing requirements and
rework
Sizing a project is difficult
The is the concept of
“Document late” to avoid
waste (but this can cause
waste elsewhere)
There’s no time

16. Starting the documentation
project
Initiation
Specs and
design
Build
Test
Launch
Post launch
Common
starting point
Iteration Zero
Consolidation sprints

17. What is Lean?

18. What is Lean?
A process for making things
Based on the Toyota
Production System
Used today in healthcare,
programming and other areas

19. What is Lean?
A relative of Agile &
Six Sigma methodologies

20. Lean in a nutshell
Maximise value to the
customer
Minimise waste

21. Waste in Lean
1.Waiting
2.Over processing
3.Rework and correcting
4.Moving things
5.Processing waste
6.Inventory
7.Talent misused
8.Not meeting customer’s requirements
Lean breaks waste down into 7 (or 8)
categories

22. We’ll focus on the three
original wastes
Muda
Not adding value to the
user
Muri
Overburden
Too difficult / Too much
Mura
Unevenness
Waiting

23. Optimise the whole, not the
parts
Optimise the whole value
stream, not just individual
functions or teams
This leads to complete, multi-
disciplined, co-located
product teams
Image: RMI.org

24. Lean activities
for maximising value
Value Stream Mapping
Voice of The Customer

25. One piece flow
Instead of batch processing
(even though it’s
counterintuitive)
You’ll spot errors much more
quickly
Image: Geoff Rixon

26. Andon cord
If there is a problem,
anyone can stop the
production line

27. Discovering the root cause of
a problem
Discover the root cause of
a problem using “5 Whys”
Offer a proportionate
intermediate fix, esp. if the
cause is at the customer’s
side
Pete Abilla

28. Hoshin Kanri
Aka policy deployment
A method for ensuring that
the strategic goals of a
company drive progress
and action at every level
within that company
Assumes mutual respect for
people

29. A Lean project plan
Is there a
compelling need
to do the work?
Current state
Implementation
plan
How we
measure
success
Desired state
Result from
change
Risks,
limitations,
issues
Roles and
responsibilities
Lessons learnt

30. Questions a Lean consultant
would ask
Will the client pay for it to be
produced?
If they won’t pay, is it essential
waste? (A compelling need,
like tests and inspections)

31. Are you ʻprocessing wasteʼ?
Do you have an efficient
process, but you’re
producing something that
add little value to the user?
(This is a key issue in Agile)

32. Questions a Lean consultant
would ask
Can it significantly improve
productivity?

33. How can we tell?
Measure to discover what
really adds value
Verify your assumptions

34. A Lean view of
technical writing

35. Do you have an inefficient
process?
Waiting
Over processing
Rework and correcting
Moving things
Inventory
Talent misused
Image: Pizza Express

36. Waste - for the user
Content that’s not needed or
Doesn’t meet their needs
Too difficult or detailed
Delays in finding information

37. Waste - for the writer
Creating content that’s not
needed
Editing/multiple draftsToo much work and
Not enough time
Delays in approving & publishing
content

38. Common types of waste in
content
“Waste in formatting -
formatting and reformatting
and re-reformatting
Waste in information
development - end users do
not want or need what’s being
produced
Waste in delivery - information
cannot be used by end user
because it’s not in the right
language or the right format
Waste in review - oh, so much
waste in the review cycles”
http://www.scriptorium.com/2015/09/lean-content-strategy/

39. How do you measure quality
in content?
Useful
Writing quality - mechanics and
grammar
Usable - ease of access to
information
Free of defects (technical accuracy)
Completeness
Conciseness
Findable

40. Towards an Agile
methodology

41. Your role in Agile

42. Docs are a team
responsibility
You should be one team
Docs should be part of
the definition of Done
Docs should be part of
the review process
Image: St Helens RFC

43. Treat documentation as code
You are a developer (of
content)
Add your tasks to the
Kanban board
Treat reviews and edits as
“calibrations” and “defects”
Use the same tools as the
developers, wherever
possible
Robert Hays, eBay Enterprises

44. Treat documentation as code
Make sure your Task scope is
clear
Include the feature number
and the User Story reference
number in the topic titles
So there is close tracking of
topics to code development

45. Agile is a team sport
There should be mutual
respect for all team members,
including you

46. Take an active role
in
User Stories
Sprint Planning
Scrums
Grooming (fixing errors)
Retrospectives

47. The Technical Writer’s role
Can also be a good project
manager for the whole Agile
project
Not so emotionally attached to
the code
Can represent the user
Image: Atlassian

48. Run doc sprints

49. Be the content strategist
“Gather it
Organise it
Share it
It’s what you’re good at”
Sarah Maddox, Technical Writer, Google

50. Optimise the whole
Define content standards
across the company
Identify the origins of
information and use them
Streamline the workflow
Image: Joe Gollner

51. Deliverables

52. Minimal Viable Product
“Just-In-Time Documentation
Also Means Just Enough”
Anne Gentle
Anne Gentle. 2007. Writing End-User Documentation in an Agile Development Environment
Retrieved May 2015 from http://justwriteclick.com/2007/07/02/writing-end-user-documentation-

53. An iterative publishing
process
Minimum viable product
Incremental release
Service à la russe
Prior to product release?
Early adopters happy to work
out some things themselves
Image: Cafe Gallay Geneva

54. Novels have been serialised
"The Strand Magazine (cover), vol. 73, April 1927" by Special Collections Toronto Public Library - http://www.flickr.com/photos/
43021516@N06/8346257651/. Licensed under CC BY-SA 2.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/
File:The_Strand_Magazine_(cover),_vol._73,_April_1927.jpg#/media/File:The_Strand_Magazine_(cover),_vol._73,_April_1927.jpg
"Alltheyearround 1891" by Chapman & Hall - Internet Archive. Licensed under Public Domain via Wikimedia Commons - http://
commons.wikimedia.org/wiki/File:Alltheyearround_1891.jpg#/media/File:Alltheyearround_1891.jpg

55. Minimal Viable Product
Triage to Support or to the
documentation
“Runners, Repeaters and
Strangers”
Image © Mark Eaton

56. Load balancing

57. Key stages in the project
Initiation
Specs
and
design
Build
Test
Launch
Post
launch
Ideal
starting point
Doc
planning

58. One piece flow
Review topics as soon as
possible?
Translate as soon as a topic
is completed (costly
rework)?
Publish as soon as a topic
is completed?

59. Defer commitment
Store content in a flexible format
that allows for multiple types of
output.
Keep your options open on
deliverable formats.
Be open to adding new content
based on user feedback or other
new information.
Assess L18N requirements
regularly as business conditions
change. Look at a list of
supported languages as an
evolving set, not as set in stone
forever.

60. Topic-based authoring
You can re-use content
You can rearrange content
Image: Kai Weber

61. Who does the work?
Try and even out the workload
Federated Help system
Find a long term partner
Developers may need to
create the code examples
Have clear requirements
Developers should not
abdicate responsibility
Image: Atlassian

62. Tools

63. Andon
Swarm around the problem
No more coding until
documentation is fixed?
Tricky if you are using
specialist tools

64. Make it easy for developers
to collaborate
Set standards
Provide guidelines
Provide templates
Enable them to use their own
tools
Share the same issue tracker
Share the same review tool?

65. Developer friendly tools
Markdown
MadCap Contributor
GitHub
JIRA
Lightweight DITA?

66. Resources

67. Did you know?
There is an ISO standard for
writing user documentation for
Agile projects
SO/IEC 26515:2011 Developing
user documentation in an agile
environment
Photo: Cerys Willoughby

68. Salesforce.com
http://blogs.developerforce.com/tech-pubs/2013/02/a-writers-guide-to-surviving-agile-software-
development.html
Write bottom up, plan
later
Write fiction
Revise fiction
Be wrong
Run blitzes to fix errors in
doct’n
Build templates
Ask questions at scrum
meetings
Volunteer for other tasks
Take the role of an
additional quality
engineer
Self-organize and barter
for time

69. Summary

70. What are the takeaways?
Lean is a useful way to
position UA in an Agile
environment
Helps you identify when
“document late” is a bad
idea, as a result of other
wastes not considered by
Agile.
Both make problems visible

71. An Agile authoring manifesto
One piece flow
Minimalist manuals
Iterative updates to the content &
Incremental publishing of content
(and frequent builds of drafts)
Documentation sprints
Collaborative authoring
Rigorous testing and
measurement of the value of the
documentation
Separation of “look and feel”
“Stop the line”
Close daily cooperation and
communication with the
development team
Removal of “waste”, such as
waiting for new information or
overload of work
Buy-in and commitment from all
the stakeholders of the value and
need for the User Assistance

72. Questions

73. For more information
ellis@cherryleaf.com
@ellispratt

74. End
© Cherryleaf 2016
Images and
screenshots © their
respective owners