This year’s Best Practices conference was held at in Santa Fe, New Mexico at the La Fonda Hotel, a grand old Pueblo-style hotel located in the heart of old Santa Fe. Anyone arriving to the conference early was treated to an open air market in the main square selling lots of turquoise jewelry, some very spicy street food, fine local Indian crafts and a parade where people on horseback dressed in papier-mâché costumes made their way to the local cathedral. All of this seemed a million miles away from a conference about technical writing management practices, but it was in fact an idyllic setting and there wasn’t a soul I met over the course of the conference who wasn’t happy to be there.
The overall theme for this year’s Best Practices conference was on Agile processes for documentation team management. This same topic came up at last year’s conference—I was on panel speaking about Agile processes for documentation teams—but this year’s conference focused squarely on that topic, examining various aspects of it in more details. I have a background in management studies, so many of the topics covered were a refresher for me, but the documentation managers and information architects I met at the conference said that they came away with solid information on how to get their teams to work together more effectively. And even though this was not a conference about DITA per se, it became apparent that it was the foundation for many of the best practices that were examined.
Keynote: Looking for Waste in the Right Places
The keynote speaker this year was Joann Molesky from ThoughtWorks. She is the co-author of Lean Enterprise. Her company has been delivering consulting service to Agile-based software development firms for over 15 years.
An issue she commonly encounters are companies whose internal culture are resistant to change, despite significant technological advancements. She quoted management expert Gary Hamel, who said that companies work using “21st-century Internet-enabled business processes, mid-20th-century management processes, all built atop 19th-century management principles.” Given the ever-accelerating growth of technology, it is hard for companies to keep up. As a result, conventional business models are under attack. She stated that in large organizations, the control bureaucracy (management) typically represents 10-20% of costs; from a Lean perspective this is a type of waste as it does not directly add value to the customer. So Molesky emphasized that we need to transform ourselves from siloed functional thinking—a goal familiar to many technical writing teams—and move towards fully customer-centric, product thinking. This would enable firms to better deliver customer value while aligning the purpose of a company more in terms of what the customer actually values.
A key takeaway from this presentation was when Molesky said that cutting costs is not the same as reducing waste; sometimes you have to spend money and invest in activities or tools in order to reduce waste and to better focus on customer’s needs. Anyone looking to switch their documentation process over to DITA or seeking to purchase a CCMS undoubtedly took heart with that statement. Conversely, she also mentioned a client she was involved with who wanted to change their internal processes, and so they bought a tool to help them with it. They ended up spending billions with no success. The problem was not with the tool—though apparently it never worked as designed—but with the underlying corporate culture. Molesky said “getting a new shiny tool will not solve your problems” when it is the organization that needs to change. She concluded by saying that the best way to create effective change in an organization is to focus on the needs of the customer and to “think big, start small, learn fast.”
Using Kanban in Documentation Development
Next on stage was Chuck Aikman, from Indiana University, who works with a team of three software developers and six technical editors, all of whom adopted Kanban two years ago. His talk was titled “Kanban: making your work in progress visible” and he looked at how his Knowledge Management team successfully adopted Kanban to manage their workflow.
So what is Kanban? It is a Lean process first developed at Toyota in the early 1950s. It means “signal card” in Japanese, and it is used primarily to allocate work to be done. There are a series of “bins”, each of which hold a number of cards, with each card describing a particular task to be done. It follows a set work flow, starting (in Aikman’s case) with new work to be done, a prioritized backlog, things they are waiting for the project owners to respond to, and then leading to work that is actively in progress and then finally to work in the process of being completed.
While this may seem at first glance to simply be a way of organizing and scheduling work, Kanban is a technique that also strives for “kaizen” (continuous improvement) in the process, not only revealing constraints but also describing the total work capacity a team can handle. There are a set amount of Kanban card/tasks that can be in the system at any one time, and cards flow from one bin to another as work progresses. A goal of using Kanban is to achieve a sustainable pace of work while also seeking ways to improve work flows and efficiency.
Aikman emphasized that documentation/knowledge managers should always be asking whether the content their team produces are delivering value to the customer. Also, determine what the minimal viable documentation will your users find valuable. The Kanban process also helps documentation planners prioritize their work, focusing on reducing work in progress (WIP), and to deliver in short, measured timeframes.
I think one of the most valuable things Aikman had to say revolved around his team’s experiences with implementing Kanban. He pointed out how an organization’s hierarchy often gets in the way of good communications, so managers need to trust their people and treat them like the adults so they feel empowered to suggest process changes. He also said it was important for a team thinking about implementing Kanban to treat it like an experiment and to make it safe to fail so that people are willing to contribute more and to trust in the process. Kanban also needs to be flexible in its implementation within a documentation environment, as complex work sometimes requires context-specific solutions that are not easily covered in a Kanban framework.
Good Habits for Lean Documentation
CIDM Partner and VP of Operations for Comtech Dawn Stevens did a nice documentation-centric presentation on waste from a Lean perspective called “Waist Not: Healthy Habits for a Lean Profile”.
Traditional Lean methodology outlines eight separate types of manufacturing wastes, which are:
- Defects
- Over-production
- Waiting
- Non-utilized talent
- Transportation
- Inventory
- Motion
- Extra-processing
Stevens then examined each of these from a technical publication perspective.
Defects: these are the errors, omissions, and information that is simply irrelevant to the customer. This can consist of outdated or incorrect content, broken links and typos/grammar problems. Referencing the keynote speaker’s earlier comment on how cost reduction does not necessarily equal better quality, Stevens talked about the sad trend of editorial staff being eliminated from technical publication groups, a role specifically designed to catch errors before they went out the door.
Over-production: this describes “kitchen sink” docs, which includes everything users are thought to need to know, whereas the reality (emphasized in DITA best practices) is to focus on minimalism and deliver what customers actually need to know when they need to know it. Over-production, from a documentation perspective, would also include providing information that users already know, adding gratuitous bells and whistles, and recreating what already exists.
Waiting: includes the time wasted for budget approval, authorization to begin, the product to be completed, getting information, and for reviews when documentation work could be done.
Non-utilized talent: this boils down to under-utilizing people’s time, skills and knowledge. This could include pigeon-holing team members to a single responsibility, assigning team members with the wrong skills to roles in a project just because they are available, and requiring everyone to attend meetings they are not truly needed to be there.
Transportation: this includes sending files for review in print or non-native formats, moving content from one program to another for differing outputs, or copying and pasting content from file to file.
Inventory: this is when content doesn’t meet the need of end users, so for example topics are either never accessed by end users because they are not directly useful, or because users cannot find them.
Motion: this was defined by Stevens as being team members being separated from each other, such as across a single building, across different buildings, or across more geographically spread sites. This of course is mitigated when there are good channels for virtual communication between team members, but when a person has to travel (i.e. to a meeting physically located elsewhere), the time that it takes for that person to travel is never recovered. In traditional Lean, this is defined more broadly as unnecessary movement by parts of a product, but I liked Dawn’s reformulation of this basic tenet.
Excess processing: is the duplication of effort where the same content is developed by multiple groups. For those using desktop publication systems, this also includes tweaking the look and feel of content, as well as minor changes reflecting personal preferences rather than an actual defect. Stevens gave the example of how at CIDM, for their publications, they first used to make things look great in Word, but Quark was the tool used for final output—so the formatting done in Word was ultimately a complete waste of time.
She concluded with a quote by Shigeo Shingo, who was the world’s leading expert on manufacturing practices and the Toyota Production System: “The most dangerous kind of waste is the waste we do not recognize.” For Stevens, the bottom line on waste in documentation processes is to examine what you are doing and question whether it brings any additional value to the customer, the company, to your department or to yourself. And if not, why are you doing it and how can you stop it? Food for thought.
To Scrum or Not to Scrum?
Christopher Gales from Splunk gave an interesting talk called “Scrum: what is it good for?” where he examined what parts of the scrum methodology work and do not work when it comes to documentation.
He started out by making what I thought was an excellent point about the original Agile manifesto which is often misconstrued. This is the line that says: “Working software over comprehensive documentation”. He pointed out that it is wrong to think that this means documentation does not matter at all, and emphasized another line that comes later from the manifesto saying that “there is value in the items on the right” within the sentences in the manifesto’s declarations. Some of the other items “on the right” include: following plans, working with contracts and using processes/tools. There are few developers who will say that these other things do not matter, so documentation definitely does matter.
Gales then talked about his experiences working with scrum in a documentation environment. He noted that scrum works really well when trying to document new, discrete features, incremental feature changes and maintenance releases for products. But there are occasions where it just doesn’t fit the type of documentation work that sometimes needs to be done, noting that scrum doesn’t work well for the following situations:
- Where the Sprint is an artifact of time as opposed to content
- There are multiple scrums (and not enough writers)
- Scenario-focused documentation
- Where there is an integrated content experience within a product
- Learning objectives (which are typically not factored in a typical development scrum)
- When there is a need to refactor content
- Editing work on existing content
- Sustaining efforts on documentation
So the question for a documentation manager is: should they use scrum? For Gale at Splunk, the answer came down to using it when it made sense to do so, and not for those occasions where it doesn’t fit. He went on to say that much of their documentation processes addresses customer requirements that lie outside the scrum process. And while they could change the content they produce in order to make it map more closely to scrums/sprints, doing so would not serve the needs of their customers better. So what they do is work in “an iterative development cycle that is focused on code, not the entire product, bracketed by more longitudinal planning and testing cycles”.
Gale’s experience closely matches my own observations when interviewing a number of documentation teams last year who claimed to be using some form of Agile (and its various approaches, including scrum, Lean and kanban): very few of them were using these Agile processes fully, instead adapting it to situations where it made the most sense to do so. A couple of the groups I talked to described their processes as being Agile, but were in fact almost textbook examples of waterfall instead. But even these groups were accessing some aspects of Agile and applying them where it worked. Basically they picked the bits of the Agile process that worked for them. I suspect that this more flexible approach to doing Agile within a documentation framework is the norm rather than the exception. Recognition that “water-scrum-fall” is more typical in development circles than pure Agile has been gaining ground for some time, and not just within the documentation realm. From a documentation management perspective, it seems to be a growing awareness that it is okay to be somewhat Agile.
Gale concluded by talking about how they use a home-grown Agile checklist which provides his documentation team with the flexibility they require while still allowing them to work within a scrum environment and also to focus on the needs of the customer. When talking to him after his talk, he mentioned that he and the members of his team at Splunk are working on a book on how they do technical documentation within a product development group. Something to keep an eye out for in the future!
A Fond Farewell
JoAnn Hackos is retiring from Comtech/CIDM and is handing over the reigns to Dawn Stevens. This conference is the first of three CIDM conferences where JoAnn Hackos has the chance to say goodbye to the people she has worked with over her long career.
And what a career it has been! She has a long list of achievements, including:
- Founder of the Center for Information-Development Management (CIDM)
- Founder and owner of ComTech Services
- A founder of the OASIS DITA Technical Committee
- The Chair of the OASIS DITA Adoption Committee
- Co-author of the ISO standard for systems and software engineering relating to content management for the product lifecycle (ISO/IEC/IEEE 26531)
- A Fellow and past President of the International Society for Technical Communication (STC)
Author of several seminal books on content management, including Managing Your Documentation Projects (Wiley 1994), Content Management for Dynamic Web Delivery (Wiley 2002) and Information Development: Managing your Documentation Projects, Portfolio, and People (Wiley 2006). - A long list of awards, including Goldsmith Award from the Institute of Electrical and Electronics Engineers, Professional Communication Society, the Rigo Award from the Association for Computer Machinery’s Special Interest Group on the Design of Communication, and the Horace Hockley Award from the Institute of Scientific and Technical Communicators in the United Kingdom.
While all of these achievements were mentioned at the banquet, it was really more of an opportunity for the many people in the audience to express their sincere appreciation and gratitude to JoAnn for what she has done for them over the years. People came up from the audience and related their own experiences of working and being with JoAnn, including Daphne Walmer’s spirited introductory speech, Joe Golner, and IXIASOFT’s Eric Bergeron. There were also a few tears and plenty of hugs going around as well. At the conclusion of the ceremony, Dawn Stevens came up and gave JoAnn the first part of a three-part statue that was created in her honor, with the next two pieces to be handed out at subsequent CIDM conferences.
